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.
next prev parent 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: linkBe 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).