Файл ядра отладки без символов

For the future:

1. Make sure that you always build with an external symbols database (this is not a debug build -- it's a release build, but you store the symbol table separately)
2. keep it around for versions you deploy

For this situation:

You know the general area, so to see if you are right, go to the stack trace and find the assembly code -- eyeball it and see if you think it matches your source (this is easier if you have some idea what source generated this assembly). If it looks right, then you have some verification on your hypothesis. You might be able to figure out the values of the local variables by looking at the stack (since you know what you passed in and declared).

1. Всегда использовать систему контроля версий (CVS / GIT / Subversion / и т.д.), даже для тестовых выпусков
2. Тег все выпуски
3. Учитывать (в future), создавая сборку с отладкой (-g) и удаляя исполняемый файл перед отправкой. ПРИМЕЧАНИЕ. Не создавайте две сборки с -g и без него; они вполне могут не совпадать, поскольку -g может иногда вызывать генерацию другого кода даже на одном уровне оптимизации. В критически важном для производительности коде вы можете отказаться от опции -g для критических файлов - в большинстве случаев это не имеет значения.
4. Если вы действительно застряли, сбросьте стек и выгрузите соответствующие части кучи в шестнадцатеричный и посмотрите на это вручную; возможно, взяв инструментальную копию и ища похожие «подписи» в сгенерированном коде и в стеке. Это настоящая "старая школа" отладки ... : -)

Do you have the exact source that you used to compile the old version (eg; through a tag in the source tree or something like that)? Maybe you could rebuild using that, and possibly get an insight into where the crash occured?

There is not much information here. The binary is stripped.But looking at segmentation fault...you should look for places where there is a possibility that you are overwriting a piece of memory.

This is just a suggestion. There can be many problems.

BTW, if you are not able to reproduce in your local machine then the volume of data on customers' might be a problem.

В gdb "информационные регистры" должны предоставить вам достаточно состояние выполнения на момент сбоя для использования с дизассемблированием исполняемого файла и соответствующих разделяемых библиотек. Обычно я использую objdump для дизассемблирования, перенаправления вывода в файл, а затем вызываю файл в моем любимом редакторе - это полезно для ведения заметок, когда все выясняется. Также gdb "info target" и "info sharedlib" могут быть полезны для определения того, где загружаются разделяемые библиотеки.

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

Я не думаю, что основной файл должен содержать символы. Вам необходимо создать версию своей программы, которая точно такая же , что и та, которую вы отправили своему клиенту, но с параметром -g. Если вы удалите исполняемый файл отладки, он должен быть идентичен поставляемой версии. Только тогда GDB сможет дать вам что-нибудь полезное.

Попробуйте запустить «pmap» для файла ядра (если в hp / ux есть этот инструмент). Это должно сообщить начальные адреса всех модулей в основном файле. Имея эту информацию, вы сможете узнать адрес места сбоя и выяснить, какая библиотека потерпела крах. Дальнейшее сравнение адресов между адресом сбоя и адресами известных функций в библиотеке («nm» по сравнению с библиотекой должно получить это) может помочь вам определить, какая функция потерпела крах.

Даже если вам удастся идентифицировать функцию в на вершине стека, маловероятно, что эта функция является источником проблемы ... надеюсь, она действительно вызвала сбой в вашем коде, а не, скажем, в стандартной строковой библиотеке C. Перестроение трассировки стека - следующая лучшая вещь на этом этапе.