[c++] shared memory object en schrijfrechten

[elgringo]

Ik heb een DLL geschreven die een shared memory object aanmaakt als deze nog niet bestaat.
Verder heb ik een interface geschreven waar de gegevens in het shared memory object kunt wijzigen. De DLL is een plug-in voor een simulatie.

Beide applicaties controleren of het shared memory object bestaat, zo niet dan wordt deze gemaakt icm een mutex om de schrijf rechten te bepalen. Het shared memory object wordt in beide applicaties als read-write geopenend alleen degene die de mutec heeft mag schrijven.

Toch krijg ik af en toe memory fouten: adress xxxxx could not be read
En de simulatie (incl programma) loopt vast.

Hoe komt dit? Is het zo dat één van de 2 applicaties toch gaat schrijven terwijl hij niet mag of omdat beide het shared memory object als rw geopend hebben, of nog iets anders?

Edit:
hij wordt zo aangemaakt, in beide applicaties:

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));

info:
Createfilemapping
MapViewOfFile

[ Voor 29% gewijzigd door elgringo op 07-09-2006 12:03 ]

[TheNameless]

Ik heb voor de rest geen ervaring met shared memory, maar kan het niet iets zijn met de mutex en DLL boundaries?

Ik neem aan dat je ook altijd de mutex lockt bij een schrijf en lees actie?

[.oisyn]

Die mutex boeit voor geen meter, dat is alleen voor jou om te zorgen dat je niet per ongeluk data zit te overschrijven. Maar dat mag wel gewoon, beide apps kunnen tegelijkertijd naar hetzelfde stuk geheugen schrijven.

Weet je wel zeker dat dat adres wat je probeert te lezen binnen je stukje shared mem valt?

MayaFreak schreef op donderdag 07 september 2006 @ 12:19:
Ik heb voor de rest geen ervaring met shared memory, maar kan het niet iets zijn met de mutex en DLL boundaries?

Nee, hoe had je je dat dan voorgesteld?

[ Voor 29% gewijzigd door .oisyn op 07-09-2006 12:23 ]

[elgringo]

.oisyn schreef op donderdag 07 september 2006 @ 12:21:
Die mutex boeit voor geen meter, dat is alleen voor jou om te zorgen dat je niet per ongeluk data zit te overschrijven. Maar dat mag wel gewoon, beide apps kunnen tegelijkertijd naar hetzelfde stuk geheugen schrijven.

Weet je wel zeker dat dat adres wat je probeert te lezen binnen je stukje shared mem valt?


[...]

Nee, hoe had je je dat dan voorgesteld?

Ja, alle data past erin.
Het shared memeory object wordt gemaakt vanuit een struct. De grote van deze struct is de grote van het shared memory object. En de struct wordt gewoon gebruikt om informatie te lezen en te schrijven. Dus:

C++:

//---------------------------------------------------------------------------
#ifndef SmoStruct
#define SmoStruct
struct Smo {
    bool bOpened;               // file opened to write
    bool bInit;             // true if smo is ready for use; hamilton is ok
    double dStates[6000];       // 2*dimension*(nodes+1)  +1 is for the R state
    double dStatesBegin[6000];      // 2*dimension*(nodes+1)  +1 is for the R state for the begin
    double dCoefficient[6000];      // Number of coeffiencts for the Hamilton
    int iNumberOfVariabeles[6000];      // number of varabeles per term
    int iVariabeles[24000];             // which states;
    double dFriction;           // Friction per integration step
    int iDimension;         // Number of dimension (1,2,3)
    double dDeltaT;             // stepsize
    double dTime;           // runtime
    int iSteps;             // number of steps taken
    double dH;              // current H
    double dHBegin;         // H when it starts
    bool bEnableHCalculation;       // Calculate H each step?
    int iNumberOfNodes;         // Number of nodes (ex. R)
    double dMatrix[1000][1000];     // start matrix
    int iStepsToDraw;           // number of steps
    bool bSync;             // true=draw, false=calculate
    double dKR;             // Spring constant for R term
    int iCoupledToNodeIn;               // which node is used for connection IN   R=0
    int iCoupledToNodeOut;              // which node is used for connection Out  R=0
    int iCoupledType;                   // 0: Add, 1 desired
    int iCoupledFlow;                   // 1=F in, v out; 0=v in, F out
    bool bSolid[1000];                  // solid node?
    bool bGravity;                     // Gravity in the Hamilton
    
    
};
#endif

//---------------------------------------------------------------------------

C++:

pSmo=(Smo*)pBuf;
pSmo->iVariabeles[1200]=.... // (of iets dergelijks)

Maar hetzelfde stukje geheugen kan door 2 processen tegelijk beschreven worden zonder fouten?
Die mutex is alleen voor eigen 'veiligheid' dus?

EDIT:
Of kan het zijn dat bijv bij het afsluiten was mis gaat? Dat het geheugen al vrijgegeven is oid?

Afsluiten (programma, DLL, wordt gestopr) gaat zo:

C++:

free(dStatesDot);
    free(dStatesDot2);
    UnmapViewOfFile(pBuf);
    CloseHandle(hMapFile);
    ReleaseMutex(hMutex);
    CloseHandle(hMutex);

dStatesDot(2) zijn 2 geheugens is de DLL
hMutex is de handle naar de mutex

[ Voor 67% gewijzigd door elgringo op 07-09-2006 12:34 ]

[.oisyn]

Yup. Twee threads mogen toch ook tegelijk naar hetzelfde geheugen binnen de applicatie schrijven? Dit is niet veel anders, het physieke geheugen is hetzelfde, het verschil is dat het (waarschijnlijk) op verschillende plekken in de applicaties gemapped is.

Maar die struct garandeert natuurlijk niet dat je geen bufferoverruns hebt. Als je pSMO->bSolid[12345] leest/schrijft ben je de sjaak

[ Voor 119% gewijzigd door .oisyn op 07-09-2006 12:33 ]

[elgringo]

.oisyn schreef op donderdag 07 september 2006 @ 12:29:
Yup. Twee threads mogen toch ook tegelijk naar hetzelfde geheugen binnen de applicatie schrijven? Dit is niet veel anders, het physieke geheugen is hetzelfde, het verschil is dat het (waarschijnlijk) op verschillende plekken in de applicaties gemapped is.

Maar die struct garandeert natuurlijk niet dat je geen bufferoverruns hebt. Als je pSMO->bSolid[12345] leest/schrijft ben je de sjaak

Klopt, maar dat gebeurd niet, das al uitvoerig getest
Hij zegt ook dat hij het memory niet kan readen, lezen moet toch altijd kunnen?

Hoe kan ik eigenlijk een DLL debuggen?

[ Voor 3% gewijzigd door elgringo op 07-09-2006 12:36 ]

[.oisyn]

Gewoon vanuit je IDE, alleen dan de executable opgeven die je dll laadt om te runnen. De rest gaat vanzelf.

[TheNameless]

.oisyn schreef op donderdag 07 september 2006 @ 12:21:

[...]

Nee, hoe had je je dat dan voorgesteld?

Iets met een klok en klepel..
Ik heb ooit eens iets gelezen over dat een shared mutex een named mutex moet zijn of iets dergelijks.
Ik kan het me gewoon wel in denken dat daar iets mee fout kan gaan.

Maar in een DLL kan je toch gewoon breakpoints zetten?
Hier in VS2003 wel iig

[elgringo]

.oisyn schreef op donderdag 07 september 2006 @ 12:55:
Gewoon vanuit je IDE, alleen dan de executable opgeven die je dll laadt om te runnen. De rest gaat vanzelf.

Hoe werkt dat precies?

ik heb hem met bcb bij run|parameter ingevoerd. Maar als ik met mijn hostapplicatie, de simulatie wil starten gebeurd er niet en loopt mijn hostapplicatie muurvast

Nee doet ie toch niet. De DLL wordt nml niet meteen geladen. Als ik mij simulatie start kan ik met bcb niet meer debuggen. De run button wordt weer actief ipv de pauze knop

[ Voor 42% gewijzigd door elgringo op 07-09-2006 13:22 ]

[.oisyn]

Tja, geen ervaring met BCB. Misschien is VS 2005 express een optie?

[elgringo]

De hostapplicatie die ik gebruikte was alleen een loader. de daadwerkelijke hostapplicatie is ../vwnt.exe 20sim.im.

Maar als ik vwnt.exe bij hostapllicatie zet en 20sim.im bij parameters wordt ie niet geladen en krijg ik de fout dat hij 20sim.im niet kan vinden. Vanuit een batrch bestand werkt het wel. Hoe kan ik zorgen dat ie wel werkt

[Creepy]

Al geprobeerd om het volledige pad naar het 20sim.im bestand op te geven?

[elgringo]

Creepy schreef op donderdag 14 september 2006 @ 11:38:
Al geprobeerd om het volledige pad naar het 20sim.im bestand op te geven?

ja dat was idd de fout, nadat er aanhalings onheen werkte het een stuk beter. Hij doet het inmiddels