O GDB trava permanentemente no Solaris

3

O GDB parece travar toda vez que eu tento o comando run do prompt do gdb. Quando executei ps , existem dois processos gdb que foram gerados e pstack revela o seguinte -

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

Por que esses processos estão suspensos em vfork e execve ? Isso acontece na minha máquina universitária, onde colegas também têm contas. Nenhum deles relatou esse problema. Parece acontecer apenas comigo.

EDITAR : Com a ajuda de schily , sou capaz de resolver o problema. Quando faço o login, estou em csh por padrão. O GDB funciona muito bem aqui. Agora, executo bash de csh para inserir o shell bash. Agora o GDB trava. Quando eu verifico a saída de echo $SHELL , vejo algo estranho

$ echo $SHELL
 /bin/bash=

Existe um sinal de igual no final da saída. Eu acho que o GDB está tentando gerar um shell bash eu acho que usando a variável de shell padrão e não consegue encontrar o cos binário desse sinal de igual. Agora, o problema é descobrir como esse sinal de igual está entrando no caminho do shell.

    
por Pavan Manjunath 20.10.2015 / 21:53

1 resposta

2

O processo que chama vfork() trava porque é o vfork() parent e o filho emprestou a imagem do processo nesse momento para que não seja executado até que o filho termine uma chamada para _exit() ou exec*() .

Então você precisa descobrir por que o exec * () trava.

Uma razão típica para um travamento no exec * () é um travamento do NFS ou uma travessia através de um ponto de montagem automática inexistente.

Chame truss -p 13079 para obter o caminho para o executável pendente * ().

    
por 20.10.2015 / 23:51