Mit jelent a backtrace-ben a 0x0000000000000000?

Egyéb: Assembly, Ada...

Az lenne a kérdésem, hogy az alábbi az lehet -e valid (b/st)acktrace, vagy csak simán beleírt valami a heapbe? És ha mégsem, akkor mit is jelent a #7 -es elem: 0x0000000000000000? 


#0  0x00007fffeef18ba6 in ?? () from ./flash/libflashplayer64.so
#1  0x00007fffeeaed0f3 in ?? () from ./flash/libflashplayer64.so
#2  0x00007fffeeab92cd in ?? () from ./flash/libflashplayer64.so
#3  0x00007fffec472bec in ?? ()
#4  0x00007fffec5526b8 in ?? ()
#5  0x00007fffec588ae0 in ?? ()
#6  0x00007fffec3fd0e0 in ?? ()
#7  0x0000000000000000 in ?? ()
  • 5762 megtekintés

( turdus | 2010. 09. 20., h – 20:50 )

azt jelenti, hogy NULL pointer. Valszeg kódot akart futtatni ott, ezért vágta ki a kernel. Tippre le nem kezelt pluginbetöltés iskolapéldája.

Ja, akkor pedig a 0x00000-nál még nincs inicializálva a stack regiszter és azért nulla. Mellesleg ha a 7-es az első, azaz a kiindulási állapot, akkor az értéke a problémád esetében nem releváns. Mindenesetre érdekes, hogy 3-7-ig nincs mellette semmi info, milyen lib vagy más állította az adott értékre.

Egyébként minek az outputja ez?

> Ja, akkor pedig a 0x00000-nál még nincs inicializálva a stack regiszter és azért nulla.
A backtrace a stack-en levő értékeket listázza, azaz a stack-regiszternek csak az aktuális értéke játszik szerepet benne, nem érdekes mi volt az állapota induláskor

> Mellesleg ha a 7-es az első, azaz a kiindulási állapot, akkor az értéke a problémád esetében nem releváns. Mindenesetre érdekes, hogy 3-7-ig nincs mellette semmi info, milyen lib vagy más állította az adott értékre.

Igazából azért releváns, mert eddig még nem láttam olyan stacktrace-t ami 0-val kezdődött volna. Azóta sikerült kideríteni, és itt magamnak is válaszolok, hogy egy pthread_create-tel készített threadnek 0-val kezdődik a stacktrace-e.

Hogy miért nincsenek symbolok, az egy másik játék ... azt egyelőre nem tudom.

> Egyébként minek az outputja ez?
Saját hobbi standalone flash player.

es valoban, nade ha strippeled a binarist akkor mar nem.
eskuszom regen strippelni se kellet.
man strip

int foo()
{
return *(int*)0;
}

int main()
{
return foo();
}

$ gcc x.c
$ strip a.out
$ gdb a.out
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x0804837c in ?? ()
(gdb) bt
#0 0x0804837c in ?? ()
#1 0x08048388 in ?? ()
#2 0xb7e8ac76 in __libc_start_main () from /lib/libc.so.6
#3 0x080482e1 in ?? ()
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

Amit te küldtél az ok, az egy normális trace, de nálam ez jön ki belőle: 


(gdb) ba
#0  0x00000000004004cd in ?? ()
#1  0x00000000004004df in ?? ()
#2  0x00007ffff7a77c4d in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, 
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffffffe338)
    at libc-start.c:226
#3  0x0000000000400409 in ?? ()
#4  0x00007fffffffe338 in ?? ()
#5  0x000000000000001c in ?? ()
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffe606 in ?? ()
#8  0x0000000000000000 in ?? ()

Lehet valami egész más gáz van nálam?

[szerk] csak 64 biten. 32-n ugyanazt produkálja mint nálad.

( aszechy | 2010. 09. 20., h – 22:29 )

Ez honnan van? Ugyanarrol a geprol, ahol a problema van? Mintha nem tudna a symbol-okat feloldani - ami akar attol is lehet, hogy a gepen mas verzioju libraryk vannak telepitve, mint ahol maga a gond adodott. pl. kapsz egy core-t az egyik gepen, masik gepen megprobalod megnyitni gdb-vel es ha ott nem pont ugyanaztok a library-k vannak, nem fogja tudni a symbol-okat megfeleloen feloldani

Saját standalone flashplayer crashel el. A debug ugyanazon a gépen van ahol a crash. Azóta már kiderítettem (lásd feljebb), hogy egy pthread_create-tel készített threadnek kezdődhet 0-val a backtrace-e. Végülis ez lett volna a fő kérdés, lehet nem sikerült jól megfogalmazni.

A symbolok eltűnése szerintem valami heap korrupció lesz, ugyanis a sehol se látok egy call-t: 


Dump of assembler code from 0x7fffec3fd0da to 0x7fffec3fd0e6:
   0x00007fffec3fd0da:	add    %al,(%rax)
   0x00007fffec3fd0dc:	add    %al,(%rax)
   0x00007fffec3fd0de:	add    %al,(%rax)
   0x00007fffec3fd0e0:	lock mov $0x59,%bl
   0x00007fffec3fd0e3:	out    %eax,(%dx)
   0x00007fffec3fd0e4:	(bad)  
   0x00007fffec3fd0e5:	jg     0x7fffec3fd0e7


Dump of assembler code from 0x7fffec588ada to 0x7fffec588ae6:
   0x00007fffec588ada:	add    %al,(%rax)
   0x00007fffec588adc:	add    %al,(%rax)
   0x00007fffec588ade:	add    %al,(%rax)
   0x00007fffec588ae0:	xlat   %ds:(%rbx)
   0x00007fffec588ae1:	and    %dl,-0x14(%rsi)
   0x00007fffec588ae4:	(bad)  
   0x00007fffec588ae5:	jg     0x7fffec588ae7

( axt v | 2010. 09. 22., sze – 00:19 )

Átfogalmazódott a kérdés:

Adott az alábbi kód: 


int foo() {
  return *(int*)0;
}
int main(){
  return foo();
}

Első eset: 


gcc main.c -o main
./main
(gdb) ba
#0  0x00000000004004cd in foo ()
#1  0x00000000004004df in main ()

Második eset: 


gcc main.c -o main
strip main
./main
(gdb) ba
#0  0x00000000004004cd in ?? ()
#1  0x00000000004004df in ?? ()
#2  0x00007ffff7a77c4d in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, 
    ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=0x7fffffffe338) at libc-start.c:226
#3  0x0000000000400409 in ?? ()
#4  0x00007fffffffe338 in ?? ()
#5  0x000000000000001c in ?? ()
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffe606 in ?? ()
#8  0x0000000000000000 in ?? ()