exceptions under linux...blir lite riktigt klok :-)

[steqve]

Hejsan!

Har lite problem med att få programmet att fånga exceptions.

Kod: Markera allt

try{
int c = 3 / divisor; // divisor = 0
printf("C: %d\n", c );
}
catch(...)
{
printf("exception" );
}

Jag tycker ju att det här borde generera ett exception. Men icke! Programmet tvärdör med texten "floatinponit exception". Jag menar...en division med noll SKALL inte ta död på en process, det är förvisso ett interrupt från processorn, men klart hanterbart :-)

Jag är rätt säker på jag i windows klarar av att fånga upp kod som *p = 0; *p = 0; vilket i linux ger ett nasty segment fault. Visst är det styggt, men ett operativ tittar väl INNAN man skriver/läser till minnet om det är ok? Har läst att det bästa sättet i linux är en signal-handler, men den kan ändock inte förhindra att processen tas ned.

Någon som har lust att förklara hur det fungerar under unix? :-) Skulle behöva bra exceptionhantering och skydd mot segfaults, div by zero pga en dynamisk kod som lätt kan smälla....vill fånga upp, rätta till, därefter gå vidare. Det hade gått att lösa om det fanns en funktion liknande den i windows ( is_god_read_ptr eller liknande där man kan kika om ett minnesområde är läs/skrivbart).

Om någon dessutom kan presentera assemblerkod för hur try / catch implementeras så skulle jag ju bli rackarns glad!!

Tack på förhand.

[jsiei97]

Någon som har lust att förklara hur det fungerar under unix? :-) Skulle behöva bra exceptionhantering och skydd mot segfaults, div by zero pga en dynamisk kod som lätt kan smälla....

Dagens fråga hur funkar ditt problem i c?
Hur fungerar ditt problem i c++ implementationer som saknar try catch, t.ex. nyare Symbian?

För mig låter det som du vill använda try catch som skydd mot dålig minneshantering?
Och om du har dynamisk kod måste du kontrollera och hålla koll på vad din data gör innan den gör fel.

Tyvärr är det mycket bättre att göra rätt från början än att förlita sig allt för mycket på
saker som try catch, lite eftersom de har en kraftig prestanda kostnad.

Sedan skulle jag misstänka att du borde aktivera

Kod: Markera allt

ulimit -c unlimited

i ditt shell så du kan fånga minnesdumparna som segfaults resulterar i.
(se att kompilera med fullt debug stöd -g eller dyl)

och sedan borde du kunna kasta in dumpen i gdb och köra lite "post mortem" analys på dina problem.

Kod: Markera allt

gdb ./hello_world core

och sedan är det bara ta reda på varför din kod gick fel (fast i detta fallet vet du redan vad som gick fel).



Och vid det här laget misstänker jag att du har blivit totalt skogstokig på att jag har ratat try catch helt,
och till synes inte svarat på din fråga

Mvh Johan

[steqve]

Definitivt inte :-) Jag har läst på mer under natten här och i Windows använder man ju structured exception handling. Därmed är try/catch eminent till kod man faktiskt inte VET utgången av.

Programmet är en mjukvaru CPU som således kan löpa helt amok om man skriver kod som gör dumma saker (t.ex en STORE instruktion till minne man inte har rätt till). Det är ju svårt att skydda sig mot, jag kan lägga in en test att man inte försöker skriva/läsa till adress 0 exempelvis, men övriga 4gb indexerbart minne är svårare. Det skulle även gå att se om adressen är inom området för datasegmentet, och det kommer till heapen kan jag ju ha en vektor med minnesinformation som talar om blockentries och storlekar. Det är ju klart görbart.

Nu har jag dock acceptera (om än dock motvilligt) att programmet helt enkelt får stendö om man försöker skriva till minne man inte har rätt till.

Däremot är jag fortfarande intresserad av hur assemlerkoden för try/catch ser ut. Har singelsteppat mina program, men ser inte riktigt hur implementationen är. Jag vill minnas att adressen till catch-koden läggs i något av registren för att sedan användas som återhoppsadress...men det var för länge sedan jag läste det där.

[mcNisse]

Du vet väl att du har tillgång till källkoden för g++ och gnus länkare? Jag tycker att du borde kunna hitta detaljerna där.

[steqve]

Förvisso, men nog för att jag läser kod till frukost, men det finns nog lättare sätt... Här var lite input:

http://www.codeproject.com/KB/cpp/exceptionhandler.aspx

Samt för den intresserade (kod för Windows SEH dock).

Kod: Markera allt

@TRY_BEGIN MACRO Handler
  	pushad 	;;Save Current State
  	mov esi, offset Handler 	;;Address of New Exception Handler
  	push esi 	;;Save Old Exception Handler
  	push dword ptr fs:[0] 	;;Install New Handler
  	mov dword ptr fs:[0], esp 	 
ENDM
@TRY_EXCEPT MACRO Handler
  	jmp NoException&Handler 	;;No Exception Occured, so jump over
Handler: 	mov esp, [esp + 8] 	;;Exception Occured, Get old ESP
  	pop dword ptr fs:[0] 	;;Restore Old Exception Handler
  	add esp, 4 	;;ESP value before SEH was set
  	popad 	;;Restore Old State
ENDM
@TRY_END MACRO Handler
  	jmp ExceptionHandled&Handler 	;;Exception was handled by @TRY_EXCEPT
NoException&Handler: 	  	;;No Exception Occured
  	pop dword ptr fs:[0] 	;;Restore Old Exception Handler
  	add esp, 32 + 4 	;;ESP value before SEH was set. 32 for pushad and ...
ExceptionHandled&Handler: 	  	;;...4 for push offset Handler. (No Restore State)
  	  	;;Exception has been handled, or no exception occured
ENDM

[diwic]

Jag är rätt säker på jag i windows klarar av att fånga upp kod som *p = 0; *p = 0; vilket i linux ger ett nasty segment fault. Visst är det styggt, men ett operativ tittar väl INNAN man skriver/läser till minnet om det är ok? Har läst att det bästa sättet i linux är en signal-handler, men den kan ändock inte förhindra att processen tas ned.

Ett operativ förlitar sig på CPU'ns hårdvarustöd för att omvandla virtuella adresser till fysiskt minne, och att den genererar exceptions om man försöker skriva till virtuellt minne som är skrivskyddat (eller inte är adresserat alls). Vad som händer då är att CPU:n meddelar operativsystemet, som i sin tur triggar en SIGSEGV-signal till processen. Finns ingen signalhanterare så dör processen.

Men, jag kommer också från Windows och är förvånad över att C++-runtimebiblioteket under linux inte per default installerar en signalhanterare för att ta hand om såna här saker? Gör den verkligen inte det så måste det väl gå att länka in nåt bibliotek så att C++ faktiskt kan hantera exceptions?

[Lars]

När det gäller division med noll så är det tydligen ett medvetet val av Stroustrup att det inte ska leda till exception, se http://www.jdl.co.uk/briefings/divByZeroInCpp.html

Varför det inte finns någon signalhanterare för SIGSEGV vet jag inte. Men det borde väl inte vara så svårt att skriva en om man behöver det.