PWNDBG fails to re-establish context, breakpoints and si/ni ignored

[cclamb]

msg.zip

Description

Breakpoints don't seem to reset under certain conditions. Specifically, after popen(.) in the attached zipped example.

Steps to reproduce

(0) Install latest version of pwndbg.
(1) execute gdb against the msg executable.
(2) set a breakpoint in print_msg().
(3) Step through the disassembly using either "ni" or "si"
(4) Attempt to step into or over popen().

The debugger will immediately run to the end of the program, not resetting breakpoints or allowing additional stepping.

My setup

Ubuntu 22.04 LTS
gdb 13.2
Latest pwndbg (as of 3/5/24)

[disconnect3d]

Hi,

I believe the popen function does a fork and execve syscalls and we set set follow-fork-mode child in Pwndbg so GDB enters and debugs the child process.

Ideally, we would love GDB to have an option to ask the user to choose if they want to follow fork or not (see: #2014) but its not there yet.

For now, you can change this by doing set follow-fork-mode parent and re-running your program.

Closing this since this is 99,9% invalid. Let us know if my understanding of this issue is incorrect and if there is any real bug here.

[cclamb]

I think you’re correct about the behavior of popen(). That said, debugging works perfectly fine with stock GDB and GDB with GEF. That’s what led me to believe there was something happening with pwndbg causing this issue. I would reconsider closing, as this is a loss of functionality from stock GDB. - c. (Mspellngs courtesie of ipad)

…

On Wed, Mar 6, 2024 at 4:46 AM Disconnect3d ***@***.***> wrote: Hi, I believe the popen function does a fork and execve syscalls and we set set follow-fork-mode child in Pwndbg <https://github.com/pwndbg/pwndbg/blob/dev/pwndbg/__init__.py#L43-L60> so GDB enters and debugs the child process. Ideally, we would love GDB to have an option to ask the user to choose if they want to follow fork or not (see: #2014 <#2014>) but its not there yet. For now, you can change this by doing set follow-fork-mode parent and re-running your program. Closing this since this is 99,9% invalid. Let us know if my understanding of this issue is incorrect and if there is any real bug here. — Reply to this email directly, view it on GitHub <#2062 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5JB5BPGIUJTGFMQBJ56LYW36Z5AVCNFSM6AAAAABEH53M76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBQGY4TGMRZGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cclamb]

I also have realized I may have been unclear on the specific use case. I am not interested in going into the popen() call code. I want to be able to srep over the call and continue debugging on the other side. Any breakpoints set on the other side of the popen() call are ignored and I can’t use ni to step over the call to continue with debugging session. Essentially, as soon as I hit the popen() call, the debugging session terminates and the program finishes execution. Stock GDB and GDB with GEF don’t do this. - c. (Mspellngs courtesie of ipad)

…

On Wed, Mar 6, 2024 at 4:46 AM Disconnect3d ***@***.***> wrote: Hi, I believe the popen function does a fork and execve syscalls and we set set follow-fork-mode child in Pwndbg <https://github.com/pwndbg/pwndbg/blob/dev/pwndbg/__init__.py#L43-L60> so GDB enters and debugs the child process. Ideally, we would love GDB to have an option to ask the user to choose if they want to follow fork or not (see: #2014 <#2014>) but its not there yet. For now, you can change this by doing set follow-fork-mode parent and re-running your program. Closing this since this is 99,9% invalid. Let us know if my understanding of this issue is incorrect and if there is any real bug here. — Reply to this email directly, view it on GitHub <#2062 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5JB5BPGIUJTGFMQBJ56LYW36Z5AVCNFSM6AAAAABEH53M76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBQGY4TGMRZGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[disconnect3d]

It is not a loss of functionality. It is a deliberate choice we have made at some point and I wondered many times if we should set that GDB parameter back or not.

FWIW: GDB docs about set follow-fork-mode child|parent.

I even made a poll on Twitter about it: https://twitter.com/disconnect3d_pl/status/1689702885435543552

...and given 524 votes, 52% of people do not care, 28% wants it to follow child and 19% wants it to follow parent.

In the end, you can set it up however you want in your ~/.gdbinit file by adding set follow-fork-mode <value> there (child or parent). So please, set it up as you want and have it working :).

Maybe we should improve the UX and make it more clear that this is set? Or, ask the users about certain settings during installation?

We do have a tip that can be randomly displayed when starting Pwndbg about this: https://github.com/pwndbg/pwndbg/blob/dev/pwndbg/lib/tips.py#L11. Shall we maybe change it to make it more clear that we do reconfigure it?

[disconnect3d]

EDIT: Nope, it does not have it. It maybe had it in the past; this text here is from old documentation page

Oh lol I just realized GDB has this "ASK" mode:

set follow-fork-mode mode
Set the debugger response to a program call of fork or vfork. A call to fork or vfork creates a new process. The mode can be:
parent
The original process is debugged after a fork. The child process runs unimpeded. This is the default.
child
The new process is debugged after a fork. The parent process runs unimpeded.
ask
The debugger will ask for one of the above choices.

How does this work?

[disconnect3d]

pwndbg> set follow-fork-mode ask
Undefined item: "ask".
pwndbg> version
Gdb:      13.1
Python:   3.11.4 (main, Dec  7 2023, 15:43:41) [GCC 12.3.0]
Pwndbg:   2024.02.14 build: 2cb8a4e0
Capstone: 5.0.1280
Unicorn:  2.0.1

Must have been added in GDB 14.x? Eh, its changelogs doesn't really say much about it.

[disconnect3d]

pwndbg> set follow-fork-mode ask
Undefined item: "ask".
pwndbg> version
Gdb:      14.1
Python:   3.11.7 (main, Dec  4 2023, 18:10:11) [GCC 13.2.0]
Pwndbg:   2024.02.14 build: 5d5eac93
Capstone: 5.0.1280
Unicorn:  2.0.1

GDB 14.1 also doesn't have it. Was this added in 14.2 or is it upcomming for 15.x?

[disconnect3d]

The GDB 14.2 does not seem to have this:
https://github.com/bminor/binutils-gdb/blob/gdb-14.2-release/gdb/infrun.c#L408-L415

[disconnect3d]

Uhm, that "ask" option was removed from documentation in 2004: bminor/binutils-gdb@b51970a (thx vries from liberachat/#gdb for pointing this out).

[cclamb]

So much for this detail and context! On reflection, it does seem like this is a more complicated issue than I originally thought! Perhaps giving the user the option to follow the child or the parent at the time of divergence would be more intuitive? Or perhaps a message describing the choice, made by default and how the user can circumvent that particular default at fork? - c. (Mspellngs courtesie of ipad)

…

On Wed, Mar 6, 2024 at 7:42 AM Disconnect3d ***@***.***> wrote: It is not a loss of functionality. It is a deliberate choice we have made at some point and I wondered many times if we should set that GDB parameter back or not. I even made a poll on Twitter about it: https://twitter.com/disconnect3d_pl/status/1689702885435543552 ...and given 524 votes, 52% of people do not care, 28% wants it to follow child and 19% wants it to follow parent. In the end, you can set it up however you want in your ~/.gdbinit file by adding set follow-fork-mode <value> there (child or parent). So please, set it up as you want and have it working :). Maybe we should improve the UX and make it more clear that this is set? Or, ask the users about certain settings during installation? We do have a tip that can be randomly displayed when starting Pwndbg about this: https://github.com/pwndbg/pwndbg/blob/dev/pwndbg/lib/tips.py#L11 Shall we maybe improve it as well? — Reply to this email directly, view it on GitHub <#2062 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5JB7RFRALX6SL7F45X2LYW4TMHAVCNFSM6AAAAABEH53M76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRGAZDEOBUGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cclamb]

This was supposed to say “thank you so much“ :-) - c. (Mspellngs courtesie of ipad)

…

On Wed, Mar 6, 2024 at 8:05 AM Chris Lamb ***@***.***> wrote: So much for this detail and context! On reflection, it does seem like this is a more complicated issue than I originally thought! Perhaps giving the user the option to follow the child or the parent at the time of divergence would be more intuitive? Or perhaps a message describing the choice, made by default and how the user can circumvent that particular default at fork? - c. (Mspellngs courtesie of ipad) On Wed, Mar 6, 2024 at 7:42 AM Disconnect3d ***@***.***> wrote: > It is not a loss of functionality. It is a deliberate choice we have made > at some point and I wondered many times if we should set that GDB parameter > back or not. > > I even made a poll on Twitter about it: > https://twitter.com/disconnect3d_pl/status/1689702885435543552 > > ...and given 524 votes, 52% of people do not care, 28% wants it to follow > child and 19% wants it to follow parent. > > In the end, you can set it up however you want in your ~/.gdbinit file > by adding set follow-fork-mode <value> there (child or parent). So > please, set it up as you want and have it working :). > > Maybe we should improve the UX and make it more clear that this is set? > Or, ask the users about certain settings during installation? > > We do have a tip that can be randomly displayed when starting Pwndbg > about this: > https://github.com/pwndbg/pwndbg/blob/dev/pwndbg/lib/tips.py#L11 > > Shall we maybe improve it as well? > > — > Reply to this email directly, view it on GitHub > <#2062 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAB5JB7RFRALX6SL7F45X2LYW4TMHAVCNFSM6AAAAABEH53M76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRGAZDEOBUGE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >