Odchyceni SIGSEGV

[Pavel Kankovsky]

On Fri, 19 Jan 2001, Michal Krause wrote:

> protoze se obvykle durazne nedoporucuje po odchyceni tohoto signalu
> pokracovat (coz je logicke), nabizi se otazka, jaky ma jeho odchytavani
> vubec smysl.

U oracliho serveru je na SIGSEGV apod. napichnuta procedura, ktera rucne
vyrobi jakysi pseudocoredump. Predpokladam, ze to delaji z toho duvodu,
ze jim to pomaha pri diagnostice chyb.

> Napadlo me tedy, jestli v handleru nelze zjistit neco zajimaveho o
> jeho vyvolani - nejaka adresa, backtrace atd. Dalo by se to nejak
> vyuzit?

To urcite ano. Signal handler ma ve skutecnosti na zasobniku vicemene
kompletni obsah registru procesu (threadu) v okamziku, kdy doslo
z jeho strany "faux pas" zpusobujiciho SIGSEGV. Viz DOSEMU, tam se to
pouziva celkem intenzivne. Je to pochopitelne dost nizkourovnove, ale pro
ucely ladeni se s tim da smirit. Co se tyce MT: nevidim zadny duvod, proc
by to nemelo fungovat (a dost mi unika, proc s tim nekdo/neco ma
problemy, ale zkoumat to nebudu).

> Nekde jsem treba cetl, ze ackoliv to neni zaruceno, na vetsine
> platforem lze v handleru volat napr. pthread_self(). Jaky na to maji
> nazor zkusenejsi kolegove programatori? :)

V zasade plati dve veci: 1. handler SIGSEGV je v podobne situaci jako
handler ostatnich signalu, tj. volani knihovnich a jinych funkci, ktere
nejsou zcela reentrantni (zase to slovo :>), nemusi vest k dobrym
vysledkum, 2. SIGSEGV navic prichazi vesmes v situaci, kdy je neco spatne,
coz znamena, ze snadno muze zhavarovat i funkce, co by se mela chovat
v signal handleru slusne. Obecne plati: cim jednodussi funkce, tom vetsi
pravdepodobnost, ze to projde.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."