[c++] eccezioni in librerie dinamiche non catturate

[tglman]

Dal titolo complesso ... si evince che ho un problema complesso .....

allora ho due librerie dinamiche(lib1 e lib2) è un esegubile(runner) ...

l'eseguibile runner usa lib1 a "linktime" e lib2 a runtime con dlopen()

ho un flusso applicatiovo del tipo:
runner->lib1->lib2->lib1
(tradotto in italiano il runner chiama una funzione di lib1 che chiama una funzione di lib2 che a sua volta richiama una funziona di lib1)

nell'ultima chiamata viene lanciata un'eccezione che dovrebbe essere gestita all'interno del codice della prima chiamata a lib1 .... ma l'eccezione sale fino a far crasshare il programma come se nn ci fosse nessun catch()...

leggendo su internet ho trovato informazioni rigardo a possibilità di problemi con le eccezioni con librerie dinamiche ...
sapreste dirmi perche il catch nn cattura l'eccezione anche se il codice è giusto e compila?

se volete vi faccio qualche esempio di codice per spiegarmi meglio ;)
grazie ciao!!

[cionci]

se volete vi faccio qualche esempio di codice per spiegarmi meglio ;)
Ecco, sarebbe molto interessante. Qualcosa compilabile ;)

[tglman]

Ok faccio un esempio semplice sempice al volo:

lib1:

class Ecce{};

void functionRunner(void (*func)())
{
try
{
func();
}
catch(Ecce & ec)
{
}
}

void lanciatore()
{
throw Ecce();
}


lib2:

void function()
{
lanciatore();
}


runner:

int main()
{
void (*pfunc)() = //carico con dlopen() lib2 e prendo il puntatore a function
fuctionRunner(pfunc);
}


ho scritto un pò di codice al volo per far capire .... il mio è più lungo e complesso ... ma il flusso è questo ...

il problema è che l'eccezione lanciata da "lanciatore()" nn viene catturata da "functionRunner()" e sale fino a far crashare tutto....
io penso che sia un problema di linking ... lib1 viene collegata a linktime e lib2 caricato a runtime con dlopen() che posso aver sbagliato ?

[sottovento]

Domande:
Stai ovviamente lavorando sotto Windows, giusto?
Sicuro che non sia un crash? La catch(...) ti prende l'eccezione? (nel tuo codice di esempio non c'era).
Ovviamente catch(...) e' sempre da evitare, soprattutto con Visual Studio < 2005, ma e' per sapere.
Cosa ti dice il debugger?

[cionci]

Vista la dlopen direi che sia su Linux ;) O su Windows con gcc.

[fero86]

probabilmente la libreria che cerca di catturare il catch é stata compilata con un compilatore diverso, o con una versione diversa dello stesso compilatore, rispetto a quello utilizzato per compilare la libreria che lancia l'eccezione; in sostanza i due meccanismi che gestiscono le eccezioni C++ (quello che lancia e quello che cattura) sono incompatibili. un po' alla lontana lo si potrebbe definire un caso di ABI mismatch, anche se non é proprio ABI.

un'altra ipotesi che mi viene in mente é che tu abbia scritto male il catch: sicuro che il tipo dell'eccezione lanciata corrisponda precisamente a quello dell'eccezione catturata?

[tglman]

Allora sono sotto linux e uso gcc (se può interessare con codeblocks)
ed il codice che lancia l'eccezione e quello che la cattura sta nella stessa libreria ... quindi compilata con lo stesso compilatore ...

comunque uso solo un compilatore di una versione ...

sicuri che nn è qualche problema di linking ?

[fero86]

mi quoto:
un'altra ipotesi che mi viene in mente é che tu abbia scritto male il catch: sicuro che il tipo dell'eccezione lanciata corrisponda precisamente a quello dell'eccezione catturata?

[tglman]

si stessa eccezione provato sia per riferimento( &) sia con la classe vera e propria (ho solo un'eccezione in quella libreria .... e quella ho catturato :( )

[cionci]

Ma se fai un catch in runner l'eccezione viene rilevata correttamente ?

[tglman]

provato ! no nn la cattura!!

[fero86]

Ma se fai un catch in runner l'eccezione viene rilevata correttamente ? appunto, secondo me no: evidentemente l'eccezione che fa crashare il tutto non é quella lanciata e catturata nel catch, ma un'altra.

@tglman: come fai ad essere sicuro che il processo crasha a causa di quell'eccezione? la causa del crash non potrebbe essere di tipo molto piu classico, ad esempio dereferenziamento di un puntatore nullo? magari proprio nel catch handler?

[tglman]

si sicuro sicuro: come da screenshot in allegato ....

e indovinate un pò la mia eccezione si chiama TestFail!!!

:( :( :(

come si evince dallo screenshot l'eccezione nn deve far finire il programma ma dovrebbe scrivere ... test fallito per: ecc ecc e continuare

[fero86]

in casi come questi io chiudo temporaneamente il progetto su cui sto lavorando e ne creo uno nuovo in cui cerco di riprodurre uno scenario estremamente basilare in cui (non) dovrebbero verificarsi le circostanze di errore; quindi nel tuo caso creerei un sorgente per una libreria dinamica che espone una funzione che lancia e cattura un'eccezione, e un sorgente per un eseguibile che carica la libreria dinamica con dlopen e chiama la funzione.

se si verifica nuovamente l'errore (il processo crasha) segnalalo al team del gcc (e per interesse nostro riporta anche qui i sorgenti e la versione del g++), altrimenti vai aggiungendo man mano pezzi di codice ai nuovi sorgenti finché non ottieni il programma a cui stavi inizialmente lavorando; tipicamente quando faccio cosi non arrivo ad aggiungere due righe che capisco di aver sbagliato io.

[tglman]

se volete darmi una mano ho messo tutto il progettino su sourceforge lo trovate cercando testframework...

grazie del vostro supporto ... io continuo con i test!!

[tglman]

Risoltoooooo!!!!!!

Finalmente ho capito qual'era il problema ....

lib2 era una libreria totalmente c e nn c++ quindi non venivano gestiti i meccanismi per le eccezioni!!!

per compatibilità con librerie nn c++ quindi ho tolto le eccezioni e usato i <setjmp.h> ed adesso funziona tutto correttamente!

grazie comunque a tutti per il supporto!