This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Do not pass NULL for the string in catch_errors
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>, <gdb-patches at sourceware dot org>
- Date: Thu, 22 Oct 2015 09:23:01 -0200
- Subject: Re: [PATCH] Do not pass NULL for the string in catch_errors
- Authentication-results: sourceware.org; auth=none
- References: <1441809933-9612-1-git-send-email-lgustavo at codesourcery dot com> <55F182B1 dot 4020404 at redhat dot com> <5627739A dot 2090401 at codesourcery dot com> <5628C37E dot 2030208 at redhat dot com>
- Reply-to: Luis Machado <lgustavo at codesourcery dot com>
On 10/22/2015 09:07 AM, Pedro Alves wrote:
On 10/21/2015 12:14 PM, Luis Machado wrote:
On 09/10/2015 10:16 AM, Pedro Alves wrote:
On 09/09/2015 03:45 PM, Luis Machado wrote:
I caught a segmentation fault while running gdb.reverse/sigall-reverse.exp,
in a mingw32 GDB, in this code path. It boils down to the code trying to
strlen () a NULL pointer. I tracked things down and it looks like
record_full_message_wrapper_safe is the only occurrence.
We could also change catch_errors to check the char pointer and pass the
empty string automatically if the pointer is NULL. Then again, it seems like
catch_errors is going away at any time now, being potentially replaced
It's been marked superseded for years. If you had fixed this by
converting this one instance, we'd be a little closer. ;-)
Well, we shouldn't rush! :-)
Seriously, i've been looking into this and it doesn't look like
catch_exceptions/catch_exceptions_with_msg is something we'll want to
use in the long run either. Those couple functions also do not directly
I thought about replacing the remaining catch_errors occurrences with
TRY/CATCH/END_CATCH blocks, which sounds better aligned with what we
want to do in the future - migrating to C++ etc. Then we can finally get
rid of catch_errors and a few useless wrappers. How does that sound?
Sounds like better leave it be then. It may be that with proper C++/RAII
the try/catches would disappear altogether in the end, for instance.
I see. Unfortunately, for the cases where catch_exceptions supposedly
acts similarly to catch_errors, it still doesn't work correctly because
catch_exceptions doesn't seem to cope well with error () calls, like the
case inside record-full.c.
With catch_exceptions, instead of catching the error and letting the
inferior continue, it will just cause the inferior to terminate.
The other cases spread through breakpoint.c, infrun.c, solib.c etc, are
supposed to emit a message in case an error happens, as opposed to
passing an empty string.
catch_exceptions_with_msg only allows recording a copy of the message
from an exception thrown from the guarded called function. It doesn't
emit a message passed in as argument like catch_errors.