Понять выход gdb в случае segfault

Question

У меня есть segfault в моей программе. Я пытаюсь использовать backtrace команду gdb, чтобы найти ошибку, но, к сожалению, я не понимаю его выход:

(gdb) bt 
#0 0x00007ffff1678480 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#1 0x00007ffff171c11e in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#2 0x00007ffff17e565f in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#3 0x00007ffff17432e3 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#4 0x00007ffff16580bf in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#5 0x00007ffff179e758 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#6 0x00007ffff173cea8 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#7 0x00007ffff6b8770a in start_thread (arg=0x7fffef352700) at pthread_create.c:333 
#8 0x00007ffff68bd82d in clone() at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 

Кто-нибудь знает, где происходит от выдаёт ошибку сегментации? Например, почему метод main не указан в выводе backtrace?

Answer 1

Кто-нибудь знает, откуда возникает segfault?

Да: GDB сказал вам, где это происходит от: безымянного функции по адресу 0x7ffff1678480 внутри libnvidia-opencl.so.1

Например, почему основной метод не указан в выходе трассировку в?

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

Итак, что делать?

Существует почти ничего, что вы можете сделать может сделать это, потому что вы используете предоставленную поставщиком и полностью непрозрачную библиотеку.

Вы должны идти по любой OpenCL вызывает ваша программа делает (при условии, что делает любой) и убедитесь, что аргументы, которые Вы обеспечиваете действительны и удовлетворяют требованиям API OpenCL.

Вы также должны сделать (gdb) thread apply all where, чтобы увидеть, где находятся другие темы. Возможно, ваш основной поток выходит, не закрывая OpenCL.

Вы также можете попробовать запустить свою программу с другой (возможно, более низкой) версией OpenCL с открытым исходным кодом (например, pocl). IF авария воспроизводится с pocl, вам будет намного легче понять, что пошло не так, как вы можете проверить источник, и GDB сообщит вам точно, где в источнике возникла проблема.

Answer 2

Начиная снизу и работать вверх:

#8 0x00007ffff68bd82d in clone() at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 

Я вижу функцию под названием clone. Я печатаю man clone и получаю что-то вроде this.

Четвертый абзац

Одним из вариантов использования клона() заключается в реализации темы: несколько потоков управления в программе, которые работают параллельно в общем пространстве памяти.

который кажется уместным, когда я смотрю на следующем кадре стека

0x00007ffff6b8770a in start_thread (arg=0x7fffef352700) at pthread_create.c:333 

где я вижу функцию под названием start_thread в модуле pthread_create. Хмм, нить, нить, я видел это слово где-то раньше. Я помню pthread_create где-то раньше, так что тип man pthread_create ...

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

Обратите внимание, что вы можете ввести info threads, чтобы посмотреть, что другие потоки были запущены в момент возникновения неисправности, и thread 1 (или любой другой номер), чтобы переключиться на другой поток и исследовать его стек.