From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: gdb-patches@sourceware.org
Subject: RFC: gdb_assert with 'catch signal ...' and fork
Date: Fri, 03 May 2013 22:37:00 -0000 [thread overview]
Message-ID: <1367620645.2243.49.camel@soleil> (raw)
gdb 7.6 'catch signal' interacts badly with fork, causing a gdb_assert
such as
break-catch-sig.c:152: internal-error: signal_catchpoint_remove_location: Assertion `signal_catch_counts[iter] > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This can be reproduced with a (patched) gdb.base/catch-signal.c.
The problem is that the signal_catch_counts is decremented
by detach_breakpoints.
The patch below modifies catch-signal.c, catch-signal.exp
and modifies breakpoint.c so as to avoid the assert.
2 questions:
1. The fix is based on the assumption that detach_breakpoints
only has to detach breakpoints and watchpoints,
but not catchpoints (see breakpoints.h comments,
that do not fully match the implementation which
e.g. also detach the single step breakpoints).
Unclear to me if this is the good fix ?
(the fix causes no regtest failure)
2. when running the modified catch-signal test with an
unpatched gdb, the test fails but gdb.log does not contain
the assert. Rather, the test fails with 'the program exited'.
When doing the same commands manually, it shows the gdb assert.
No idea why this difference of behaviour.
Philippe
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.759
diff -r1.759 breakpoint.c
3552a3553,3555
> if (bl->owner->type == bp_catchpoint)
> continue;
>
Index: testsuite/gdb.base/catch-signal.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/catch-signal.c,v
retrieving revision 1.3
diff -r1.3 catch-signal.c
17a18
> #include <stdlib.h>
46a48,59
>
> signal (SIGCHLD, handle);
> switch (fork()) /* fork marker */
> {
> case -1:
> perror ("fork");
> exit (1);
> case 0:
> exit (0);
> }
> (void) wait(NULL);
> raise (SIGHUP); /* fifth HUP */
Index: testsuite/gdb.base/catch-signal.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/catch-signal.exp,v
retrieving revision 1.4
diff -r1.4 catch-signal.exp
85a86,87
>
> delete_breakpoints
86a89,95
> # Test interaction with fork. This used to cause a gdb_assert.
> gdb_breakpoint ${srcfile}:[gdb_get_line_number "fork marker"]
> gdb_continue_to_breakpoint "fork marker"
> gdb_test "handle SIGHUP nostop noprint pass" \
> "SIGHUP.*No.*No.*Yes.*"
> gdb_test "catch signal SIGHUP" "Catchpoint .*"
> gdb_test "continue" "Catchpoint .* SIGHUP.*" "got SIGHUP after fork"
next reply other threads:[~2013-05-03 22:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-03 22:37 Philippe Waroquiers [this message]
2013-05-03 22:43 ` Philippe Waroquiers
2013-05-07 17:11 ` Pedro Alves
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=1367620645.2243.49.camel@soleil \
--to=philippe.waroquiers@skynet.be \
--cc=gdb-patches@sourceware.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