epasveer / seer

Seer - a gui frontend to gdb
GNU General Public License v3.0
2.09k stars 66 forks source link

libcheck forking away confuses gdb and seer with default settings #152

Closed ell1e closed 10 months ago

ell1e commented 11 months ago

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:

Screenshot from 2023-09-27 18-36-53

This is with gdb, gcc 12 and a pretty standard C program with no fancy dependencies, so I wonder what's going on.

ell1e commented 11 months ago

Seems like it was caused by the unit test library libcheck forking away, my apologies for the invalid ticket.

epasveer commented 11 months ago

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.

epasveer commented 11 months ago

Reopening for the moment.

ell1e commented 11 months ago

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.

ell1e commented 11 months ago

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!

epasveer commented 11 months ago

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.

epasveer commented 11 months ago

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.

https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_25.html#:~:text=By%20default%2C%20when%20a%20program,set%20follow%2Dfork%2Dmode%20.&text=Set%20the%20debugger%20response%20to%20a%20program%20call%20of%20fork%20or%20vfork%20.

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.

epasveer commented 10 months ago

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.