[c++] geheugen fout

[elgringo]

Ik heb een dll voor een simulatie programma geschreven (20-sim:http://www.20sim.com/) deze combi van dll en simulatie geeft een geheugen fout.

De fout:
De instructie op 0x00d09031 verwijst naar geheugen op 0x0252320C. De lees- of schrijfbewerking ("read") op het geheugen is mislukt.
Klik op op ok om het programma te beëindigen

Normaliter zou ik denken dat het een geheugen fout is (defect memory oid). Nu lijkt me het toch in het programma te zitten. Ik maak gebruik van een shared memory object wat een mutex heeft om te aan te geven of de dll of het programma om de dll insteld mag schrijven. Lezen moet eigenlijk altijd goed gaan (toch?)

Waar zou ik een oorzaak van deze fout kunnen zoeken?
Ik heb de gealloceerde geheugens nagekeken en niets wordt groter als dat hij mag zijn. Het lijkt mij ergens in het shared memory te zitten maar weet niet waar ik deze moet gaan zoeken.

[ Voor 11% gewijzigd door elgringo op 13-09-2006 18:51 ]

[NMe]

Gebruik je geen ongeïnstantieerde objecten of gebruik je reeds opgeruimde objecten niet elders alsnog? Wanneer je multithreaded programmeert loop je snel het risico dat dit gebeurt, dus ik zou het even heel goed nalopen.

Overigens vind ik het vreemd dat je een geheugenfout vanuit een programma dat je zelf gemaakt hebt meteen op de hardware gooit. De meest waarschijnlijke bron van de fout is nog altijd je eigen code.

[elgringo]

-NMe- schreef op woensdag 13 september 2006 @ 19:00:
Gebruik je geen ongeïnstantieerde objecten of gebruik je reeds opgeruimde objecten niet elders alsnog? Wanneer je multithreaded programmeert loop je snel het risico dat dit gebeurt, dus ik zou het even heel goed nalopen.

Overigens vind ik het vreemd dat je een geheugenfout vanuit een programma dat je zelf gemaakt hebt meteen op de hardware gooit. De meest waarschijnlijke bron van de fout is nog altijd je eigen code.

Dat eerste dacht ik dus ook. Ik maak van een struct een shared memory object en deze wordt door windows pas verwijderd als hij door alle partijen gesloten is. Dat is het enige wat gebruikt wordt. Het shared memory object bevat ook alleen waardes en geen objecten.

En dat tweede bedoel ik dus. Met een gekocht programma duidt dit op een hardware fout, in mijn geval waarschijnlijk niet (dat bedoelde ik te zeggen).

Kan het misschien zo zijn dat een lees en schrijf actie elkaar net kruizen dat dan de fout ontstaat?

[Soultaker]

Het kan praktisch overal door komen, en je geeft wel heel weinig contextinformatie.

Wordt je DLL wel correct geladen; wordt er ueberhaupt ooit code uit je DLL uitgevoerd? Crasht het programma in je DLL code, of in de applicatie? Hoe ziet de stack trace eruit? Je hebt het over een mutex, maar wordt je DLL ook concurrent aangeroepen (lijkt me helemaal niet vanzelfsprekend voor een simulatie)?

Overigens wordt met 'shared memory' doorgaans geheugen bedoeld, dat gedeeld wordt door verschillende processen. Dat is vermoedelijk niet waar jij mee bezig bent. Geheugen dat vanuit meerdere threads gebruikt wordt moet je inderdaad wel afschermen met een mutex (ofzoiets), maar dat maakt het geen shared memory.

[MisterData]

Fout die ik als beginner ook ooit heb gemaakt is aan te nemen dat een pointer naar een willekeurige plek in het geheugen zomaar in een ander proces ook verwijst naar datzelfde stukje geheugen, en door de pointer te versturen naar het andere proces (via een message) gewoon een soort 'shared memory' te hebben, wat natuurlijk nevernooit werkt

[MSalters]

Nou ja, nevernooit, het werkte op Win95 probleemloos. Maar je wist toen al dat het ooit fout zou gaan.

[Soultaker]

@MisterData:
Klopt, maar het lijkt me dat je daar bij een 'normale' plug-in DLL geen last van hebt. Daarom is het wel handig om te weten hoe de boel precies in elkaar steekt.

[ Voor 4% gewijzigd door Soultaker op 13-09-2006 21:14 ]

[elgringo]

Soultaker schreef op woensdag 13 september 2006 @ 20:41:
Het kan praktisch overal door komen, en je geeft wel heel weinig contextinformatie.

Wordt je DLL wel correct geladen; wordt er ueberhaupt ooit code uit je DLL uitgevoerd? Crasht het programma in je DLL code, of in de applicatie? Hoe ziet de stack trace eruit? Je hebt het over een mutex, maar wordt je DLL ook concurrent aangeroepen (lijkt me helemaal niet vanzelfsprekend voor een simulatie)?

Overigens wordt met 'shared memory' doorgaans geheugen bedoeld, dat gedeeld wordt door verschillende processen. Dat is vermoedelijk niet waar jij mee bezig bent. Geheugen dat vanuit meerdere threads gebruikt wordt moet je inderdaad wel afschermen met een mutex (ofzoiets), maar dat maakt het geen shared memory.

De DLL wordt correct geladen, sommige simulaties gaat goed, andere niet (zie fout is ts), het programma crasht ism mijn DLL, wie de oorzaak is weet ik eigenlijk niet, maar ik weet voor 90% zeker dat dit mijn DLL is omdat de simulatiesoftware en bestaand en werkend product is.
Hoe kom ik aan een stacktrace?
En wat houdt een DLL concurrent aanroepen in?

Ik heb wel degelijk shared memory. Ik heb een DLL die een Hamiltonfunctie simuleert hoe deze obgebouwd is staat in het shared memory die door een 2de applicatie gemaakt en veranderd kan worden, hiervoor dient de mutex, dat het niet gelijktijdig gebeurd. Verder heeft de applicatie een thread om het verloop van de simulatie te tekenen, maar deze is geheel suspend als de fout voorkomt.

Shared memory wordt zo gemaakt:

C++:

hMapFile = CreateFileMapping(INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE,0,sizeof(Smo),szName);
pBuf = MapViewOfFile(hMapFile,FILE_MAP_ALL_ACCESS,0,0,sizeof(Smo));

en als ie al bestaat:

C++:

hMapFile = OpenFileMapping(FILE_MAP_ALL_ACCESS,FALSE,szName);
pBuf = MapViewOfFile(hMapFile,FILE_MAP_ALL_ACCESS,0,0,sizeof(Smo));

[ Voor 11% gewijzigd door elgringo op 14-09-2006 09:42 ]

[.oisyn]

Is je probleem niet nog steeds exact hetzelfde als in je vorige topic: \[c++] shared memory object en schrijfrechten ?

Open de BCB help en ga lezen over hoe je een DLL kan debuggen. Dan weet je wáár het crasht. Zonder die info kunnen wij je verder ook niet helpen.

.edit: gezien je andere topic die nu gesloten is heb je dat al gedaan. Weet je wel zeker dat de juiste dll wordt ingeladen (bijvoorbeeld je hebt een release dll in die dir staan, terwijl je nu een debug dll probeert te debuggen?)

[ Voor 69% gewijzigd door .oisyn op 14-09-2006 11:26 ]

[elgringo]

.oisyn schreef op donderdag 14 september 2006 @ 10:54:
Is je probleem niet nog steeds exact hetzelfde als in je vorige topic: \[c++] shared memory object en schrijfrechten ?

Open de BCB help en ga lezen over hoe je een DLL kan debuggen. Dan weet je wáár het crasht. Zonder die info kunnen wij je verder ook niet helpen.

.edit: gezien je andere topic die nu gesloten is heb je dat al gedaan. Weet je wel zeker dat de juiste dll wordt ingeladen (bijvoorbeeld je hebt een release dll in die dir staan, terwijl je nu een debug dll probeert te debuggen?)

Ik had de verkeerde host-applicatie. Ik had een loader en moet vwnt.exe 20sim.im zijn. Alleen als ik vwnt.exe bij de hostapplicatie zet en 20sim.im bij de parameters werkt het niet en kan bcb de 20sim.im file niet vinden (die overigens in dezelfde dit staat als vwnt.exe)

wat ben ik dom..... "" deden wonderen...

[elgringo]

Nu krijg ik een fout tijdens het debuggen van de DLL:
Project vwnt.exe faulted with the message "floating point invalid operation at 0x00cdecd8". Proces stopped.

Waar kan dit op duiden (deze fout komt na een standaard fout van 20-sim zelf)
De fout komt nadat de dll gesloten wordt met de functie:

C++:

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{
        return 1;
}

Na de return 1, komt de error. Moet ik wat in deze functie nog wat afsluiten oid?

[ Voor 36% gewijzigd door elgringo op 14-09-2006 14:04 ]

[BCC]

Debuggen is een van de eerste dingen die je leert als je begint met programmeren. Ik krijg nogal het idee dat jij:
a) geen idee hebt wat je precies aan het doen bent.
b) weinig tot geen programmeer ervaring hebt en daardoor niet kan debuggen.

Beide dien je eerst zelf op te lossen, zodat je een concreet probleem hier neer kan leggen.

[elgringo]

BCC schreef op donderdag 14 september 2006 @ 14:08:
Debuggen is een van de eerste dingen die je leert als je begint met programmeren. Ik krijg nogal het idee dat jij:
a) geen idee hebt wat je precies aan het doen bent.
b) weinig tot geen programmeer ervaring hebt en daardoor niet kan debuggen.

Beide dien je eerst zelf op te lossen, zodat je een concreet probleem hier neer kan leggen.

Ik weet wel degelijk hoe je moet debuggen ook van DLLs. Deze DLL kreeg ik echter niet gedebugd ivm een foute hostapplicatie te gebruiker (de loader) ipv het echte programma. Heej ik maakt soms domme fouten en ben er trots op

Verder weet ik nu waar momenteel de fout ligt; in mijn dll die afgesloten is en misschien wat problemen veroorzaakt, of in de hostapplicatie. Omdat dit de eerste keer is dat ik zo'n fout heb leg ik het hier niet om te kijken of ik zo wat wijzer wordt.