This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/3 v4] Demangler crash handler


On 05/06/2014 2:03 PM, Gary Benson wrote:

> diff --git a/gdb/cp-support.c b/gdb/cp-support.c
> index 91533e8..f4dde70 100644
> --- a/gdb/cp-support.c
> +++ b/gdb/cp-support.c

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

This worries me a little, when a problem case occurs gdb will dump 
core regardless of the users ulimit setting, without first asking
the user, and doesn't tell the user that a core file was created.

This feels quite unexpected behaviour to me, especially the bit about
disregarding the ulimit setting without first asking for permission.

Catching the crash feels like a good idea, but I'd prefer that gdb ask
before circumventing the ulimit and dumping core.  Alternatively we
could just not dump core from gdb, report the bad symbol and let the
user file a bug.  With the demangler being so deterministic it should
be possible to reproduce, if not, then we just ask the user to turn
off the crash catch, adjust their ulimit (like we would with any other
gdb SEGV crash), and rerun the test.

If we really want to create the core file by default, but aren't going
to ask, then I'd propose we honour the ulimit setting, and make sure
that the user is told that a core file was just written.

Thanks,
Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]