public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert
Date: Thu, 07 Jan 2021 23:35:20 +0000	[thread overview]
Message-ID: <bug-98586-4-OXRdmMHIEx@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-98586-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-01-07

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this.  I'm able to reproduce the issue by hacking in a 
  gcc_assert (0);
into that routine.

I looked at calling diagnostic_initialize.

Unfortunately, libgccjit supports being linked into multithreaded processes,
and it guards all of the regular compiler state with a single big mutex,
including the diagnostic subsystem (and the "global_dc" pointer implicitly used
by fancy_abort).  This failure is happening before the mutex is acquired.

Some possible solutions:

(a) guard more code with the mutex, and fix the ICE-handling to ensure that
diagnostic_initialize is called if need be so the final message can be printed

(b) make the ICE handler detect this case, and use a custom diagnostic context
for the final message (though it's accessing data outside of the mutex in this
case, albeit just one pointer that rarely changes, and in crash handling)

(c) don't use fancy_abort within libgccjit, perhaps overriding the defn of the
abort macro in system.h

(d) rewrite fancy_abort so that it detects the case somehow

(e) have a custom assertion macro for the parts of libgccjit that aren't
guarded by the mutex

I'm not sure yet what the best fix is.

  reply	other threads:[~2021-01-07 23:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-07 18:12 [Bug jit/98586] New: " keith.marshall at mailinator dot com
2021-01-07 23:35 ` dmalcolm at gcc dot gnu.org [this message]
2021-01-08 11:18 ` [Bug jit/98586] " keith.marshall at mailinator dot com
2021-01-11 22:09 ` dmalcolm at gcc dot gnu.org
2021-01-14 22:03 ` cvs-commit at gcc dot gnu.org
2021-01-14 22:04 ` dmalcolm at gcc dot gnu.org
2021-01-16 14:16 ` keith.marshall at mailinator dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-98586-4-OXRdmMHIEx@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).