[vb6] Debug probleem

[Adion]

Ik heb een vb6 programma dat soms een Overflow error genereert en dan crashed.
Het probleem is dat ik nog niet heb uitgevonden waar de overflow juist plaatsvind in de code.
Ik kan het programma ook niet in de vb debug mode starten, omdat dat problemen geeft met de dll referenties.
Ik heb eindelijk een aantal opeenvolgende handelingen gevonden die wel steeds de error genereren.
Nu dacht ik dus de applicatie te debuggen met behulp van visual c++ 6, wat normaal geen probleem is als ik in vb debug informatie laat maken tijdens het compileren.
Het probleem is echter dat als ik de exe start in visual c++ met debug->go (in visual c is een project geopend van een dll die ook gebruikt wordt door het vb programma) dat ik dan de error niet opnieuw gegenereerd krijg.

Ik heb ook al in de belangrijkste functies waar de fout zou kunnen zitten een On Error toegevoegd die dan wat error informatie weergeeft over de functie waarin de fout gebeurd.
Ook heb ik al gezocht naar alle delingen die gebeuren en gekeken of de code daarrond niet zorgt voor floating point delingen door (bijna) nul die vaak overflows geven, maar die zijn er ook niet meer denk ik.

Omdat de error er opkomt in een gewone message box (zoals vb6 dat altijd doet bij fouten die het zelf kan opvangen) neem ik aan dat de fout niet gegenereerd wordt door de gebruikte dll's, dus denk ik dat ik me kan beperken tot de visual basic code om de fout in te zoeken.

Is er iemand hier die eventueel nog suggesties heeft om de fout te vinden?

Ik zit er echt al een paar uur op te zoeken, en ik kan de fout echt niet vinden.
Doordat de fout niet altijd optreed heb ik ze dus ook niet ontdekt toen ik waarschijnlijk de code verandert heb die nu tot de fout leid.

Update: Het wordt weer allemaal lekker vaag
Ik heb een functie die in het programma erg vaak gebruikt wordt, die een tijd in milliseconden teruggeeft op basis van timerPerformanceCounter en timerPerformanceFrequency.
Deze functie deelt de counter door de frequency (deze worden eerst beide in een Currency variabele ingelezen, omdat Currency de enige 64-bit integer representatie in vb is) waarna het resultaat wordt ge mod tot het bereik van een 32-bit Long integer die dan wordt teruggegeven.
Deze functie is er al bijna van in het begin en heeft nooit voor problemen gezorgd.
Als ik er nu een On Error vooraan en achteraan een errorhandler die een msgbox met de err.Description geeft aan toevoeg, dan krijg ik wel de messagebox, maar geen description.
Als ik de on error weghaal krijg ik weer gewoon de Overflow error via visual basic.
Ik heb nu echter ook soms de error al kunnen opvangen in andere functie dmv On Error, en daar is de Description wel juist.

[ Voor 23% gewijzigd door Adion op 31-03-2003 14:35 ]

[Sponge]

Er zijn verscheidende methodes die je kunt gebruiken, maar nogal "dirty" zijn.. ze hebben me echter goed geholpen

Zorg dat je een simpele sub maakt die naar een file schrijft, en deze weer sluit. Zet op verscheidene plaatsen "addlog A","addlog B","addlog C","addlog D",etc. Als je weet dat het programma bij C die fout krijgt, moet de fout tussen C en D zitten.. en dan doe je daar nog een keer, echter dan met 1,2,3,4,5 ofzo

Overigens is er ook nog de debug console, die je met de API "OutputDebugString" kunt gebruiken. Je moet de console exe (gewoon soort DOS box )ook nog gebruiken, die heb ik via de DirectX8 SDK gekregen. Overigens werkt deze manier alleen met Win2k, en ik denk WinXP.

[Adion]

Ik heb zo'n functies, en ik heb ook al geprobeerd met gewone MsgBoxen te laten tonen op plaatsen waar ik denk dat hij net niet geraakt, en dan die verplaatsen tot ervoor enzo.
Wat ik daarmee uiteindelijk bereikt heb is het volgende :

Er is tot nog toe maar 1 combinatie van handelingen die ik gevonden heb die 100% zeker de error produceren. In de andere gevallen komt de bug soms opdagen, en wordt soms opgevangen in methodes waar ik de On Error code heb toegevoegd (ook niet steeds dezelfde functie)

De combinatie waarmee ik de bug steeds krijg, bestaat uit een aantal handelingen, gevolgd door een klik op een knop, waarna de bug verschijnt (in de mousedown event vermoed ik).
Nu heb ik alle knoppen enzo mbv een skin gemaakt, en de mousedown event controleert dus eerst waar er geklikt werd en bepaald op die manier welke functie moet opgeroepen worden.

Als ik na de functieoproep een MessageBox zet, krijg ik deze niet meer te zien wegens de crash.
Als ik voor de functieoproep een MessageBox zet, krijg ik de messagebox te zien, waarna er GEEN error komt.
In dit geval verschijnt de error echter wel tijdens het afsluiten van het programma, en dit in een functie waar de On Error code gewoon zijn werk doet.

Ook in de functie die opgeroepen wordt door de mousedown heb ik een On Error geplaatst, maar deze heeft nog nooit iets laten weten.

Ik snap er dus in ieder geval niets meer van...

Nog een update:
Na nog wat updates aan het programma kan ik de fout nu niet meer reproduceren op de manier waar het daarnet nog wel ging.
Het vervelende is nu dat ik dus totaal niet weet of de fout nu gaat wegblijven.
Het enige dat ik denk ik tussen de 2 builds waarin de fout verdween gedaan heb is de functiedeclaratie naar een dll gewijzigd zodat een bepaalde String niet meer werd meegegeven.
Het lijkt mij niet dat dit er eigenlijk iets mee te maken heeft, dus snap ik niet waarom de fout nu weg zou zijn...

edit:
Helaas, de bug is niet weg en komt nog steeds te voorschijn na wat testen

[ Voor 19% gewijzigd door Adion op 31-03-2003 20:48 ]

[Adion]

Ok, het is al wel een tijd geleden, maar ik denk dat ik eindelijk heb gevonden waar de fout ongeveer zit.

De fout zit waarschijnlijk WEL in mijn eigen dll's, want na wat code in 1 van de gebruikte dll's te wijzigen kwam de fout opnieuw ergens anders opvangen.

Ik kon op die manier in de visual basic code wel een on error toevoegen in een bepaalde functie die de fout dan opvangt (in deze methode werd geen methode van de dll opgeroepen)

De fout kwam echter niet meer terug nadat ik de nieuwe code in de dll had nagekeken en gevonden had dat enkele variabelen niet geinitializeerd werden en dus soms van grootorde 10^8 werden.

Wat ik dus vermoed is dat er in de dll een overflow optrad, dat daardoor de overflow flag gezet werd, die standaard in c/c++ niet bekeken word, maar die wel opgevangen werd door visual basic, in de eerstvolgende methode die door visual basic uitgevoerd word, omdat deze de overflow flag wel bekijkt.

Wat ik hieraan bijkomend vreemd vind, is dat de dll bijna zeker in een andere thread draait.
(Het gaat om een programma, waarbij geluidseffecten in de dll geprogrammeerd zijn en opgeroepen worden door de sound library wanneer dit nodig is, en de gui is in visual basic geschreven)
Maar nu vraag ik me dus wel nog een beetje af hoe en wanneer overflow fouten worden opgevangen. Tenslotte moet er toch minstens voor elk process 1 overflow flag zijn, of hoe zit dit juist?

[Verwijderd]

Adion schreef op 14 June 2003 @ 15:39:
Ok, het is al wel een tijd geleden, maar ik denk dat ik eindelijk heb gevonden waar de fout ongeveer zit.

De fout zit waarschijnlijk WEL in mijn eigen dll's, want na wat code in 1 van de gebruikte dll's te wijzigen kwam de fout opnieuw ergens anders opvangen.

Ik kon op die manier in de visual basic code wel een on error toevoegen in een bepaalde functie die de fout dan opvangt (in deze methode werd geen methode van de dll opgeroepen)

De fout kwam echter niet meer terug nadat ik de nieuwe code in de dll had nagekeken en gevonden had dat enkele variabelen niet geinitializeerd werden en dus soms van grootorde 10^8 werden.

Wat ik dus vermoed is dat er in de dll een overflow optrad, dat daardoor de overflow flag gezet werd, die standaard in c/c++ niet bekeken word, maar die wel opgevangen werd door visual basic, in de eerstvolgende methode die door visual basic uitgevoerd word, omdat deze de overflow flag wel bekijkt.

Wat ik hieraan bijkomend vreemd vind, is dat de dll bijna zeker in een andere thread draait.
(Het gaat om een programma, waarbij geluidseffecten in de dll geprogrammeerd zijn en opgeroepen worden door de sound library wanneer dit nodig is, en de gui is in visual basic geschreven)
Maar nu vraag ik me dus wel nog een beetje af hoe en wanneer overflow fouten worden opgevangen. Tenslotte moet er toch minstens voor elk process 1 overflow flag zijn, of hoe zit dit juist?

Dit boeit voor de rest niet.

Never let an exception escape your DLL!

De code in de .exe en de .dll zouden grof gezien onafhankelijk van elkaar moeten zijn. Een fout in de .DLL mag de werking van de .exe niet verstoren. De .dll zou bij een foutconditie bijvoorbeeld een foutcode terug moeten geven ofzo.

Is de DLL in Visual basic gemaakt?

zet in alle functies en procedures een Error Handler.

[Adion]

Visual Basic zorgt zelf dat errors mooi in hun eigen functie worden opgevangen, of doorgegeven zodat er een messagebox komt die de fout geeft.

De dll is in Visual C++ geschreven, en ik heb er geen idee van hoe en of je errors kan opvangen in c++, daar moet ik dus maar eens naar zoeken.