Re: tui/1703: the run command suspends gdbtui

[Joshua Neuheisel <joshua at neuheisel dot us>]

The following reply was made to PR tui/1703; it has been noted by GNATS.

From: Joshua Neuheisel <joshua@neuheisel.us>
To: gdb-prs@sources.redhat.com,
 green@redhat.com,
 gdb-gnats@sources.redhat.com,
 nobody@sources.redhat.com
Cc:  
Subject: Re: tui/1703: the run command suspends gdbtui
Date: Sat, 4 Dec 2004 08:52:10 -0500

 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gdb&pr=1703
 
 I'm just an average gdb user, but this bug has been bothering me for a  
 while, so I decided to trace it.  If we run gdbtui as "gdbtui ./a.out",  
 gdbtui starts and finds its way into the function tui_init which calls
 
 atexit (tui_exit);
 
 This will be important later.
 
 Now we fork/exec a.out, and the original gdbtui process is now no  
 longer in the foreground process group.  Now we find our way into  
 linux_test_for_tracefork, where we fork.  The child calls  
 linux_tracefork_child which calls ptrace, kill, fork, and exit.  The  
 problem here is the "exit" call.  Due to the atexit call above,  
 tui_exit is called during the "exit" call.  This calls the curses  
 function "endwin" which tries to write escape codes to the terminal.   
 This causes a SIGTTOU to be sent to the process group, thereby stopping  
 our original gdbtui.
 
 The fix here seems simple:  the exit call in linux_tracefork_child  
 should be an "_exit" call instead.  There's no reason for calls  
 registered with atexit to execute here, since this was just a  
 "temporary" fork for testing purposes only.
 
 I hope this helps someone.  I really enjoy using gdbtui...
 
 Joshua Neuheisel
 joshua@neuheisel.us