gdb очень долго стартует программу

(gdb) r < тут по нажатию enter затыкается

А у меня нет, где и как искать причину?

perf record -- gdb TEST, потом perf report. Если тяжело в консоли смотреть, то http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

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

  14,65%  gdb         [kernel.kallsyms]    [k] do_syscall_64
  11,11%  gdb         gdb                  [.] bfd_calc_gnu_debuglink_crc32
   5,99%  gdb         [kernel.kallsyms]    [k] syscall_return_via_sysret
   5,98%  gdb         gdb                  [.] read_attribute_value
   5,77%  gdb         [kernel.kallsyms]    [k] entry_SYSCALL_64

Хм, а если ему сделать gcore в течении этих секунд именно? Не уверен правда как поведёт себя ptrace приложения которое выполняет ptrace, но, возможно до этого момента дело ещё и не доходит?

На всякий случай - забэкапь систему если интересно дорыться до причин, у меня не воспроизводится например.

у меня на двух воспроизводится (эта 1910 и еще 1604) и на двух нет (1904 и 1910) вторые почти чистые, а первые более рабочие

Хм, а если ему сделать gcore в течении этих секунд именно?

Корку создал такую:

#0  0x00007f04e2034616 in __libc_sigaction (sig=sig@entry=11, act=act@entry=0x7ffc878e0810, oact=oact@entry=0x0) at ../sysdeps/unix/sysv/linux/sigaction.c:58
#1  0x00007f04e2034749 in __sigaction (sig=sig@entry=11, act=act@entry=0x7ffc878e0810, oact=oact@entry=0x0) at ../nptl/sigaction.c:30
#2  0x0000563e5da75bc4 in gdb_demangle (name=0x563e60a933e0 "Qt::ThresholdAlphaDither", options=3) at cp-support.c:1550
#3  0x0000563e5da76112 in gdb_sniff_from_mangled_name (mangled=<optimized out>, demangled=0x7ffc878e0908) at cp-support.c:1599
#4  0x0000563e5dc60442 in symbol_find_demangled_name (mangled=0x563e60a933e0 "Qt::ThresholdAlphaDither", gsymbol=0x7ffc878e0990) at symtab.c:768
#5  symbol_set_names (gsymbol=gsymbol@entry=0x7ffc878e0990, linkage_name=linkage_name@entry=0x563e60a933e0 "Qt::ThresholdAlphaDither", len=len@entry=24, copy_name=copy_name@entry=1, 

обратил внимание, что именно строки

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Корок - лучше несколько снять, по ним можно будет понять корень который зациклился. Если корни совпадают то дело в шляпе, дальше только сорцы поглядеть.

Ещё один момент - убедись, что поток не один там, а то может другой поток процессор жгёт.

Хочу так же заметить - ПО не такое уж и простое, проверь для начала на хеллоуворлде. Ибо, судя по тому, что я вижу - у тебя отладочная версия Qt подцепилась, а символов там мягко говоря дохрена, и пока они все не считаются отладка не начнётся.

да, это на qt простейшая прога (одно окно и пара кнопок), онаже на других компах без проблем отлаживается попробую завтра совсем простую программу

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

Так а чего непонятного-то? read_attribute_value и do_syscall_64 говорит о том, что много SYS_read делается, а bfd_* - что read’ы эти на объектных файлах. Можешь ещё strace -e open gdb запустить, и там наверняка мильон файлов открывается.

да, это на qt простейшая прога (одно окно и пара кнопок), онаже на других компах без проблем отлаживается попробую завтра совсем простую программу

На одном стоит кутешные дебагинфо, на другом - нет. Как вариант, на том, где всё плохо, куте ручками собрана, и на ФС мильон объектных файлов, которые gdb шерстит в поисках дебагинфы.

Это на любой программе воспроизводится? Даже на такой?

#include <stdio.h>
int main(void) {
  printf("Hello\n");
  return 0;
}

Можешь ещё strace -e open gdb запустить, и там наверняка мильон файлов открывается.

ок, проверю, но я думал, что дебуг-инфа грузится _до_ запуска программы

strace без параметров уже запускал, множество чегото типа sigaction было, но не open

да qt собрана руками, но пробовал и системным qt собирать перепроверю еще раз

дебуг-инфа грузится до запуска программы

Программа может загружать библиотеки во время работы. И тогда gdb не может загрузить отладочную информацию заранее.

Программа может загружать библиотеки во время работы.

хм, да, но именно эта программа не загружает сама что либо еще явно

вообще проблема изначально была иная: большая программа вообще не останавливалась (я не дожидался) на точку останова - gdb стартовал (также долго), но висел в 100% загрузке процессора при «вот-вот срабатывании» точки останова. возможно где то тут есть связь.

вообще не останавливалась

Никогда не видел, чтобы подобное подвисание длилось больше минуты. Возможно, ты наткнулся на какой-то баг.

использую printf, будь мужиком

int main(void)

эта минимальная не тормозит

strace -e open gdb

хм в логе только десяток строки вида

--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=6401, si_uid=1000, si_status=SIGTRAP, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=6401, si_uid=1000, si_status=SIGTRAP, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=6402, si_uid=1000, si_status=SIGSTOP, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_TRAPPED, si_pid=6402, si_uid=1000, si_status=SIGTRAP, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=6403, si_uid=1000, si_status=SIGKILL, si_utime=0, si_stime=0} ---

разобрался, как и подсказали, - грузились debug символы типа libQt5Core.so.5.12.2.debug, которые собирались вместе с qt (сам уже не помню зачем я их собирал)

-f добавь

хм, ругается так

strace: Process 10136 attached
[pid 10136] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10136, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
strace: Process 10137 attached
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
[pid 10137] +++ exited with 127 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10137, si_uid=0, si_status=127, si_utime=0, si_stime=0} ---
During startup program exited with code 127.
+++ exited with 0 +++

интернеты пишут надо сделать

sudo sysctl -w kernel.yama.ptrace_scope=0
sudo setcap cap_sys_ptrace=eip /usr/bin/gdb

но не помогает

Было недавно на лоре, что ptrace процесса который уже под ptrace - запрещён. А один из форков - тадамс, таки трейсится.

т.е. никак или я не понял ответа ?

Никак насколько я знаю, если кто-то знает лучше - поправьте.

Подтверждаю опыт с кутэ. Отладочные либы дропни (или указывай релизные при сборке), они в гдб годами грузятся, там сотни мегабайт живого веса говна.

Отладочные либы дропни

да, так и сделал, всю тему я это долго соображал, вот если бы gdb где нибудь вывел строку типа «гружу либу такую то», я быстрее сообразил бы )