GDB вечно вешается на Solaris

Кажется, что GDB зависает каждый раз, когда я пытаюсь run команду из подсказки gdb. Когда я запускал ps , есть два процесса gdb, которые были порождены, и pstack показывает следующее:

 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 

Почему эти процессы висят в vfork и execve ? Это происходит на моей университетской машине, где у сокурсников есть счета. Никто из них не сообщил об этой проблеме. Кажется, случается только со мной.

EDIT : С помощью схилий , я могу углубить проблему. Когда я вхожу в систему, я по умолчанию находится в csh . GDB работает очень хорошо. Теперь я запускаю bash из csh чтобы войти в оболочку bash. Теперь GDB висит. Когда я проверяю вывод echo $SHELL , я вижу что-то странное

 $ echo $SHELL /bin/bash= 

В конце вывода есть знак равенства. Я предполагаю, что GDB пытается породить оболочку bash, я думаю, используя переменную оболочки оболочки и не может найти двоичный cos этого знака равенства. Теперь проблема заключается в том, чтобы узнать, как этот знак равенства попадает в путь оболочки.

One Solution collect form web for “GDB вечно вешается на Solaris”

Процесс, вызывающий vfork() зависает, потому что он является vfork() parent и ребенок в это время заимствовал образ процесса, поэтому он не может работать до тех пор, пока ребенок не завершит вызов _exit() или exec*() .

Поэтому вам нужно выяснить, почему стоит exec * ().

Типичной причиной зависания в exec * () является зависание NFS или обход через несуществующую точку автомата.

Вызовите truss -p 13079 чтобы получить путь для висячего exec * ().

  • Настройка точек останова удаленно с помощью gdb / gdbserver
  • Conque-GDB in vim: как установить размер
  • Как запустить GDB в фоновом режиме и вернуть его обратно?
  • что обрабатывает SIG33 pass nostop noprint`, когда используется в gdb
  • разрешение отклонено для ptrace под GDB
  • Ошибка при установке gdb-arm-linux-gnueabi
  • Ядро процесса сброса, не убивая процесс
  • Как заставить gdb не спрашивать меня «y или n»?
  • Удаление GDB на Mac
  • есть ли способ узнать, присутствуют ли сигналы в вашем приложении и какие сигналы есть?
  • QEMU для программ ARM с GDB
  • Linux и Unix - лучшая ОС в мире.