Hogy lehet megtudni a halál okát?

C/C++

Hogy lehet megtudni a halál okát?

  • 792 megtekintés

( soky | 2005. 05. 11., sze – 14:07 )

/etc/rc.d-ből inditom, gondolom root-ként, mivel nem mondtam su-t.
De hogy ilyenkor mi a pwd, arról fogalmam sincs...
Lehet, hogy nem is ártana NEM rootként futtatni, és su alkalmával beállhatnék egy könytárba.
finddel végignéztem, amennyiben core a neve, ilyet csak a modules-ben találtam, de az nyilván nem dump :)

micsa: ezt hogy?

Amúgy én mindig be szoktam rakni a projekt elejére hogy a processz mindig állítsa be magának unlimitedre hogy véletlenül se maradjak le egy esetleges core-ről.

Indító szkriptbe vagy magába az ELF-be?

( uid_4672 | 2005. 05. 11., sze – 14:14 )

hmm...

nem nagyon illik root-ként futtatni egy user alkalmazást... mert hogy a rootnak túl sok minden meg van engedve...

megcsinálhatod, hogy a rc.d ből lefuttatsz egy script-et, ami a belép a /home/juzer könyvtárba, su juzer utána pedig elindítja a programot...
ha root vagy a su az megy jelszó nélkül...
vagy su -c parancs
csak olyan könyvtárból indítsd, amibe tud létrehozni file-ot az illető user...

( soky | 2005. 05. 15., v – 19:28 )

Oké, -g-vel fordítom, nem root-ként futtatom, olyan helyről indítom ahova írhat, ulimit -c-t felnyomom, csomag készítésnél megakadályozom a strippet.
Ez elég ahhoz, hogy crash esetén létrejöjjön egy core dump, amit itthon gdb-vel nézegethetek?
Egyébként ezt a dumpot a kernel hozza létre függetlenül a futtatott bináris fordítási opcióitól?

( uid_4672 | 2005. 05. 16., h – 08:12 )

igen, elég.

amúgy ki kell próbálni... beteszel a projekt elejére egy *(int*)0 = 0;-t, megnézed hogy mi lesz. megpróbálod gdbzni, stb.

( soky | 2005. 05. 11., sze – 00:00 )

Sziasztok!
Van egy C-ben irt progim, ami évek óta megy.
Egyszer hív az ügyfél, hogy megállt, és nem tudom kideríteni miért.
Soros porton vesz adatokat, postgresql táblában tárolja, közben logot is ír.
Signal-okat elkapom és szabályosan leállok, logolok, logfile-t lezárom, lock-ot törlöm.
Hibákat lekezelem, ha fatal logolom és kilépek.
Legutóbb (gyorsításképpen) kivettem a logba írás után a flush-t.
Ennél a leállásnál a logból hiányzott egy órányi adat, a lock bentmaradt, tehát nem volt alkalmam szabályosan leállni, logolni.

Ha mondjuk van egy pointer hibám, ami segfaulttal öl meg, vagy az adatbáziskezelő dob le magáról, honnan tudhatom meg?

Stdoutom nincs, mert rc.d-bol indítom, és &-el háttérbe teszem.

Kérlek segítsetek!
Köszi, soky

( gabor2 | 2005. 05. 11., sze – 07:40 )

[quote:5d8a0ff958="soky"]Sziasztok!
Van egy C-ben irt progim, ami évek óta megy.
...
Ha mondjuk van egy pointer hibám, ami segfaulttal öl meg, vagy az adatbáziskezelő dob le magáról, honnan tudhatom meg?

Stdoutom nincs, mert rc.d-bol indítom, és &-el háttérbe teszem.

Kérlek segítsetek!
Köszi, soky

Nezd meg, hogy keletkezett-e core file. Aztan gdb -c corefile. Ha nem a stack-ed szallt el, akkor valami leirast tudsz kapni a stack allapotarol az elszalas pillanataban, a 'bt'-vel. Meg 'man gdb'. Ha stripe-elted a binarist
az gaz.

g

( Lippi | 2005. 05. 11., sze – 09:35 )

Sziasztok,

Lenne egy elmeleti kerdesem:
Ez vajon akkor is mukodik, ha az ugyfelnel a strip-elt binaris van, de megvan az eredeti (debuggos) is es arra futtatom a gdb-t?

Ha RTFM, akkor sem leszek szomoru, de kulcsszonak orulnek!

Udv:

Lippi

( uid_4672 | 2005. 05. 11., sze – 10:01 )

a strip csak annyit csinál - tudtommal - hogy kiszedi a debug és symbol section-öket a futtathatóból. Elvileg minden symbol ugyanott lesz (ami a virtuális címet illeti). Csak arra kell vigyázni, hogy ha te most buildeled újra a debugos verziót, akkor az ugyanazzal a kompilerrel és ugyanazokkal a kompiler paraméterekkel legyen lebuildelve (gondolok itt optimizálásra... persze -g opció)

és ami a dinamikus library-ket illeti, hogy ezek a symbolok is meglegyenek, ajánlom hogy azon a gépen nézd a debugos verziót is amelyiken kikresselt

tehát elvileg megy...

( wry | 2005. 05. 11., sze – 10:07 )

[quote:3399860186="Lippi"]Sziasztok,

Lenne egy elmeleti kerdesem:
Ez vajon akkor is mukodik, ha az ugyfelnel a strip-elt binaris van, de megvan az eredeti (debuggos) is es arra futtatom a gdb-t?

Ha RTFM, akkor sem leszek szomoru, de kulcsszonak orulnek!

Udv:

Lippi

elméletben teljesen mindegy lenne, nem? a strip a symbolokat kitörlni az objfileból, de azokra a program futtatásához nincs szükség - azaz a program attól még változatlan.
lehet, hogy rosszul gondolkozom, de szerintem tök minden stripped bináris tojta e a coret vagy non-stripped tele debug infókkal, ha a gdb-ben a coret a non-stripped változattal ereszted össze akkor jó eséllyel látnod illene mi történt.

( soky | 2005. 05. 11., sze – 10:13 )

ArchLinux-ra készítettem belőle csomagot, aki strippel.
Mondjuk ezt meg tudom kerülni, akár debug infóval is fordíthatnám, kössz az ötletet!

Ennek a strippelt példánynak a halálakor is létrejö(he)tett ilyen core dump?
És hol kéne keresnem/találnom?
Ha ez alapján nem tudja megmutatni a hiba helyét, de a fő okot megnevezi?

( uid_4672 | 2005. 05. 11., sze – 10:20 )

core-t a linux csak akkor generál ha az ulimit-ben be van állítva az illető usernek. a core file helye az a könyvtár ahonnan indítva volt a program...
de ha nem volt ez berakva (ulimit -c unlimited) akkor bizony nem csinál core-t. és core nélkül nem nagyon lehet csinálni sokat.....

( wry | 2005. 05. 11., sze – 11:10 )

[quote:b2232d57cc="micsa"]core-t a linux csak akkor generál ha az ulimit-ben be van állítva az illető usernek. a core file helye az a könyvtár ahonnan indítva volt a program...
de ha nem volt ez berakva (ulimit -c unlimited) akkor bizony nem csinál core-t. és core nélkül nem nagyon lehet csinálni sokat.....

unlimit-ben biztos vagy? én úgy tudtam, hogy ha 0 akkor nincs core, ha unlimited akkor van és ha x méretű és a core mérete nagyobb lenne x-nél akkor x méretűre lesz faragva.
az ulimit beállításodat az "ulimit -a"-val tudod megnézni, de a pontos parancsot a shell-ed manualjában fogod megtalálni (pl bash esetén man bash és aztán tekerj az "ulimit" parancsra).
fontos, hogy a progit futtató usernek jól be legyen állítva a core file size, ugyanis némely distrok 0-ra állítják alapból.

( uid_4672 | 2005. 05. 11., sze – 11:36 )

nem értem mit akarsz ezzel mondani. azt mondtam hogy ahhoz hogy engedélyezd a core fileokat - bármilyen méretűeket - azt az ulimit -c unlimited paranccsal éred el. merthogy a disztrók általában 0ra állítják startból. mi a probléma? Amúgy én mindig be szoktam rakni a projekt elejére hogy a processz mindig állítsa be magának unlimitedre hogy véletlenül se maradjak le egy esetleges core-ről.

amúgy nem unlimitet mondtam hanem ulimitet

( wry | 2005. 05. 11., sze – 12:43 )

egyszerű.
egy dolgot elírtam (az első szó (unlimit) helyett unlimited-et akartam írni).
ezt pedig félreértettem :

"de ha nem volt ez berakva (ulimit -c unlimited) akkor bizony nem csinál core-t. és core nélkül nem nagyon lehet csinálni sokat....."

ezt ugyanis kétféleképpen lehet értelmezni és nekem úgy sikerült, ahogyan te nem akartad :) zárójelbe tetted a helyes megoldást, én viszont ugyanezt mondatot ha írtam volna, akkor a helytelen megoldást tettem volna zárojelbe - vagy a helyeset nem tettem volna zárójelbe, hanem kettőspont mögé (vagy vessző után, idézőjelek közé).
most már minden tiszta.

de hogy egy példában is demonstráljam miért félreérthető:

"de ha nem így tettél (azaz ha úgy tettél, hogy...), akkor...."