The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Problem with eglSwapBuffers and heap corruption

I've got a bit of a problem with the use of eglSwapBuffers in my Series 60 code.

I was running my app full screen which seemed to automatically make it use the direct screen access code.

When I displayed the menu I was hitting memory corruption errors. I tracked this down to the menu display causing loss of direct screen access, which freed the bitmap being used for this but OpenGL still had a pointer to this now dead bitmap and in the call to glClear it corrupted the heap trying to write to this dead pointer.

I debugged into the sample apps to see how they avoided this problem and discovered that apps like Example3D and GlExample were calling eglSwapBuffers at the start of their draw cycles and this call sorted out the dead pointer problem and stopped the heap corruption.

This solution also fixed my problem but it doesn't seem to be right thing to do, surely eglSwapBuffers should be called straight after the drawing code to copy it to the display ASAP. The method used in those sample apps is postponing the screen update until the next animation cycle causing an unwanted lag in updating the display.

I've just had a look through some of the other sample apps and believe they are surviving this problem by luck, the ones that run in full screen but don't call eglSwapBuffers until after their draw cycle are actually drawing to freed memory but getting away with it because writing to freed heap space doesn't actually corrupt anything unless some other code tries to use that heap.

I've confirmed this by making the following change in the \OpenGlExamples\3Dexamples\openglex\rain sample.

In the first call to User::Heap().Check(); after the menu was displayed the code paniced with User-49, what has happened is the alloc of 100 bytes has gone into the space freed by deleting the direct screen buffer, the opengl draw code has then trashed the free cell pointer at the end of this new alloc cell, which was picked up by the heap check afterwards.

At the moment I can't see any solution other than calling eglSwapBuffers before my draw code, and having to put up with the lag in updating the display.

But I suggest this whole situation needs to be looked at carefully to prevent other people hitting this same problem I did with heap corruption, it was very very hard to track down, involved writing a heap dump function to analyse what was corrupting my heap, lots of memory watch break points to track back step by step who was responsible for the corruption, then watching the same memory watch points in the sample apps to work out why they didn't hit the same problem as me.

At the very least all the sample apps need to be changed so they aren't writing to freed memory.