gdb output problems when run in shell (bash or ksh)

gdb output problems when run in shell (bash or ksh)

[Klaus Zeitler]

Hello,

I'm trying to debug a program with more than 100 threads under Solaris 5.8,
that generates lots of output. When I run the program under gdb in bash,
the first few threads are started, then gdb suspends itself and I need to
call 'fg' to resume execution, i.e. the whole thing looks like e.g.:

[674]$ gdb ./umc.vx 
GNU gdb 6.3.0.20050704-cvs
...
[New LWP 27]
UMC1-1-> [07-05 10:05:41:932930] (tMain      ) : Smdev: SMDEV initialization succeeded!
[New LWP 28]
logMsg [07-05 10:05:42:849879] (FireWire   ) : PetDemon create Server socket on port 45263
UMC1-1-> [07-05 10:05:42:870024] 0x13dd7d0  (tFtpdTask  ) : waiting for a new client connection...
UMC1-1-> [07-05 10:05:42:981463] 0x7277b0   (tMain      ) : Initializing OSipc

[6]+  Stopped                 gdb ./umc.vx
[675]$ fg
gdb ./umc.vx
---Type <return> to continue, or q <return> to quit---
[New LWP 29]
logMsg [07-05 10:20:36:924936] (nbapDemon  ) : PetDemon create Server socket on port 45260
...


When run in ksh, gdb isn't put in background. Instead after quite a few lines
of output from the image interspersed with gdb output lines "[New LWP <nn>]",
ksh seems to hang. Top then shows that both gdb and ksh are both running at
approximately 50% CPU.

But when I run the program in emacs or ddd, I don't have any problems.  Since
this always happens while gdb is trying to print more than 200 times "[New LWP
<nn>]", maybe we have a problem with both gdb and the image printing at the
same time.

I'd appreciate any help. Thanks

Klaus

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
Our policy is, when in doubt, do the right thing.
    -- Roy L. Ash, ex-president Litton Industries

Re: gdb output problems when run in shell (bash or ksh)

[Andreas Schwab]

Klaus Zeitler <kzeitler@lucent.com> writes:

> I'm trying to debug a program with more than 100 threads under Solaris 5.8,
> that generates lots of output. When I run the program under gdb in bash,
> the first few threads are started, then gdb suspends itself and I need to
> call 'fg' to resume execution, i.e. the whole thing looks like e.g.:

Does this patch help?

2005-08-02  Andreas Schwab  <schwab@suse.de>

	* sol-thread.c (sol_thread_wait): Call target_terminal_ours before
	printing output.

--- gdb/sol-thread.c.~1.50.~	2005-06-27 10:03:40.000000000 +0200
+++ gdb/sol-thread.c	2005-08-02 13:46:35.000000000 +0200
@@ -463,6 +463,7 @@ sol_thread_wait (ptid_t ptid, struct tar
 	  && !ptid_equal (rtnval, save_ptid)
 	  && !in_thread_list (rtnval))
 	{
+	  target_terminal_ours ();
 	  printf_filtered ("[New %s]\n", target_pid_to_str (rtnval));
 	  add_thread (rtnval);
 	}

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb output problems when run in shell (bash or ksh)

[Klaus Zeitler]

>>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:
    Andreas> 
    Andreas> Does this patch help?
    Andreas> 
    Andreas> 	* sol-thread.c (sol_thread_wait): Call target_terminal_ours before
    Andreas> 	printing output.
    Andreas> 
    Andreas> --- gdb/sol-thread.c.~1.50.~	2005-06-27 10:03:40.000000000 +0200
    Andreas> +++ gdb/sol-thread.c	2005-08-02 13:46:35.000000000 +0200
    Andreas> @@ -463,6 +463,7 @@ sol_thread_wait (ptid_t ptid, struct tar
    Andreas>  	  && !ptid_equal (rtnval, save_ptid)
    Andreas>  	  && !in_thread_list (rtnval))
    Andreas>  	{
    Andreas> +	  target_terminal_ours ();
    Andreas>  	  printf_filtered ("[New %s]\n", target_pid_to_str (rtnval));
    Andreas>  	  add_thread (rtnval);
    Andreas>  	}

What a quick reply. Your patch didn't help, but if gave me an idea where to
look. I searched for other calls of 'printf_filtered ("[New %s]\n"' (11
matches) and it worked, when I added the call to target_terminal_ours in
module procfs.c to the first occurrence of 'printf_filtered ("[New %s]\n"':

		    if (!in_thread_list (temp_ptid))
		      {
			  target_terminal_ours ();
			printf_filtered ("[1:New %s]\n",
					 target_pid_to_str (temp_ptid));
			add_thread (temp_ptid);
		      }

A closer look revealed that the problem is caused by prompt_for_continue in
fputs_maybe_filtered. It seems as if gdb counts the 'New thread' messages
and prompts for continuation according to page height.
When I set page height in gdb to 0, the problem also disappears.

Thanks

Klaus


-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
Real programmers don't comment their code.  It was
hard to write, it should be hard to understand.