У меня тоже была эта проблема, но я редко использую GDB в KDevelop, что меня еще не беспокоило. Вот мой журнал попыток исправить это:
Просмотр исходного кода GDB 7.3.1 показывает, что это сообщение печатается, когда GDB пытается установить свой главный TTY на вновь созданный псевдо-tty (см. Gdb / inflow.c, строки 683-740). В частности, вызов ioctl с запросом TIOCSCTTY завершается с ошибкой прав доступа.
Имея это в виду, я взглянул на исходный код ядра Linux, чтобы понять, что может вызвать сбой. Немного поиска показывает, что он в конечном итоге выродится в вызов tiocsctty (). Важный комментарий от tiocsctty:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Поскольку единственная другая причина, по которой он может потерпеть неудачу с EPERM, - это если tty, который создает GDB, на самом деле является контрольным tty для другого процесса (что весьма маловероятно), я счел разумным предположить, что GDB не лидер сессии. Вполне справедливо, что он запущен KDevelop в конце концов!
Итак: я пытался не запускать сеанс GDB во внешнем терминале, и он работает. Проблема сузилась.
Первоначально внешняя линия терминала была установлена на konsole --noclose --workdir %workdir -e %exe. Изменение этого значения на terminator -e %exe немного изменило: KDevelop предупредил меня, что
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
Я проверил свои разрешения; мой пользователь был частью группы tty, и все соответствующие файлы были доступны для чтения и записи.
Просмотр исходного кода KDevelop показывает, как KDevelop фактически настраивает терминал. Он запускает скрипт оболочки
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
и затем настраивает GDB на использование терминального устройства, которое оно считывает из FIFO_PATH. (Кстати, мое имя не то, которое использует KDevelop.) Проблема (насколько я могу судить) состоит в том, что gdb не запускается как дочерний элемент сценария оболочки и поэтому не может использовать его в качестве основного tty.
Я пока не чувствую, что исправляю KDevelop, чтобы заставить эту работу работать должным образом (или вначале не могу найти причину, по которой это перестало работать ...), поэтому лучшее, что я могу предложить сейчас, это просто не используйте внешний терминал для отладки.
Удачи! Я обновлю, если найду что-нибудь полезное.