Please provide more details, I am looking forward for the panic message and backtrace.
I can't seem to get the panic with the latest source base, but tracing doesn't appear to work with vfork(). I attached a modified test case to closer model what gdb is doing. If you change fork() to vfork() in simple.c the parent doesn't get the events the same way it does under fork().
The lack of the notification for parent is exactly what the patch I posted fixes. More exactly, it is the lack of notification for parent with PT_CONTINUE loop. I will commit this today. Regarding a single notification. Currently, parent arrives at the syscall return code only after the child is attached to the debugger. See the cv_wait() in kern_fork.c:739. In other words, if you get the PL_FLAG_FORK, the child is already attached (at last it shall be). My scescx.c code illustrates this well, IMO. You still get a separate stop from the child, but I do not see how is it harmful.
There a couple of tweaks to the interface that I'd like to have: - set PL_FLAG_FORKED in the child so gdb can identify the stop as a fork() event. - add a switch similar to PT_FOLLOW_FORK to enable/disable exec() notifications. Gdb gets confused by the events it hasn't explicitly asked for and having a switch makes it easier to filter out unwanted stops. Do you think it's possible/makes sense? Thanks. Dmitry.
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]"
