DragonFlyBSD

Grab.

Hi,

This is still the case, I could reproduce it with the suggested test.

Breakpoint 1, stalloc (nbytes=24) at memalloc.c:151
151 {
(gdb)
Continuing.
Trace/BPT trap (core dumped)

But I have some questions here:
a) if the child has the breakpoint set, why is it still breaking at stalloc() ? Because If I am running 'ls' for example that function does not exist.
b) Are we sure this is not a gdb "feature" ?

FWIW, this is also the case in FreeBSD 10.

Cheers,
Antonio Huete

It's stalloc in sh, after fork, before exec.

On 02/24/2014 02:23 PM, bugtracker-admin@leaf.dragonflybsd.org wrote:

Issue #1587 has been updated by tuxillo.

Status changed from New to Feedback

Hi,

This is still the case, I could reproduce it with the suggested test.

Breakpoint 1, stalloc (nbytes=24) at memalloc.c:151
151 {
(gdb)
Continuing.
Trace/BPT trap (core dumped)

But I have some questions here:
a) if the child has the breakpoint set, why is it still breaking at stalloc() ? Because If I am running 'ls' for example that function does not exist.
b) Are we sure this is not a gdb "feature" ?

FWIW, this is also the case in FreeBSD 10.

Cheers,
Antonio Huete

----------------------------------------
Bug #1587: can't gdb across fork
http://bugs.dragonflybsd.org/issues/1587#change-11837

• Author: corecode
• Status: Feedback
• Priority: Normal
• Assignee: tuxillo
• Category: Userland
• Target version: 3.8.0
  ----------------------------------------
  When the debugged process performs a fork(), gdb/ptrace won't notice and
  will not be able to remove breakpoints in the new child. When the child
  then hits a breakpoint, it will receive a SIGTRAP and dump core.

gdb needs to be aware of forks, so that it will be able to remove the
breakpoints in the child.

Test: gdb sh and break stalloc.