[VB6]Unhandled Exception bij build 'optimized for fast code'

[Adion]

Ik heb dus een (tamelijk groot) programma in Visual Basic 6.
Als ik het in de IDE run heb ik geen problemen, als ik het gewoon zonder optimizatie compileer heb ik ook geen problemen.
Als ik compileer en 'optimize for fast code' kies, lukt het compileren, maar als ik het programma dan start krijg ik na een tijdje een 'Unhandled Exception' en dus een echte crash van het programma (dus niet zo'n error die door de visual basic error handling wordt opgevangen, maar een die door windows wordt opgevangen)

Als ik dan debug vraag (wat kan omdat 'Create Symbolic Debug Info' aanstond) dan zie ik dat de error juist voor een functie-oproep gebeurde.
De error zelf is :
"Unhandled exception at 0x00000000 in djDecks.exe: 0xC0000005: Access violation reading location 0x00000000."
Betekend dit dat Visual Basic vergeten is de locatie van deze functie in te vullen ofzo?

Is hier een fix voor of heeft iemand hier ook al problemen mee gehad, en zijn er eventueel andere (en betere) visual basic compilers te vinden?
Ik gebruik Visual Basic 6 met SP5

[Sponge]

Je zou een logfile functie kunnen maken, waarmee je snel iets naar de schijf kan schrijven (elke keer openen en sluiten, anders slaat het programm niets op als ie crashed!!). Dan zet je gewoon op een aantal punten neer:

AddLog "A"
...code
AddLog "B"
...code
AddLog "C"

etc.

Het is zeker dirty.. maar op deze manier kun je wel ontdekken waar het probleem zit. Ik heb zulk soort errors ook wel gehad, die achteraf soms best wel logisch waren. Trouwens onder "Advanced" staan de vinkjes well allemaal uit he? (just in case)

[Adion]

De vinkjes staan inderdaad uit ja.
Zoals ik al zei, als ik debug kies als het programma crashed kom ik in Visual C terecht, en omdat er een Symbolic Debug Info file aanwezig is zie ik daar ook de Visual Basic code met de positie waar hij gecrashed is.

Dat is dus gewoon een functie die bij een gewone compile wel goed gaat.
Ik vond het verdacht dat de error zich op adres 0x00000000 zou voordoen, want dit lijkt mij te betekenen dat de verwijzing naar de functie niet correct is.

Ik zal eens proberen met een log functie of de positie dezelfde is.

[farlane]

Je programma probeert een geheugenlocatie te lezen die niet in zijn eigen addressspace ligt.

Overigens is dit niet makkelijk ( maar zeker doable ) om met vb alleen voor elkaar te krijgen. Zijn er misschien ActiveX controls oid die tijdens initialisatie iets verkeerd doen?

Voor welke functie crashed de applicatie? Wat gebeurd er in die functie? Is het een form_load of een Sub Main ?

[Adion]

Het programma start in Sub Main (in Module1), het is ook in deze functie dat het crashed bij een oproep naar een andere functie die ik zelf geschreven heb (in een andere module).

Ik gebruik maar 1 ActiveX control (die ik zelf geschreven heb) in het programma, en die zit op een form die op dat moment nog niet geladen is.

Ik denk niet dat het een fout is in de code, omdat zowel in de IDE, als bij een compile zonder optimize er geen problemen zijn.
Het lijkt erop dat VB bij het compileren 'vergeten' is om de locatie van die functie in te vullen?

[farlane]

Probeer de functie die wordt aangeroepen eens te analyseren.

Draai je applicatie eens zonder de aanroep van de functie die volgens jou de crash veroorzaakt.

Haal eens wat verdachte aanroepen uit deze functie.

Kortom, probeer het probleem te localiseren zodat je een oplossing kunt bedenken.

Maakt deze functie gebruik van functies uit je ActiveX of een andere externe functie?

Feit is dat het niet vaak voorkomt dat met alleen VB(A) functies een access violation kan worden verkregen.

[Adion]

De functie maakt geen gebruik van ActiveX ofzo, wel van een aantal win32 functies.

Ik heb de functie eens verwijderd daar, en dan gebeurd er het volgende:
Het programma start, gaat verder tot net voor deze functie en lijkt dan vast te lopen (er gebeurd niets meer). Maar het programma crashed niet meer.

Deze functie kwam voor in een lus die er vereenvoudigt zo uitziet :

code:

For a = 0 To 2
  ...
  ShowWindow a
  ShowOtherWindow a
  ...
Next

De ShowOtherWindow a oproep gaf oorspronkelijk de fout, dus die heb ik eruit gecommentarieerd.
Omdat het daarvoor leek vast te komen zitten heb ik een MsgBox "Doing " & a voor de showwindow oproep gezet.
Bij het uitvoeren verscheen Doing 0, maar telkens ik op ok drukte kwam er opnieuw Doing 0 op.
De lus word dus niet verhoogt, en het programma blijft oneindig in deze lus vastzitten.

Binnen de lus staan slechts een 10-tal regels code, en deze wijzigen de variabele a niet, en geven de variabele ook enkel By Value door aan andere functies.

Zoals al gezegd werkt alles wel goed als ik de optimalizatie uitzet.

edit:
Favor Pentium Pro stond ook aan, maar dat uitzetten veranderd niets aan het probleem

[Verwijderd]

code:

For a = 0 To 2
  ...
  ShowWindow a
  ShowOtherWindow a
  ...
Next

output :
ShowWindow 1
ShowOtherWindow 1

show je hier niet 2x window 1 ??

[Adion]

Nee, OtherWindow is een ander venstertje

En als ik de MsgBox moet geloven gebeurd er de hele tijd
ShowWindow 0
ShowWindow 0
ShowWindow 0
...

[farlane]

Wordt a gedeclareerd? ( Option Explicit moet echt aan )

Welke type heeft a? Probeer eens een ander type.

Is a ook een globale var oid?

Probeer eens Next a.

Probeer eens een andere naam.

[edit]

Doen die Win32 functies iets met a? ( Wordt a als pointer of reference meegegeven ? )

Als a een window handle is, is het wel een geldige ?

Kortom, als je Win32 functies gebruikt is het wel goed mogelijk dat je iets verkeerd doet, want die zijn minder streng dan VB.

Check ook het formaat van je declares. Klopt dit allemaal? ( Vooral volgorde,typen van je parameters, ByRef/ByVal en het returntype )

Visual Basic:

Public Declare Function ShowWindow Lib "user32" Alias "ShowWindow" (ByVal hwnd As Long, ByVal nCmdShow As Long) As Long

[cablepokerface]

Het is een suggestie voor dit probleem van niks ... maar is migreren naar VB.NET een optie ?

[farlane]

cablepokerface schreef op 09 september 2002 @ 16:22:
Het is een suggestie voor dit probleem van niks ... maar is migreren naar VB.NET een optie ?

Lijkt me dat migreren idd niet je eerste keuze moet zijn. Je leert van dit soort dingen ( ook al zijn ze erg vervelend op het moment ) wel wat.

[Paulstartrek]

Ik ben niet zo bekend met VB maar verhoogt de expressie 'a=0 TO 2' wel de variabele a? De for loop in Borland C werkt niet op die manier. Zowiezo staat het dan al tussen haakjes.

[farlane]

Paulstartrek schreef op 09 september 2002 @ 16:28:
Ik ben niet zo bekend met VB maar verhoogt de expressie 'a=0 TO 2' wel de variabele a? De for loop in Borland C werkt niet op die manier. Zowiezo staat het dan al tussen haakjes.

Excuses hiervoor maar dat ik kon het niet laten ...

[Adion]

Het gaat hier over een projectje van ondertussen een 10000 regels code ofzo, dus het minste dat ik dan zou moeten kennen is toch wel hoe een for-lus werkt in de taal waarin ik schrijf.

a is gedeclareerd binnen de sub main als een Long.

Binnen de lus staan slechts een 10-tal regels code, en deze wijzigen de variabele a niet, en geven de variabele ook enkel By Value door aan andere functies.

De waarde van a wordt dus absoluut NIET door mijn code gewijzigd.

Option Explicit staat in die module niet op, maar de compiler zou daar toch overweg mee moeten kunnen?

Als ik gewoon de hele For lus wegdoe verschuift het probleem zich gewoon naar een stukje verder in mijn programma.
Opnieuw een functie-oproep, deze keer vanuit een form naar een module met opnieuw de error :

Unhandled exception at 0x001567e7 in djDecks.exe: 0xC0000005: Access violation writing location 0x00000000.

Ik kan nog wel eens proberen om overal Option Explicit op te zetten, maar anders wordt het blijkbaar gewoon compilen zonder optimalizatie?

edit:
Ik heb ondertussen al Option Explicit opgezet in deze Module en in de modules die opgeroepen worden vanuit de for-lust.
De fout heeft zich opnieuw verschoven, en zit nu op volgende regel in de for-lus:
vis_DrawSoundFX(a) = True
en deze variabele is in een andere module gedefinieerd als
Public vis_DrawSoundFX(2) As Boolean

[Janoz]

Bij deze foutmelding kan ik eigenlijk maar aan 1 ding denken. Er staat dat je probeert te schrijven naar 0x00000000. Dit is over het algemeen de null pointer en is dus sowieso niet geheugen voor je programma. Ik neem aan dat je wel bekend bent met het principe 'null-pointer'? Waar het in het kort eigenlijk opneer komt is dat je iets probeert weg te schrijven in iets wat je nog niet hebt gedeclareerd.

_{Hmm, lees nu edit.. Heb je nog steeds die null pointer exception?}

[Adion]

Jep, identiek dezelfde fout.
Ik weet inderdaad wel wat een null-pointer is, maar daar heeft de code zoals ik ze getypt heb toch niets mee te maken?

Op school heb ik vorig jaar de basiswerking van een compiler en een linker enzo geleerd, en daar heb ik geleerd dat die in een aantal stappen werkt.
Eerst wordt het programma gecompileerd, en worden verwijzingen die nog niet bekend zijn eerst opengelaten.
Nadien zou de compiler dan, eenmaal hij een volledige tabel heeft van alle symbolen, de opengelaten symbolen moeten opvullen.
Stel dat visual basic het adres null laat staan, en dat hij daarna 'vergeten' is om deze een juiste waarde te geven?

Ik betwijfel nog steeds dat het aan mijn code ligt, omdat alles wel perfect werkt zonder optimize.

Ik zou best wel over willen gaan naar .NET, maar de automatische conversie gaat natuurlijk niet perfect en het lijkt voor zover ik er al mee geexperimenteerd heb ook een stuk tragere code te genereren dan VB6.

offtopic:
De .hdc property die ik gebruikte om de snelle win32 tekenfuncties te kunnen gebruiken bestaat niet rechtstreeks meer in .NET, net zoals AutoRedraw.
Ik ben tussendoor wel aan het proberen GDI+ enzo te leren gebruiken, maar ik heb op dit moment nog te weinig .NET ervaring om daarop over te stappen

edit:
Ondertussen nog een aantal modules en forms option explicit gezet, en nog steeds geen beterschap

[farlane]

Het gaat hier over een projectje van ondertussen een 10000 regels code ofzo, dus het minste dat ik dan zou moeten kennen is toch wel hoe een for-lus werkt in de taal waarin ik schrijf.

Lijkt me ook. Die reactie was ook niet van mij hoor.

Option Explicit staat in die module niet op, maar de compiler zou daar toch overweg mee moeten kunnen?

Deze Option Explicit kun ( moet naar mijn idee ) je gebruiken of de variabele waarmee je werkt wel de variabele is waarmee je denkt dat je werkt. Het is niet verplicht, de compiler werkt ook zonder, maar het kan voor de meest ranzige bugs zorgen ( Typo's zorgen voor spontane nieuwe variabelen etc )

Als ik gewoon de hele For lus wegdoe verschuift het probleem zich gewoon naar een stukje verder in mijn programma.

Lijkt erop dat je programma al voor die lus vernaggeld is.

Ik kan nog wel eens proberen om overal Option Explicit op te zetten, maar anders wordt het blijkbaar gewoon compilen zonder optimalizatie?

Zoals gezegd lijkt me dit verstandig, het is alleen niet de _oorzaak_ van je av. Het kan je misschien wel helpen om hem te vinden.

Ik heb ondertussen al Option Explicit opgezet in deze Module en in de modules die opgeroepen worden vanuit de for-lust.
De fout heeft zich opnieuw verschoven, en zit nu op volgende regel in de for-lus:
vis_DrawSoundFX(a) = True
en deze variabele is in een andere module gedefinieerd als
Public vis_DrawSoundFX(2) As Boolean

Het is wel weer die a die hierin voorkomt. Lijkt erop dat die variabele zelf vernaggeld is. Kun je hem ook private & lokaal maken, om te testen of die a door iets overschreven wordt?
Probeer eens eenzelfde variabele te declareren met een andere naam en die te gebruiken. Treden dan dezelfde verschijnselen op?

[Adion]

farlane schreef op 09 september 2002 @ 21:32:
Lijkt me ook. Die reactie was ook niet van mij hoor.

Had ik al gezien hoor

Deze Option Explicit kun ( moet naar mijn idee ) je gebruiken of de variabele waarmee je werkt wel de variabele is waarmee je denkt dat je werkt. Het is niet verplicht, de compiler werkt ook zonder, maar het kan voor de meest ranzige bugs zorgen ( Typo's zorgen voor spontane nieuwe variabelen etc )

Ja, dat weet ik wel. Normaal declareer ik wel variabelen hoor, en die vul ik dan als ik ze nodig heb in met CTRL+SPACE zodat typfouten normaal niet voorkomen.
Het is alleen soms handig als je een nieuwe functie bent aan het maken van snel een variabele kan gebruiken om even mee te testen.
Bijna alle forms en modules hebben ondertussen trouwens Option Explicit opstaan.

Lijkt erop dat je programma al voor die lus vernaggeld is.

Ik vermoed tijdens het compileren

Het is wel weer die a die hierin voorkomt. Lijkt erop dat die variabele zelf vernaggeld is. Kun je hem ook private & lokaal maken, om te testen of die a door iets overschreven wordt?
Probeer eens eenzelfde variabele te declareren met een andere naam en die te gebruiken. Treden dan dezelfde verschijnselen op?

Had ik al gezegd denk ik, a is al binnen de sub main gedeclareerd met
Dim a As Long
Ik heb nog eens geprobeerd expliciet voor die lus een andere variabele te declareren en die te gebruiken, en het resultaat bleef hetzelfde.

[farlane]

Heb je al geprobeerd om je app op een andere PC te draaien?

Of als het echt VB is is misschien opnieuw installeren een mogelijkheid.

Eventueel wil ik je prog wel ff compileren om te zien of 'tie hier ook crashed..

[Janoz]

Ik neem aan dat de for lus niet het aller eerste is dat in je programma gebeurt...

Ik denk dat je

Lijkt erop dat je programma al voor die lus vernaggeld is.

niet te snel af moet doen met

Ik vermoed tijdens het compileren

Ikzelf heb ook wel eens heel vreemde problemen gehad (was wel op linux, en met C++) waarin mijn programma op een bepaald punt een segmentation error gaf. Ik wis 100% zeker dat die code goed was. Achteraf bleek dit ook het geval te zijn, en lag de fout helemaal aan het begin van mijn programma omdat ik er vanuit was gegaan dat een stukje gealloceerd geheugen automatisch op 0 zou staan.

Wat ik hier eigenlijk mee wil zeggen is dat ik het erg twijfelachtig vind dat het probleem in de compiler zit. Daar hebben vele profs jaren aan gewerkt en d'r komt ff een 'VB-er' die ff gaat vertellen dat zijn prog goed is en de compiler fout ..

Kijk ff of je naast het declareren van variabelen er ook voor zorgt dat ze de waarde krijgen die ze horen te krijgen en ga er niet standaard van uit dat iets op 0 of null is geinitialiseerd.

[Adion]

Ik zal er natuurlijk eens naar kijken of er daarvoor iets fout zou kunnen gegaan zijn, maar het is echt grotendeels VB code en daar kan je zo makkelijk niet iets fout doen zonder dat je een foutboodschap krijgt.
VB intitializeerd trouwens echt variabelen op 0.

Farlane: Ik zal eens op een andere computer proberen.
Als ik er morgen niet uit ben zal ik eens kijken of ik de source bijeen kan bundelen in een zipje en dan wil ik het wel eens opsturen (heb vandaag niet zoveel tijd)

[Janoz]

Adion schreef op 11 september 2002 @ 20:29:
VB intitializeerd trouwens echt variabelen op 0.

En dat kan nu juist het verschil zijn tussen 'gewoon' uitvoeren en 'optimized for vast code' compileren. Ik zou zeggen, kijk er eens naar