[c/delphi/dll] 'crash' afvangen

[Alarmnummer]

Ik moet 2 weken assisteren bij het debuggen van een oud systeem. Hierbij is een belangrijk niet gui gedeelte geschreven in c (borland c v4.0) en gecompileerd tot een dll. Het delphi gedeelte spreekt deze dll weer aan.

Zo nu en dan gebeurt het dat de applicatie ineens verdwijnt zonder foutmeldingen. Mijn vermoeden is dat het in de c code fout gaat (geen wonder, want het is een typisch voorbeeld van hoe je niet moet werken). Hier gebeurt verder ook veel odbc werk.

Mijn vraag is in hoeverre ik die dll kan afschermen. Wat voor mogelijkheden zijn er dus om een rotte dll een beetje af te vangen. Het gaat me er puur om dat we een manier hebben om het probleem te localiseren.

[ Voor 4% gewijzigd door Alarmnummer op 13-01-2003 11:51 ]

[LordLarry]

Grote try catch om alle functies in je DLL is het enige wat ik me zo kan bedenken, maar met GUI koppel je jezelf al weer los door de windows messages en zal dat geen nut meer hebben. Ik denk dat je meer geluk hebt als je zoveel mogelijk logt welke functies er aangeroepen worden om zo steeds meer in te zoomen op het probleem.

[whoami]

LordLarry schreef op 13 januari 2003 @ 12:02:
Grote try catch om alle functies in je DLL is het enige wat ik me zo kan bedenken,

Ik denk niet dat dit zal werken. Die dll is immers in C geschreven, en voor zover ik weet kent C geen exceptions.

[Alarmnummer]

*is niet echt thuis in debuggen icm c*

Zou het niet mogelijk zijn om betere debugging support in te bouwen in de c code? En misschein zou het een mogelijkheid zijn om er dan maar een c++ project van te maken?

[LordLarry]

whoami schreef op 13 januari 2003 @ 12:05:

[...]


Ik denk niet dat dit zal werken. Die dll is immers in C geschreven, en voor zover ik weet kent C geen exceptions.

C niet nee, maar als het over GUI gaat verwacht ik eigenlijk dat het om BCB v4 gaat. Of heb ik het mis Alarmnummer?

[whoami]

LordLarry schreef op 13 januari 2003 @ 12:10:
[...]


C niet nee, maar als het over GUI gaat verwacht ik eigenlijk dat het om BCB v4 gaat. Of heb ik het mis Alarmnummer?

Ik denk dat je het mis hebt. Het is het niet-GUI gedeelte dat in C geschreven is.

[Alarmnummer]

LordLarry schreef op 13 januari 2003 @ 12:10:
[...]
C niet nee, maar als het over GUI gaat verwacht ik eigenlijk dat het om BCB v4 gaat. Of heb ik het mis Alarmnummer?

Het is niet Borland C Builder, maar gewoon een losse Borland C (4.5 of 5.5) en delphi 5

Maar wat voor extra debugging info kan ik opnemen in die c code?
Is het mogelijk om daar ook een stacktrace te krijgen?

[ Voor 18% gewijzigd door Alarmnummer op 13-01-2003 12:33 ]

[LordLarry]

Hehe, inderdaad. Ik had het beter moeten lezen.

Die stacktrace is mogelijk doordat de Borland compiler debug informatie toevoegt. Die oude BC compilers deden dat ook al, dus dat is niet het probleem. Zoals whoami al zegt heb je geen excepties in C, dus ze afvangen en dan een stacktrace draaien zal geen zin hebben. Dus alhoewel een stacktrace wel mogelijk is, is het punt waarop deze laten zien moeten worden onduidelijk. Al helemal voor DLL's, want hierbij is eigenlijk de App die ze laat verantwoordelijk.

Waarschijnlijk kan je met weinig moeite je C DLL compilen met een C++ compiler met alle voordelen vandien. Bij de exception trace componenten moet je extra code aan een DLL toevoegen om die excepties ook af te vangen. Dat zal je hier ook moeten doen.

[Olaf van der Spek]

Je kunt een 'proxy' schrijven en de proxy met DLL in een apart process laten draaien. Als je de DLL wilt aanroepen doe je dat via interprocess communicatie. Een crash in de DLL zal de GUI nu niet laten meecrashen.

[Alarmnummer]

Ik heb de makefile omgezet zodat er met de c++ compiler wordt gewerkt (en zie dat ze zeer weinig debugging info hebben aangeschakeld ) Ik krijg hierbij de volgende foutmelding:

Too many types in declaration: op regel 16

C++:

#ifndef _VTMAN_H
#define _VTMAN_H


extern val_tp unknown_val;


void      vt_destroy        (val_tp *val);

void      vt_init           (void);
void      vt_set_unknown    (val_tp *val);
boolean   vt_unknown        (const val_tp val);

void      vt_put_int        (const long in     , val_tp *val);
void      vt_put_real       (const Real rel    , val_tp *val);
void      vt_put_bool       (const boolean bool, val_tp *val);   <====
void      vt_put_name       (const name_tp name, val_tp *val);
void     vt_put_date       (const date_tp date, val_tp *val);
void      vt_put_per        (const per_tp per  , val_tp *val);

val_kind  vt_get_val_kind   (const val_tp val);
long      vt_get_int        (const val_tp val);
Real      vt_get_real       (const val_tp val);
boolean   vt_get_bool       (const val_tp val);
name_tp   vt_get_name       (const val_tp val);
date_tp   vt_get_date       (const val_tp val);
per_tp    vt_get_per        (const val_tp val);

void         vt_exit                 (void);


#endif

Ik heb vroeger c geprogged en ben laatst nog even een tijdje bezig geweest met c++. Maar ik zou niet weten wat hier aan mankeerd.

[D2k]

bool is een reserved keyword zo te zien

[Alarmnummer]

D2k schreef op 13 January 2003 @ 13:29:
bool is een reserved keyword zo te zien

Idd.

Gefixed. Bool even gerenamed naar b.

[D2k]

* D2k is helemaal zo gek nog niet

[farlane]

Als je de mogelijkheid hebt om de dll te recompileren, zou je erover kunnen denken om daarvoor visual studio te gebruiken.

De c compiler van MS kent ( als extensie ) wel exceptions. Daarmee kun je o.a. ook access violations afvangen.

( Zie ook dit topic )
[rml][ NT Debug] Crashende comm driver[/rml]

[Alarmnummer]

Ik ben nu al zover dat ik hem met en zonder c++ kan compileren. Ik heb nu een hele zooi flags aangezet maar ik moet verder nog even uitzoeken hoe ik die dll exceptions kan opvangen in delphi.

[edit]
Als ik compileer met c++ dan kan ik de dll niet laden, en zonder c++ wel. Waar kan dit aan liggen?

[ Voor 23% gewijzigd door Alarmnummer op 13-01-2003 16:03 ]

[farlane]

Declareer je exported functies als extern "C" om C++ name decoration te vermijden.

[Alarmnummer]

farlane schreef op 13 January 2003 @ 16:04:
Declareer je exported functies als extern "C" om C++ name decoration te vermijden.

Ok.. is dit compatible met c? Het zou erg fijn zijn als de code zowel met de c als de c++ compiler kan werken.

[edit]
Ik zie hier een compiler optie:

underscore on externs. Als ik die disable, dan is het ook goed?

[ Voor 18% gewijzigd door Alarmnummer op 13-01-2003 16:16 ]

[.oisyn]

whoami schreef op 13 January 2003 @ 12:05:

Ik denk niet dat dit zal werken. Die dll is immers in C geschreven, en voor zover ik weet kent C geen exceptions.

errors (gpf, segfault, pagefault, etc.) worden in VC++ vertaald naar C++ exceptions, misschien kent Delphi ook een soortgelijk systeem?

[farlane]

Alarmnummer schreef op 13 January 2003 @ 16:14:
[...]

Ok.. is dit compatible met c? Het zou erg fijn zijn als de code zowel met de c als de c++ compiler kan werken.

[edit]
Ik zie hier een compiler optie:

underscore on externs. Als ik die disable, dan is het ook goed?

Nee, gebruik dan #ifdef ___cplusplus ( of hoe het ding ook heet onder Borland ) om je de declaraties.

like so:

C++:

#ifdef __cplusplus
extern "C"
{
#endif

void exported_blaat_functie();

#ifdef __cplusplus
}
#endif

Wat die compiler optie doet weet ik niet eigenlijk.

[MSalters]

extern "C" is C++ voor "Deze functie heet onder water ook exported_blaat_functie en niet exported_blaat_functie__returns_void__no_arguments". In C++ mag je n.l. functies hebben die dezelfde naam hebben, maar verschillende argumenten.

Wat er overigens gebeurt met de DLL is dat Windows een Structured Exception genereert. MSVC kan die opvangen met __try / __catch. Je kunt 'm ook in de MSVC debugger laten runnen ("attach to process"), en onder de menu optie debug/exceptions bij de optie "break on exceptions" alle niet-C++ exceptions aanvinken. Je kunt dan bij een Access Violation de module zien. Misschien heeft Delphi dezelfde SEH debug handler, dan heb je een betere stack trace.

[matthijsln]

MSalters schreef op 13 januari 2003 @ 16:48:
extern "C" is C++ voor "Deze functie heet onder water ook exported_blaat_functie en niet exported_blaat_functie__returns_void__no_arguments". In C++ mag je n.l. functies hebben die dezelfde naam hebben, maar verschillende argumenten.

Het return type hoort overigens niet bij een C++ functietype, dus als je een operator++ bijvoorbeeld wil overloaden moet je nogal een hack gebruiken...

Over het probleem: wat krijg je als je de app in de Delphi debugger draait? Het lijkt me het handigst om eerst proberen een debugger te gebruiken om te localiseren waar het fout gaat zonder extra code te introduceren.

De Delphi debugger is voor niet-Delphi code helaas niet erg geschikt, dus als dat niet veel zinvols oplevert OllyDbg is wel een aanrader, die begrijpt de meeste debug symbol formaten van Microsoft en Borland wel: http://home.t-online.de/home/Ollydbg/ (is wel op assembler-niveau georienteerd).

[curry684]

Zoek eens op de __set_se_translator functie. Als je die gebruikt en met wat logging implementeert in je C-dll moet je wel kunnen zien wat er gebeurt (waarschijnlijk een access violation ergens).

[MSalters]

matthijsln schreef op 13 januari 2003 @ 17:28:
[...]
Het return type hoort overigens niet bij een C++ functietype, dus als je een operator++ bijvoorbeeld wil overloaden moet je nogal een hack gebruiken...

Toch wel. Dat je niet kunt overloaden op return type is een ander verhaal. Maar dat het return type wel degelijk onderdeel is van het functietype blijkt wel uit functie pointers: een int(*)() kun je niet aan een void(*)() assignen.

[Alarmnummer]

Ik zit nog even met de afhandeling van fouten in de dll.

Op welke manier gebeurt dit? Als er een fout optreed in de dll (desnoods een fout die door debugging statements worden gevonden), hoe kan de delphi code dit opmerken? Wordt er bij die aanroep naar die dll en bij het opmerken van een fout, een delphi exception opgeworpen zodat de delphi exception handler deze uiteindelijk voor de kiezen krijgt?

Of gebeurt er iets anders?

[edit]
Dit is trouwens een voorbeeld van een delphi/dll call.

var
ii_init_esm : function(DSN, FCMODEL: c_string): Boolean; stdcall;

Ik zie in de help dat stdcall niets met exception/error handling doet.

Ik zit zelf op dit moment idd ook te denken aan het wrappen van alle methodes. Maar voor een big fuckup in de stack kan ik daar natuurlijk niets mee, omdat het hele proces zwaar verminkt kan raken en zelfs de delphi error handlers niet meer werken.

[edit2]
Ik ben er intussen achter dat bij 'normale' fouten in de dll zoals bv een nullpointer fout dat delphi netjes een exception opwerpt. Het wrappen van methodes is verder niet meer nodig.

[ Voor 48% gewijzigd door Alarmnummer op 14-01-2003 11:52 ]

[Alarmnummer]

Het hele c gebeuren (dll) maakt gebruikt van dynamische arrays van standaard groote . Het kan gebeuren dat een resultaat niet in zo`n buffer past. Op wat voor manier kan ik fouten hierin makkelijk terug vinden. De compiler heeft helaas geen bounds checking of iets in die geest.

[ Voor 14% gewijzigd door Alarmnummer op 14-01-2003 11:57 ]

[LordLarry]

Range Checking voor de gewone array's. Anders helpt misschien een programmatje dat memory leaks detecteerd:

http://www.automatedqa.com/products/aqtime.asp
of
MemorySleuth van TurboPower. Helaas is TurboPower net gestopt http://www.turbopower.com/

er is ook een gratis variant, maar ik weet niet hoe goed deze is:
http://www.automatedqa.com/products/memproof.asp

[Alarmnummer]

Ik heb borland c++ 5 erop gezet en daarin zit codeguard. Ik hoop daarmee voldoende informatie te voorschijn te toveren. thanx anyway

[farlane]

Alarmnummer schreef op 14 January 2003 @ 11:56:
Het hele c gebeuren (dll) maakt gebruikt van dynamische arrays van standaard groote . Het kan gebeuren dat een resultaat niet in zo`n buffer past. Op wat voor manier kan ik fouten hierin makkelijk terug vinden. De compiler heeft helaas geen bounds checking of iets in die geest.

Ik snap deze niet helemaal.

De arrays worden vanuit Delphi doorgegeven en je dll gaat ervan uit dat ze een bepaalde grootte hebben?

In dat geval zou je de grootte van de arrays vanuit Delphi echt moeten doorgeven aan je dll.

[Alarmnummer]

farlane schreef op 14 januari 2003 @ 16:11:
[...]


Ik snap deze niet helemaal.

De arrays worden vanuit Delphi doorgegeven en je dll gaat ervan uit dat ze een bepaalde grootte hebben?

In dat geval zou je de grootte van de arrays vanuit Delphi echt moeten doorgeven aan je dll.

Zo bedoel ik het niet In de c code worden allemaal buffers aangemaakt om bv een sql query op de db uit te voeren. Deze buffers zijn allemaal van een standaard grote (256 - 4096 bytes) en die dingen staan overal verspreid zonder gebruik te maken van een constante.

Soms krijg een functie een array table namen aan. Op basis van die tablenames moet dan een SQL query uitgevoerd worden. Als je 1000 tablenamen meegeeft van gemiddel 10 karacters, dan zit je al op meer dan 11000 karacters (komma`s niet vergeten ) de hele query is nog een stuk langer. Maar toch zijn die buffers van een vaste size. Het is altijd op hoop van zegen gegaan: hopen dat je maar niet te ingewikkelde vragen gaat stellen.

Dit gebeurt dus honderden keren her en der verspreid in de c code en dus niet iets dat je eenvoudig kan aanpakken.

[.oisyn]

wheehehe, je beschrijft het alsof ik door 5 jaar oude c-code van mezelf doorspit

maar serieus, ik voel met je mee

[Alarmnummer]

Een groot deel van de instabiliteitsproblemen zijn daar denk ik ook het gevolg van. Maar die Codeguard van Borland C die plakt er een enorme lading extra checks in, en boundschecks ed zijn er ook onderdeel van (en dat hebben we dus ook nodig).

Trouwens. Als je free aanroept van borland c, wordt de pointer dan ook op null gezet zodat je niet per ongeluk met een al vrijgegeven stuk geheugen kan knoeien?? *heeft ff geen borland c handleiding thuis liggen*

[ Voor 8% gewijzigd door Alarmnummer op 14-01-2003 21:14 ]

[LordLarry]

Nee, een Free zet niets op null. Dat moet je zelf doen. Of de functie FreeAndNil gebruiken

[Alarmnummer]

LordLarry schreef op 14 January 2003 @ 21:50:
Nee, een Free zet niets op null. Dat moet je zelf doen. Of de functie FreeAndNil gebruiken

bij delphi heb ik dat op een aantal plaatsen ook al gedaan. Een nullpointer is even wat duidelijker Gelukkig hebben ze een functie gemaakt (ik heb het nu over c code) waar dit in wordt gedaan. Het hele systeem maakt (hopelijk) gebruik van deze functie en daarom is het dus geen probleem om hem meteen even op null te zetten.

[ Voor 4% gewijzigd door Alarmnummer op 14-01-2003 21:58 ]

[farlane]

Alarmnummer schreef op 14 January 2003 @ 20:56:
[...]

Dit gebeurt dus honderden keren her en der verspreid in de c code en dus niet iets dat je eenvoudig kan aanpakken.

Op die manier. Hmm, lijkt erop dat je nog wat werk te doen hebt.

[Alarmnummer]

Nog een simpele delphi vraag, maar kan het niet vinden in de boeken.

Ik wil graag een globale unit variable hebben voor een logger class die ik even in elkaar heb gezet (debuggen met dialoogjes is k*t).

var
logger: TLogger;

Maar nu heb ik alleen de variable aangemaakt, maar niet geinitialiseerd (en meteen initaliseren is nog niet gelukt). Hoe krijg ik dit voor elkaar? (ik kan hem natuurlijk wel een een functie aanroep van een andere unit plakken, maar dat vind ik ook maar weer zozo).

[ Voor 5% gewijzigd door Alarmnummer op 15-01-2003 11:32 ]

[matthijsln]

Alarmnummer schreef op 15 January 2003 @ 11:28:
Ik wil graag een globale unit variable hebben voor een logger class die ik even in elkaar heb gezet (debuggen met dialoogjes is k*t).

OutputDebugString() werkt ook met de Delphi debugger, het resultaat kan je dan zien in een van de debug windows.

var
logger: TLogger;

Maar nu heb ik alleen de variable aangemaakt, maar niet geinitialiseerd (en meteen initaliseren is nog niet gelukt). Hoe krijg ik dit voor elkaar? (ik kan hem natuurlijk wel een een functie aanroep van een andere unit plakken, maar dat vind ik ook maar weer zozo).

Je kan het in een initialization sectie zetten of in je .dpr.

code:

...

initialization
logger := TLogger.Create();
finalization
logger.Free();
end.

(of zoiets, Delphi is al weer een tijdje geleden)

[Alarmnummer]

[gefrustreerd]
Aargh. Mijn dll doet het op mijn eigen bak, maar bij mijn collega`s zorgt het voor een vastloper. En dat terwijl ik de dll weer in zijn orginele toestand heb terug gezet. Hoe moet ik nu in godsnaam debuggen als ik het niet eens kan testen???

[farlane]

Als de fouten echt voor een stack smash zorgen, kun je de meest vreemde verschijnselen tegenkomen. ( Ik spreek uit ervaring )

De methode die genoemd is ( de av opvangen dmv de exception handling die de MS C compiler kent was voor mij een oplossing )

Veel succ6

[Alarmnummer]

Het enigste dat anders is, is dat ik nu borland c builder 6 gebruik ipv borland c++ 5.5. De applicatie doet het keurig netjes op mijn bak, maar de nieuwe dll zorgt ervoor dat bij mijn collega`s de applicatie niet meer reageert.

[edit]
en dit soort grappen worden toegevoegd om errors te omzeilen.

code:

procedure TFeitenForm.VragenFormulier1Click(Sender: TObject);
begin
  //NieuwKindForm.show();  //om een ODBC error te vermijden bij
  //NieuwKindForm.close(); //sluiten van exporteren naar sjabloon 2992002vh
  InvulForm2.Show;
  //self.Close;
end;

Oja.. En vaak worden fouten in de c code helemaal niet afgehandeld. Er wordt vanuit een c code een dialoog omhoog geworpen met een 'behulpzame' foutmelding. Maar er wordt verder geen aandacht meer aangeschonken. De aanroepende procedure weet dus niet dat er iets is misgegaan

[ Voor 66% gewijzigd door Alarmnummer op 16-01-2003 11:37 ]

[Alarmnummer]

Mijn nieuwste fix:

code:

 try
     freeAndNil(c);
  except
     //negeer de foutmelding. Schijbaar heeft een of andere randdebiel het geheugen
     //al vrijgegeven in het c gedeelte.
  end;

*heeft de smaak goed te pakken van dit soort programmeren