Closed ell1e closed 10 months ago
Seems like it was caused by the unit test library libcheck forking away, my apologies for the invalid ticket.
Hi Ellie.
Thanks for trying Seer.
For my own curiosity, I will look into libcheck. Even if it forks, gdb break points should be able to survive. At least I thinks so.
I'm the UK at the moment. I'll look into when I get back.
Reopening for the moment.
It seems to be the case that by default, gdb detaches when there's a fork. However, I think it might be helpful if seergdb either just changed that default, or showed some more obvious information that this happened e.g. in that seer execution stuff popup. It took me quite a while to realize what was going on.
Thanks for trying Seer.
This project really is very promising. Thanks for working on it. Only some minor things threw me off (among them that the startup dialog, despite offering project/load save which is very nice but not the most obvious to discover right away, doesn't just show the path still entered from last launch. And the lack of variable hover on pause) but those really aren't a big deal, I think I'm going to quite like this program once I got some more used to it. Really cool!
Thanks fir the kind words. Keep the suggestions coming!
On the matter of "forking", you may need to set the "fork follow" mode to "child", "parent", or "both". Bottom right corner of the UI. I'll be able to verify when I get back.
I've duplicated what you've seen with libcheck. And it is related to libcheck's use of fork/vfork.
gdb, by default, will follow the parent's execution.
By default, when a program forks, GDB will continue to debug the parent process and the child process will run unimpeded.
But this means they child runs unimpeded, even if there are breakpoints set.
So, for your use, you need to tell Seer to "Fork follows Child". Which is the button in the lower right corner. Do this early. Just after you break in main().
In my tests, I did see some odd things with Seer and restarting the program that has forked processes. I'll use this Issue to address that.
I'm closing this task as it's relates to using "Fork follows child".
However, I'm creating task #167. As there is a problem restarting the debug session with Run/Start for programs that use fork/vfork.
For some reason, when I set up a breakpoint in the program sources and then click to run the program, the breakpoint is just completely ignored and afterward even disappears again from the breakpoint list like it wasn't ever there:
This is with gdb, gcc 12 and a pretty standard C program with no fancy dependencies, so I wonder what's going on.