Intereting Posts
Несколько ключей SSH – без идентификации Наличие нескольких компьютеров в файле доступа к сети? Поиск решения для настройки обратного прокси для игровых серверов Двойная загрузка Windows 10 + Проблемы с Debian Извлечение загрузки из вывода свернуть Как восстановить данные TrueCrypt? xrandr, xorg test screen error – по умолчанию используется только допустимый режим Именованные трубы: несколько экспериментов приводят к путанице Как передать массив функции как действительный параметр, а не глобальную переменную Какие оболочки использовались в ранних системах Unix? Поиск строки, с успехом Поиск ближайшего шаблона Команда для установки заголовков Linux не выполняется Где я могу найти список кодов терминальных клавиш для переназначения ярлыков в bash? Где находятся / scripts / local-top и / scripts / local-premount? Доступ к файлу в PHP через символическую ссылку от пользователя, который обычно не имеет разрешения

GDB не может выполнить мою тестовую программу

Мой компьютер работает с Ubuntu 14.04. GDB кажется ненормальным в разных аккаунтах. Например, я делаю очень простой тест. Я пишу файл под ~/test/test.c следующим образом:

 #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { printf("hello,world"); return 0; } 

и построить с помощью команды «gcc -g test.c -o test» , тогда я получаю файл с результатом test. Следующий шаг, запустите gdb для отладки. Обратите внимание, что текущая учетная запись является пользователем моей.

 $gdb test (gdb)l //work well (gdb) b 6 //work well (gdb) r //error: Cannot exec /home/xxx/test/test -c exec /home/xxx/test/test . //Error: No such file or directory 

Но если я перейду на корневую учетную запись командой «su», gdb работает хорошо. Зачем?

По-видимому, ваша переменная SHELL установлена ​​в файл, который не существует. Попробуйте следующее:

 export SHELL=/bin/sh gdb test 

что /bin/sh существует и является исполняемым. Это работает через su не из-за прав root, а потому, что su сбрасывает переменную окружения SHELL . На странице руководства пользователя su :

Обратите внимание, что поведение по умолчанию для среды следующее:

Сбрасываются переменные среды $ HOME, $ SHELL, $ USER, $ LOGNAME, $ PATH и $ IFS.

Дальше Обсуждение

Если вы спрашиваете себя: «Как я должен был знать это из следующего сообщения об ошибке?»:

 //error: Cannot exec /home/xxx/test/test -c exec /home/xxx/test/test . //Error: No such file or directory 

Ты не одинок. Это, по-видимому, плохое сообщение об ошибках из gdb . Когда gdb решает, что ему нужно выполнить команду с помощью оболочки, она создает команду в следующем формате:

 /path/to/shell -c exec /path/to/executable 

Однако, когда он печатает сообщение об ошибке, он делает следующее:

  save_errno = errno; fprintf_unfiltered (gdb_stderr, "Cannot exec %s", exec_file); for (i = 1; argv[i] != NULL; i++) fprintf_unfiltered (gdb_stderr, " %s", argv[i]); fprintf_unfiltered (gdb_stderr, ".\n"); fprintf_unfiltered (gdb_stderr, "Error: %s\n", safe_strerror (save_errno)); gdb_flush (gdb_stderr); 

Здесь exec_file – это расширенный путь файла, который вы передали в командной строке. exec_file он печатает exec_file , а затем элементы argv , начиная с 1-го индекса. argv содержит аргументы, которые он передал execvp .

К сожалению, оболочка, которую она пытается использовать, находится в 0-м элементе argv , который никогда не печатается. Таким образом, вы никогда не увидите файл, который не удалось найти execvp .

Затем он печатает конечный результат . который на самом деле не является одним из аргументов, которые он передал execvp и предположительно там, чтобы сделать сообщение полным предложением.

Наконец, он печатает ошибку, которую мы получили от нашего вызова execvp , а это значит, что исполняемый файл не найден.

Вероятно, эта ошибка вызвана тем, что этот код обработки ошибок одинаковый для случая, когда gdb пытается выполнить команду напрямую и для случая, когда она использует оболочку. В первом случае построенное сообщение об ошибке будет выглядеть корректно, поскольку exec_file и argv[0] будут одинаковыми.