Ktory thread sposobil coredump?

[Marian Cerny]

On 2006-02-04 11:35 +0100, Dan Lukes wrote:
> > casto sa mi stava, ze nejaky viacvlaknovy proces spadne, vytvori
> > coredump, ale ja neviem zistit, co sposobilo je pad (kde nastal
> > segmentation fault).
> > 
> > Teraz momentalne je to apache s worker MPM. Nevedel by mi niekto
> > poradit, ktory thread sposobil segmentation fault?
> 
> 	Nejsem zas tak zkuseny uzivatel gdb, ale skoro bych rekl, ze core-dump 
> nemohl zpusobit jiny, nez "current" thread. Takze staci coredump 
> spolscne s puvodnim binarem nahrat zpet do gdb - a zjistit, ktery thread 
> je "current".

Ano, zrejme vlastny coredump nemohol sposobit iny nez current thread.
Lenze tam bude nejaky figel, ze current thread nebude ten, ktory vykonal
ten neplatny pristup do pamete (segmentation fault).

Moja hypoteza je taka, ze ked sa vykona instrukcia, ktora sposobi
neplatny pristup do pamete, tak sa tomu procesu posle signal, ktory bud

  o spracuje aktualne vlakno, ale este preda riadenie inemu vlaknu,
    ktore vykona vlastny coredump, alebo

  o spracuje rovno ine vlakno.

Mne potom vlastne nejde o to, ktore vlakno sposobi/vykona ten coredump,
ale ktore pustilo instrukciu, ktora vykonala neplatny pristup do pamete.

To, ze to current vlakno z coredumpu nie je to, ktore vykonalo neplatny
pristup do pamete, mam overene praxou, ked sme vytvarali viacvlaknovu
hru Dark Oberon. Lenze tam som mal debugovacie informacie a stacilo sa
mi trosku poprepinat medzi vlaknami a pozriet parametre funkcii, poziciu
kazdeho jednotlivych vlakien v kode a nejake premenne. Uz predtym ma to
trosku stvalo, ze to musim hladat, ale tam to hladanie netrvalo dlho.

V linuxe bolo myslim po nacitani coredumpu do gdb current vlakno to,
ktore vykonalo ten neplatny pristup. Dokonca sa mi zda, ze aj na FreeBSD
4.x to tak bolo. Ja pouzivam 5.4. Takze to mozno zavisi aj od toho, aka
kniznica sa pouzije, ci libthread, libr_c, ci ake kniznice to FreeBSD
ma.

Marian Cerny