[review v3] Introduce thread-safe way to handle SIGSEGV

Tom Tromey (Code Review) gerrit@gnutoolchain-gerrit.osci.io
Fri Nov 22 23:12:00 GMT 2019


Tom Tromey has posted comments on this change.

Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/171
......................................................................


Patch Set 3:

(1 comment)

| --- gdb/cp-support.c
| +++ gdb/cp-support.c
| @@ -1477,17 +1480,17 @@ static bool catch_demangler_crashes = true;
|  
|  /* Stack context and environment for demangler crash recovery.  */
|  
| -static SIGJMP_BUF gdb_demangle_jmp_buf;
| +static thread_local SIGJMP_BUF *gdb_demangle_jmp_buf;
|  
|  /* If nonzero, attempt to dump core from the signal handler.  */
|  
| -static int gdb_demangle_attempt_core_dump = 1;
| +static std::atomic<bool> gdb_demangle_attempt_core_dump;

PS3, Line 1487:

> Is there anything ever initializing this to true?

Oops, nope.  I fixed this.

> Makes me ponder about a maintenance command to force a SIGSEGV.

I think there is one actually.
I don't know if I want to try to unit test this or not.
The current problem under discussion is maybe hard to check.

What would be really great is to fuzz the demangler and fix all
the bugs.  Then we could ditch all of this code

|  
|  /* Signal handler for gdb_demangle.  */
|  
|  static void
|  gdb_demangle_signal_handler (int signo)
|  {
|    if (gdb_demangle_attempt_core_dump)
|      {
|        if (fork () == 0)

-- 
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: Ic832bbb033b64744e4b44f14b41db7e4168ce427
Gerrit-Change-Number: 171
Gerrit-PatchSet: 3
Gerrit-Owner: Tom Tromey <tromey@sourceware.org>
Gerrit-Reviewer: Tom Tromey <tromey@sourceware.org>
Gerrit-CC: Pedro Alves <palves@redhat.com>
Gerrit-Comment-Date: Fri, 22 Nov 2019 23:12:06 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Pedro Alves <palves@redhat.com>
Gerrit-MessageType: comment



More information about the Gdb-patches mailing list