On Thu, Jun 14, 2007 at 08:01:31PM +0400, Eugene Prokopiev wrote:
> # ulimit -c 10000000000
> # cp -a 
> /data/build/hasher-callweaver/chroot/usr/src/RPM/BUILD/callweaver-1.1.99.20070614/ 
> .
> # cd callweaver-1.1.99.20070614
> # LD_LIBRARY_PATH=/usr/lib/debug:$PWD gdb .libs/callweaver
> GNU gdb 6.6-alt1 (ALT Linux)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "x86_64-alt-linux"...
> Using host libthread_db library "/lib64/libthread_db.so.1".
> (gdb) run -vvvvvcd
> ...
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1092139328 (LWP 24377)]
> 0x00002afca9067cc4 in strncpy () from /lib64/libc.so.6
> (gdb) quit
> The program is running.  Exit anyway? (y or n) y
> 
> И где теперь сам дамп? В текущем каталоге ничего подозрительного нет.

gdb перехватывает SIGSEGV до создания дампа (но в таком варианте дамп
и не нужен - после SIGSEGV можно изучать через gdb состояние ещё
живого процесса, а не восстановленное из дампа, которое может быть уже
неполным).  Вот если запускать программу напрямую (без gdb), должен
создастся дамп (но опять-таки при условии, что программа не пытается
обработать SIGSEGV самостоятельно).

Ещё одни возможные грабли: обычно дамп пишется в текущий каталог
процесса - если выполнялись вызовы chdir(), дамп может оказаться не
там, где ожидалось (либо вообще не создастся, если запись в каталог
оказалась запрещена).  Подобная ситуация может возникать при отладке
демонов; в таких случаях можно писать в kernel.core_pattern абсолютный
путь (и добавить, например, ".%p", чтобы имя файла зависело от pid).