3

GDB seems to hang everytime when I try run command from gdb prompt. When I ran ps, there are two gdb processes that have been spawned and pstack reveals the following -

15:47:02:/home/stufs1/pmanjunath/a2/Asgn2_code$ uname -a
SunOS compserv1 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Blade-1500

15:44:04:/home/stufs1/pmanjunath/a2/Asgn2_code$ ps aux | grep gdb
pmanjuna 13121  0.1  0.1 1216  968 pts/23   S 15:44:11  0:00 grep gdb
pmanjuna 13077  0.0  0.1 7616 4392 pts/15   S 15:41:41  0:00 gdb client
pmanjuna 13079  0.0  0.1 7616 4392 pts/15   T 15:41:51  0:00 gdb client

15:44:50:/home/stufs1/pmanjunath/a2/Asgn2_code$ pstack 13077
13077:  gdb client
 fef42c30 vfork    ()
 00065938 procfs_create_inferior (32ea10, 32d728, 317430, 1, 0, 657a8) + 190
 0008c668 sol_thread_create_inferior (32ea10, 32d728, 317430, 1, 25e030, 0) + 18
 000ffda0 find_default_create_inferior (32ea10, 32d728, 317430, 1, 405c, 4060) + 20
 000d8690 run_command_1 (0, 1, 32ea10, 1, ffbff0f4, 316fd0) + 208
 0007e344 do_cfunc (316fd0, 0, 1, 1, 0, 0) + c
 0008016c cmd_func (316fd0, 0, 1, 0, 1, 0) + 30
 0004c1d4 execute_command (316fd0, 1, 0, 4f00c, 1, 2dc800) + 390
 000eb6a0 command_handler (2f4ee0, 0, 2f3800, 8acf, ff000000, ff0000) + 8c
 000ebbcc command_line_handler (2f3800, 7200636c, 32d71c, 7200, 2dfc00, 2dfc00) + 2a4
 0019b354 rl_callback_read_char (fef6b6f8, 0, 931d8, 0, fef68284, fef68284) + 340
 000eafb4 rl_callback_read_char_wrapper (0, fef709b0, 0, 11, 0, eafb0) + 4
 000eb590 stdin_event_handler (0, 0, 932b4, fef6fad4, 0, 1) + 60
 000ea780 handle_file_event (1, 1084, 932f4, 4f00c, ff1f2000, 1000) + bc
 000ea11c process_event (0, 0, ffffffff, 0, 2df9f8, 0) + 84
 000ea9d4 gdb_do_one_event (1, 1, 0, 2f3158, ff1f2000, 2) + 108
 000e7cd4 catch_errors (ea8cc, 0, 2473a8, 6, ffbff6f0, 1) + 5c
 000907e8 tui_command_loop (0, 64, ffffffff, 0, 0, 2f6190) + e0
 000e7fcc current_interp_command_loop (800000, ff400000, ffc00000, 800000, 0, 331b40) + 54
 00045b80 captured_command_loop (1, 1, 0, fef33a54, ff1f2000, 2) + 4
 000e7cd4 catch_errors (45b7c, 0, 22db20, 6, 2dc400, 0) + 5c
 0004625c captured_main (2d1800, 2f4ae0, 0, 0, 0, 0) + 6a0
 000e7cd4 catch_errors (45bbc, ffbffc18, 22db20, 6, 0, 0) + 5c
 00046bb0 gdb_main (ffbffc18, 0, 0, 0, 0, 0) + 24
 00045b6c main     (2, ffbffc9c, ffbffca8, 2f45b8, ff1f0100, ff1f0140) + 28
 000459dc _start   (0, 0, 0, 0, 0, 0) + 5c

15:45:38:/home/stufs1/pmanjunath/a2/Asgn2_code$ pstack 13079
13079:  gdb client
 fef4098c execve   (ffbfffe6, ffbffc9c, ffbffca8)
 feec4a7c execlp   (ffbffdc6, ffffffff, 289bc0, ffbfed18, 0, ffbfed10) + ac
 0016e3e8 fork_inferior (32ea10, 32d728, 317430, 6567c, 653dc, 0) + 310
 00065938 procfs_create_inferior (32ea10, 32d728, 317430, 1, 0, 657a8) + 190
 0008c668 sol_thread_create_inferior (32ea10, 32d728, 317430, 1, 25e030, 0) + 18
 000ffda0 find_default_create_inferior (32ea10, 32d728, 317430, 1, 405c, 4060) + 20
 000d8690 run_command_1 (0, 1, 32ea10, 1, ffbff0f4, 316fd0) + 208
 0007e344 do_cfunc (316fd0, 0, 1, 1, 0, 0) + c
 0008016c cmd_func (316fd0, 0, 1, 0, 1, 0) + 30
 0004c1d4 execute_command (316fd0, 1, 0, 4f00c, 1, 2dc800) + 390
 000eb6a0 command_handler (2f4ee0, 0, 2f3800, 8acf, ff000000, ff0000) + 8c
 000ebbcc command_line_handler (2f3800, 7200636c, 32d71c, 7200, 2dfc00, 2dfc00) + 2a4
 0019b354 rl_callback_read_char (fef6b6f8, 0, 931d8, 0, fef68284, fef68284) + 340
 000eafb4 rl_callback_read_char_wrapper (0, fef709b0, 0, 11, 0, eafb0) + 4
 000eb590 stdin_event_handler (0, 0, 932b4, fef6fad4, 0, 1) + 60
 000ea780 handle_file_event (1, 1084, 932f4, 4f00c, ff1f2000, 1000) + bc
 000ea11c process_event (0, 0, ffffffff, 0, 2df9f8, 0) + 84
 000ea9d4 gdb_do_one_event (1, 1, 0, 2f3158, ff1f2000, 2) + 108
 000e7cd4 catch_errors (ea8cc, 0, 2473a8, 6, ffbff6f0, 1) + 5c
 000907e8 tui_command_loop (0, 64, ffffffff, 0, 0, 2f6190) + e0
 000e7fcc current_interp_command_loop (800000, ff400000, ffc00000, 800000, 0, 331b40) + 54
 00045b80 captured_command_loop (1, 1, 0, fef33a54, ff1f2000, 2) + 4
 000e7cd4 catch_errors (45b7c, 0, 22db20, 6, 2dc400, 0) + 5c
 0004625c captured_main (2d1800, 2f4ae0, 0, 0, 0, 0) + 6a0
 000e7cd4 catch_errors (45bbc, ffbffc18, 22db20, 6, 0, 0) + 5c
 00046bb0 gdb_main (ffbffc18, 0, 0, 0, 0, 0) + 24
 00045b6c main     (2, ffbffc9c, ffbffca8, 2f45b8, ff1f0100, ff1f0140) + 28
 000459dc _start   (0, 0, 0, 0, 0, 0) + 5c

Why are these processes hanging in vfork and execve? This happens on my university machine where fellow students also have accounts. None of them have reported this problem. Seems to happen only to me.

EDIT : With schily's help, I am able to corner the problem. When I log in, I am in csh by default. GDB works pretty fine here. Now, I run bash from csh to enter bash shell. Now GDB hangs. When I check the output of echo $SHELL, I see something strange

$ echo $SHELL
 /bin/bash=

There is an equal sign at the end of the output. I guess GDB is trying to spawn a bash shell I guess using the default shell variable and fails to find the binary cos of that equal sign. Now, the problem is to find out how that equal sign is getting into the shell path.

  • What is the output from the env command? Do you have any LD_* environment variables set? What's the output from pmap on your hung gdb processes? Can you get a pstack of your client processes? (Maybe by using the -F option?) – Andrew Henle Oct 20 '15 at 21:43
  • Also, check /var/adm/messages for errors - both vfork() and execve() are memory-intensive. If you each have your own machines, maybe yours has a hardware problem. – Andrew Henle Oct 20 '15 at 21:49
2

The process that calls vfork() hangs because it is the vfork() parent and the child did borrow the process image at that time so it cannot run until the child finishes a call to_exit() or exec*().

So you need to find out why the exec*() hangs.

A typical reason for a hang in exec*() is a NFS hang or a traversal through a non-existent automount point.

Call truss -p 13079 to get the path for the hanging exec*().

  • Good catch. I missed the fact that the two processes are parent-child. (And FWIW, this is just one reason why I don't like vfork()...). And there's a good chance truss won't return any data in this case as it tracks system calls as they happen. System calls aren't happening here as the processes are both hung, although a truss -vall ... on the child process might emit the arguments. – Andrew Henle Oct 20 '15 at 22:01
  • truss should return the file path in the first argument. You don't need the argv in clear text. BTW: vfork() is still a good idea to increase performance. I could increase the Bourne Shell performance by 20% for configure just by replacing fork() for the simple commands by vfork(). I am currently working on using more vfork() for pipes and then will be as fast as ksh93. For a debugger, it is not useful to use vfork() instead of fork(). – schily Oct 20 '15 at 22:09
  • Your suspicion is somewhat right. As I soon as I run truss, GDB gets unstuck and says "Cannot exec /bin/bash=: No such file or directory". But truss says a different story "execve("/usr/local/bin/gdb", 0xFFBFFCAC, 0xFFBFFCB8) Err#2 ENOENT". And I confirmed this is not happening with csh only bash! Also /bin/bash is very much there – Pavan Manjunath Oct 20 '15 at 23:35
  • I cannot help you with "Cannot exec /bin/bash=: No such file or directory" you would need to check your environment (e.g. PATH) to find a possible reason. ENOENT for "/usr/local/bin/gdb"is obviously a result from PATH name search that traversed a hung NFS mount or similar automopunt point. – schily Oct 21 '15 at 9:19
  • 1
    So you have rubbish in $SHELL, I recommend to correct this. – schily Oct 22 '15 at 7:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.