https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082014-02-20T15:33:13ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #1587: can't gdb across forkhttps://bugs.dragonflybsd.org/issues/1587?journal_id=117992014-02-20T15:33:13Ztuxillo
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/11799/diff?detail_id=1456">diff</a>)</li><li><strong>Category</strong> set to <i>Userland</i></li><li><strong>Assignee</strong> changed from <i>0</i> to <i>tuxillo</i></li><li><strong>Target version</strong> set to <i>3.8</i></li></ul><p>Grab.</p> DragonFlyBSD - Bug #1587: can't gdb across forkhttps://bugs.dragonflybsd.org/issues/1587?journal_id=118372014-02-24T13:23:55Ztuxillo
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>Hi,</p>
<p>This is still the case, I could reproduce it with the suggested test.</p>
<p>Breakpoint 1, stalloc (nbytes=24) at memalloc.c:151<br />151 {<br />(gdb)<br />Continuing.<br />Trace/BPT trap (core dumped)</p>
<p>But I have some questions here:<br />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. <br />b) Are we sure this is not a gdb "feature" ?</p>
<p>FWIW, this is also the case in FreeBSD 10.</p>
<p>Cheers,<br />Antonio Huete</p> DragonFlyBSD - Bug #1587: can't gdb across forkhttps://bugs.dragonflybsd.org/issues/1587?journal_id=118382014-02-24T13:33:05Zcorecode
<ul><li><strong>File</strong> <a href="/attachments/1079">signature.asc</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1079/signature.asc">signature.asc</a> added</li></ul><p>It's stalloc in sh, after fork, before exec.</p>
<p>On 02/24/2014 02:23 PM, <a class="email" href="mailto:bugtracker-admin@leaf.dragonflybsd.org">bugtracker-admin@leaf.dragonflybsd.org</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-4 priority-4 priority-default" title="Bug: can't gdb across fork (Feedback)" href="https://bugs.dragonflybsd.org/issues/1587">#1587</a> has been updated by tuxillo.</p>
<p>Status changed from New to Feedback</p>
<p>Hi,</p>
<p>This is still the case, I could reproduce it with the suggested test.</p>
<p>Breakpoint 1, stalloc (nbytes=24) at memalloc.c:151<br />151 {<br />(gdb)<br />Continuing.<br />Trace/BPT trap (core dumped)</p>
<p>But I have some questions here:<br />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. <br />b) Are we sure this is not a gdb "feature" ?</p>
<p>FWIW, this is also the case in FreeBSD 10.</p>
<p>Cheers,<br />Antonio Huete</p>
<p>----------------------------------------<br />Bug <a class="issue tracker-1 status-4 priority-4 priority-default" title="Bug: can't gdb across fork (Feedback)" href="https://bugs.dragonflybsd.org/issues/1587">#1587</a>: can't gdb across fork<br /><a class="external" href="http://bugs.dragonflybsd.org/issues/1587#change-11837">http://bugs.dragonflybsd.org/issues/1587#change-11837</a></p>
<ul>
<li>Author: corecode</li>
<li>Status: Feedback</li>
<li>Priority: Normal</li>
<li>Assignee: tuxillo</li>
<li>Category: Userland</li>
<li>Target version: 3.8.0<br />----------------------------------------<br />When the debugged process performs a fork(), gdb/ptrace won't notice and <br />will not be able to remove breakpoints in the new child. When the child <br />then hits a breakpoint, it will receive a SIGTRAP and dump core.</li>
</ul>
<p>gdb needs to be aware of forks, so that it will be able to remove the <br />breakpoints in the child.</p>
<p>Test: gdb sh and break stalloc.</p>
</blockquote> DragonFlyBSD - Bug #1587: can't gdb across forkhttps://bugs.dragonflybsd.org/issues/1587?journal_id=139982021-05-11T10:54:03Ztuxillo
<ul><li><strong>Target version</strong> changed from <i>3.8</i> to <i>6.0</i></li></ul>