Ktory thread sposobil coredump?

[Jan Pechanec]

On Sat, 4 Feb 2006, Marian Cerny wrote:

>> 	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.

	tyhle veci jsou synchronni - sigsegv, fpe a spol, tj. signal urcite 
dostane to vlakno, ktere to zpusobilo. Samozrejme, pokud dane vlakno maskuje 
sigsegv nebo dela neco, co UNIX03 explicitne nepovoluje v dane situaci, 
vysledek je nedefinovany.

	to volani adresy 0x00... muze byt treba tim, ze se zavola sym = 
dlsym(...), nezkontroluje se navratova hodnota a pak se zavola ten sym().

	k cemu potrebujes vedet, ktery vlakno to zpusobilo? Melo by pro 
zakladni orientaci stacit, kde v kodu se to stalo, ne? Nebo to nemuzes 
prelozit s debug symboly?

>
>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

	hmm, divny, mluvis o FBSD nebo o Linuxu? Mohlo by to souviset s tim, 
o cem mluvim nahore? Treba vsechna vlakna maskujici vsechny signaly a jedno 
vlakno jako signal manager cekajici v sigwait()?

	h.

-- 
Jan Pechanec <jp (at) devnull (dot) cz>
http://www.devnull.cz