Здравствуйте,

Может кто-нибудь подсказать, есть ли ограничения на размер core-файла (у меня по 420М) при загрузке в GDB?
при попытке загрузить в GDB вызовом "gdb program core_175" выдает:

GNU gdb 6.0
Copyright 2003 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 "sparc-sun-solaris2.9"...
Core was generated by `тута путя к программе'.
Program terminated with signal 11, Segmentation fault.
#0 0xff03d174 in ?? ()
(gdb) bt
#0 0xff03d174 in ?? ()
#1 0xff03c6d8 in ?? ()
#2 0xff03c434 in ?? ()
(gdb)

При падении программы сгенерировано 3 core файла по 420М с именами тип core_XXXX. Когда я пытался симулировать проблему путем вызова по адресу 0, то был сгенерирован только один core файл размером 8М, при этом он нормально загрузился в GDB и показал stack trace. При каких условиях ОС генерирует несколько больших core файлов и может ли это являться причиной проблемы загрузки их в GDB?

ОС: SunOS 5.9

Здравствуйте, Pilgrim78, Вы писали:

P>Может кто-нибудь подсказать, есть ли ограничения на размер core-файла (у меня по 420М) при загрузке в GDB?

Вряд ли. Размер ограничивается размером доступной виртуальной и физической памяти.

P>При падении программы сгенерировано 3 core файла по 420М с именами тип core_XXXX.
P>Когда я пытался симулировать проблему путем вызова по адресу 0

Более корректный вариант — abort(), но это не важно.

P>то был сгенерирован только один core файл размером 8М,

Либо программа еще не успела создать дочерних процессов, либо SEGFAULT получил только один процесс.

P>при этом он нормально загрузился в GDB и показал stack trace.

Значит в этом случае стек не был поврежден.

P>При каких условиях ОС генерирует несколько больших core файлов

Вероятно, когда программа порождает несколько процессов и они получают сигнал. А размер их зависит от того, сколько они использовали памяти.

P>и может ли это являться причиной проблемы загрузки их в GDB?

Скорее всего произошел расстрел памяти, запоровший стек — в таком случае backtrace сделать не получится.

Здравствуйте, Pilgrim78, Вы писали:

P>Здравствуйте,

P>Может кто-нибудь подсказать, есть ли ограничения на размер core-файла (у меня по 420М) при загрузке в GDB?

Именно в gdb — по идее не должно быть, но на практике я наблюдал странности подобного рода.

P>при попытке загрузить в GDB вызовом "gdb program core_175" выдает:

P>GNU gdb 6.0
P>Copyright 2003 Free Software Foundation, Inc.
P>GDB is free software, covered by the GNU General Public License, and you are
P>welcome to change it and/or distribute copies of it under certain conditions.
P>Type "show copying" to see the conditions.
P>There is absolutely no warranty for GDB. Type "show warranty" for details.
P>This GDB was configured as "sparc-sun-solaris2.9"...
P>Core was generated by `тута путя к программе'.
P>Program terminated with signal 11, Segmentation fault.
P>#0 0xff03d174 in ?? ()
P>(gdb) bt

Ну, так он нормально загрузился. Никаких проблем загрузки не видно.

P>#0 0xff03d174 in ?? ()
P>#1 0xff03c6d8 in ?? ()
P>#2 0xff03c434 in ?? ()
P>(gdb)

Ну, так всё нормально в самом gdb. А вот стек... я не знаю, как солярка распределяет память — может, эти адреса и нормальны. '??' означает отсутствие отладочной информации для диапазона в который входит этот адрес — возможно, это библиотека без отладочной информации. Или нужно явно ему сказать подгрузить отладочную информацию для библиотеки (по крайней мере на Linux/FreeBSD при динамически подгружаемых модулях это именно так).

P>При падении программы сгенерировано 3 core файла по 420М с именами тип core_XXXX.

Насколько я знаю по Linux/FreeBSD/etc., один процесс генерирует всегда только один core. Несколько может возникать только из разных процессов. У Вас явно программа падала более одного раза, а номер вместо XXXX — вероятно, pid. Хотя для солярки я не могу быть уверен в этом — может, она свалила таким образом для нескольких LWP? (Хотя нелогично всё равно)

P> Когда я пытался симулировать проблему путем вызова по адресу 0, то был сгенерирован только один core файл размером 8М, при этом он нормально загрузился в GDB и показал stack trace.

"Нормально" — это в смысле что есть названия функций? Охотно верю — Вы ведь моделировали в своём коде, а не в библиотечном, не так ли?

Здравствуйте, ДимДимыч, Вы писали:

P>>и может ли это являться причиной проблемы загрузки их в GDB?

ДД>Скорее всего произошел расстрел памяти, запоровший стек — в таком случае backtrace сделать не получится.

Либо вылет внутри системных или других библиотек собранных с оптимизацией фрейма стека, в этом случае тоже, как правило, ничего не видно. Как один из вариантов -- heap corruption, ну или там, printf попросить напечатать строку, не завершенную нулем (потерялся), в результате чего оно рано или поздно наедет на защищенную память. Отлаживать такое сложно, пожалуй только методом "разделяй и властвуй".

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Либо вылет внутри системных или других библиотек собранных с оптимизацией фрейма стека, в этом случае тоже, как правило, ничего не видно. Как один из вариантов -- heap corruption, ну или там, printf попросить напечатать строку, не завершенную нулем (потерялся), в результате чего оно рано или поздно наедет на защищенную память. Отлаживать такое сложно, пожалуй только методом "разделяй и властвуй".

Сейчас тоже начинаю склоняться к этой версии. По идее, если бы был "расстрелян" стек, то на команду bt не вывело бы:
(gdb) bt
#0 0xff03d174 in ?? ()
#1 0xff03c6d8 in ?? ()
#2 0xff03c434 in ?? ()

Может это и впрямь вылет в какой-то системной/сторонней библиотеке без отладочной информации. Можно ли как-то узнать по указанному адресу стека 0xff03d174, в какой библиотеке произошел вылет. Может есть команда просмотра по каким адресам какие модули были загружены?

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Либо вылет внутри системных или других библиотек собранных с оптимизацией фрейма стека, в этом случае тоже, как правило, ничего не видно.

Естественно. Но судя по отображаемой глубине стека всего в 3 фрейма и близости находящихся там значений, это все таки больше похоже на срыв стека, имхо. Если с elf'а не снимали отладочную информацию, то main() как минимум должна бы быть видна на дне.

Здравствуйте, Pilgrim78, Вы писали:

P>По идее, если бы был "расстрелян" стек...

Возможно, кроме того что стек затерся, так еще и произошел возврат из функции, в результате чего оказалось некорректным значение регистра вершины стека.

Здравствуйте, Pilgrim78, Вы писали:

P>Может это и впрямь вылет в какой-то системной/сторонней библиотеке без отладочной информации. Можно ли как-то узнать по указанному адресу стека 0xff03d174, в какой библиотеке произошел вылет. Может есть команда просмотра по каким адресам какие модули были загружены?

disas или x/i на этот адрес — и смотреть, вообще оно похоже на код или нет.
Может, там реальный код, но затёрт кусок стека.

Здравствуйте, Pilgrim78, Вы писали:

P>Может это и впрямь вылет в какой-то системной/сторонней библиотеке без отладочной информации. Можно ли как-то узнать по указанному адресу стека 0xff03d174, в какой библиотеке произошел вылет. Может есть команда просмотра по каким адресам какие модули были загружены?

Ну, распечатать регистры и текущий фрейм (info regi, info frame), потом по числу, содержащемуся в IP глянуть к какой библиотеке он может относиться (info sharedlibrary), а может и в символ отрезолвится (info symbol 0x12345whatever).

help info глянь, там много интересного.

Здравствуйте, netch80, Вы писали:

N>disas или x/i на этот адрес — и смотреть, вообще оно похоже на код или нет.
N>Может, там реальный код, но затёрт кусок стека.

(gdb) x/i 0xff03d174
0xff03d174: Cannot access memory at address 0xff03d174
(gdb) disas 0xff03d174
No function contains specified address.

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Ну, распечатать регистры и текущий фрейм (info regi, info frame), потом по числу, содержащемуся в IP глянуть к какой библиотеке он может относиться (info sharedlibrary), а может и в символ отрезолвится (info symbol 0x12345whatever).

EK>help info глянь, там много интересного.

(gdb) info regi
g0 0x0 0
g1 0x604730c 100954892
g2 0x0 0
g3 0x0 0
g4 0x0 0
g5 0x0 0
g6 0x0 0
g7 0xfd871400 -41479168
o0 0x0 0
o1 0x604748c 100955276
o2 0x6047380 100955008
o3 0x0 0
o4 0xa 10
o5 0x28 40
sp 0xfbafbb60 4222597984
o7 0x604748c 100955276
l0 0xfdb9fab4 -38143308
l1 0x36 54
l2 0x1ccfd0 1888208
l3 0x0 0
l4 0x0 0
l5 0x0 0
l6 0x0 0
l7 0xff0629f0 -16373264
i0 0x62f3c48 103758920
i1 0x1811ce00 403820032
i2 0xfdbce254 -37952940
i3 0x1 1
i4 0x631d728 103929640
i5 0x1 1
fp 0xfbafbbd0 4222598096
i7 0xff03c6d0 -16529712
y 0x24 36
psr 0xfe401006 -29356026 icc:-Z--, pil:0, s:0, ps:0, et:0, cwp:6
wim 0x0 0
tbr 0x0 0
pc 0xff03d174 4278440308
npc 0xff03d178 -16526984
fpsr 0x420 1056 rd:N, tem:0, ns:0, ver:0, ftt:0, qne:0, fcc:<, aexc:1, cexc:0
cpsr 0x0 0
(gdb) info frame
Stack level 0, frame at 0xfbafbbd0:
pc = 0xff03d174; saved pc 0xff03c6d8
called by frame at 0xfbafbbd0
Arglist at 0xfbafbbd0, args:
Locals at 0xfbafbbd0, Previous frame's sp in sp
(gdb) info sharedlibrary
No shared libraries loaded at this time.
(gdb) info symbol 0xfbafbb60
No symbol matches 0xfbafbb60.

Здравствуйте, Pilgrim78, Вы писали:

P>(gdb) x/i 0xff03d174
P>0xff03d174: Cannot access memory at address 0xff03d174
P>(gdb) disas 0xff03d174
P>No function contains specified address.

Покажи info threads и bt full на каждый тред.

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Здравствуйте, Pilgrim78, Вы писали:

P>>(gdb) x/i 0xff03d174
P>>0xff03d174: Cannot access memory at address 0xff03d174
P>>(gdb) disas 0xff03d174
P>>No function contains specified address.

EK>Покажи info threads и bt full на каждый тред.

(gdb) info threads
13 process 789497 0xfec754b4 in ?? ()
12 process 592889 0xfda9cce0 in ?? ()
11 process 658425 0xfda9d8d8 in ?? ()
10 process 461817 0xfda9e5a4 in ?? ()
9 process 396281 0xfec754b4 in ?? ()
8 process 330745 0xfec754b4 in ?? ()
7 process 265209 0xfec754b4 in ?? ()
6 process 199673 0xfec754b4 in ?? ()
5 process 723961 0xfec754b4 in ?? ()
4 process 68601 0xfda9cce0 in ?? ()
3 process 986105 0xfda9d8d8 in ?? ()
2 process 920569 0xfec754b4 in ?? ()
* 1 process 855033 0xff03d174 in ?? ()

(gdb) bt full
#0 0xff03d174 in ?? ()
No symbol table info available.
#1 0xff03c6d8 in ?? ()
No symbol table info available.
#2 0xff03c434 in ?? ()
No symbol table info available.

(gdb) thread 2
[Switching to thread 2 (process 920569 )]#0 0xfec754b4 in ?? ()
(gdb) bt full
#0 0xfec754b4 in ?? ()
No symbol table info available.
#1 0xfec72e7c in ?? ()
No symbol table info available.
#2 0xfec72eb8 in ?? ()
No symbol table info available.

(gdb) thread 3
[Switching to thread 3 (process 986105 )]#0 0xfda9d8d8 in ?? ()
(gdb) bt full
#0 0xfda9d8d8 in ?? ()
No symbol table info available.
#1 0xfec40cd8 in ?? ()
No symbol table info available.
#2 0xfec75378 in ?? ()
No symbol table info available.

(gdb) thread 4
[Switching to thread 4 (process 68601 )]#0 0xfda9cce0 in ?? ()
(gdb) bt full
#0 0xfda9cce0 in ?? ()
No symbol table info available.
#1 0xff361228 in ?? ()
No symbol table info available.
#2 0xff15d5e0 in ?? ()
No symbol table info available.

(gdb) thread 5
[Switching to thread 5 (process 723961 )]#0 0xfec754b4 in ?? ()
(gdb) bt full
#0 0xfec754b4 in ?? ()
No symbol table info available.
#1 0xfec72e7c in ?? ()
No symbol table info available.
#2 0xfec72eb8 in ?? ()
No symbol table info available.

(gdb) thread 6
[Switching to thread 6 (process 199673 )]#0 0xfec754b4 in ?? ()
(gdb) bt full
#0 0xfec754b4 in ?? ()
No symbol table info available.
#1 0xfec72e7c in ?? ()
No symbol table info available.
#2 0xfec72eb8 in ?? ()
No symbol table info available.

(gdb) thread 7
[Switching to thread 7 (process 265209 )]#0 0xfec754b4 in ?? ()
(gdb) bt full
#0 0xfec754b4 in ?? ()
No symbol table info available.
#1 0xfec72e7c in ?? ()
No symbol table info available.
#2 0xfec72eb8 in ?? ()
No symbol table info available.

(gdb) thread 8
[Switching to thread 8 (process 330745 )]#0 0xfec754b4 in ?? ()
(gdb) bt full
#0 0xfec754b4 in ?? ()
No symbol table info available.
#1 0xfec72e7c in ?? ()
No symbol table info available.
#2 0xfec72eb8 in ?? ()
No symbol table info available.

(gdb) thread 9
[Switching to thread 9 (process 396281 )]#0 0xfec754b4 in ?? ()
(gdb) bt full
#0 0xfec754b4 in ?? ()
No symbol table info available.
#1 0xfec72e7c in ?? ()
No symbol table info available.
#2 0xfec72eb8 in ?? ()
No symbol table info available.

(gdb) thread 10
[Switching to thread 10 (process 461817 )]#0 0xfda9e5a4 in ?? ()
(gdb) bt full
#0 0xfda9e5a4 in ?? ()
No symbol table info available.
#1 0xfec6e1cc in ?? ()
No symbol table info available.
#2 0xff15ddbc in ?? ()
No symbol table info available.

(gdb) thread 11
[Switching to thread 11 (process 658425 )]#0 0xfda9d8d8 in ?? ()
(gdb) bt full
#0 0xfda9d8d8 in ?? ()
No symbol table info available.
#1 0xff15ec54 in ?? ()
No symbol table info available.
#2 0xff1b429c in ?? ()
No symbol table info available.

(gdb) thread 12
[Switching to thread 12 (process 592889 )]#0 0xfda9cce0 in ?? ()
(gdb) bt full
#0 0xfda9cce0 in ?? ()
No symbol table info available.
#1 0xff361228 in ?? ()
No symbol table info available.
#2 0x000496c0 in ?? ()
No symbol table info available.

(gdb) thread 13
[Switching to thread 13 (process 789497 )]#0 0xfec754b4 in ?? ()
(gdb) bt full
#0 0xfec754b4 in ?? ()
No symbol table info available.
#1 0xfec72e7c in ?? ()
No symbol table info available.
#2 0xfec72eb8 in ?? ()
No symbol table info available.

Здравствуйте, Pilgrim78, Вы писали:

P>Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>>Ну, распечатать регистры и текущий фрейм (info regi, info frame), потом по числу, содержащемуся в IP глянуть к какой библиотеке он может относиться (info sharedlibrary), а может и в символ отрезолвится (info symbol 0x12345whatever).

EK>>help info глянь, там много интересного.

Я в спарке не спец, но ....

P>(gdb) info regi
P>fp             0xfbafbbd0       4222598096

Вот это, видимо, Frame Pointer ?

P>pc             0xff03d174       4278440308

А это, видимо, Program Counter (в x86 оно называется Instruction Pointer / IP) ?

P>npc            0xff03d178       -16526984

Это не знаю.

P>(gdb) info frame
P>Stack level 0, frame at 0xfbafbbd0:
P> pc = 0xff03d174; saved pc 0xff03c6d8
P> called by frame at 0xfbafbbd0

Да, так и есть. PC -- указатель инструкций.

P>(gdb) info sharedlibrary
P>No shared libraries loaded at this time.

Эээ.... shared-либ там в программе действительно не предусмотрено, или дебаггер их почему-то не показал?

P>(gdb) info symbol 0xfbafbb60
P>No symbol matches 0xfbafbb60.
Надо было info symbol 0xff03d174 и disass 0xff03d174

Здравствуйте, Eugene Kilachkoff, Вы писали:

P>>(gdb) info symbol 0xfbafbb60
P>>No symbol matches 0xfbafbb60.
EK>Надо было info symbol 0xff03d174 и disass 0xff03d174

Результат тот же

(gdb) info symbol 0xff03d174
No symbol matches 0xff03d174.
(gdb) disass 0xff03d174
No function contains specified address.

Здравствуйте, Pilgrim78, Вы писали:

P>Результат тот же

P>(gdb) info symbol 0xff03d174
P>No symbol matches 0xff03d174.
P>(gdb) disass 0xff03d174
P>No function contains specified address.

Есть под SunOS objdump или readelf?
Сделать

$ objdump -ph program
или
$ readelf -lS program

, посмотреть, попадают ли эти адреса в какие либо секции.

Здравствуйте, ДимДимыч, Вы писали:

ДД>Есть под SunOS objdump или readelf?
ДД>Сделать
ДД>

ДД>$ objdump -ph program
ДД>или
ДД>$ readelf -lS program
ДД>

ДД>, посмотреть, попадают ли эти адреса в какие либо секции.

к сожалению этих коман нет

Здравствуйте, Pilgrim78, Вы писали:

ДД>>Есть под SunOS objdump или readelf?
ДД>>Сделать
ДД>>

ДД>>$ objdump -ph program
ДД>>или
ДД>>$ readelf -lS program
ДД>>

ДД>>, посмотреть, попадают ли эти адреса в какие либо секции.

P>к сожалению этих коман нет

А nm-то там есть? Поставить gnu binutils в конце концов....