How can glClear cause application crashes?

[a***@gmail.com]

Hi all,

my application had the exceptionally bad habit of crashing on certain
user actions, but often in different places (once code was changed
somewhere).

It's a big application, and finding the crash location kept me busy
for several weeks, in total.

Finally, it seems I've found the cause of the crash: The glClear
function (MS OGL implementation)

If I call glClear(clrDepthBufferBit), the application will crash
(sometimes in wglMakeCurrent, sometimes in glGetIntegerv, sometimes
even in a totally different part of the executable.
If I remove this line of code, the application will run just fine.

I'm still using glClear(clrColorBufferBit), it does not seem to cause
any problems.

Any ideas, WHY glClear would cause a crash (probably overwriting a
portion of memory it doesn't own) when clearing the depth buffer?

Thanks!

Robert

[fungus]

Post by a***@gmail.com
Any ideas, WHY glClear would cause a crash (probably overwriting a
portion of memory it doesn't own) when clearing the depth buffer?

I don't think this can be the problem.


--
<\___/>
/ O O \
\_____/ FTB. Remove my socks for email address.

[crjjrc]

Post by a***@gmail.com
Any ideas, WHY glClear would cause a crash (probably overwriting a
portion of memory it doesn't own) when clearing the depth buffer?

glClear is often the first OpenGL call made when rendering a new
frame. Are you sure the OpenGL context is current?

- Chris

[a***@gmail.com]

Post by crjjrc

Post by a***@gmail.com
Any ideas, WHY glClear would cause a crash (probably overwriting a
portion of memory it doesn't own) when clearing the depth buffer?

glClear is often the first OpenGL call made when rendering a new
frame. Are you sure the OpenGL context is current?
- Chris

The context is current, wglMakeCurrent is some code lines before, and
if it fails, I bail out of the function.
In my case, glDrawBuffer(dbBack) is the first OGL call after
wglMakeCurrent.

And in response to fungus, I can't believe it either, but application
behavior seems to prove otherwise.
I've even had the crash on different machines, next I'll try if the
fix works for all of them (in this case it would rule out any graphic
driver dependency).

Is there any way to access the OGL source code in order to properly
debug this?

Robert

[Wolfgang Draxinger]

Post by a***@gmail.com
Is there any way to access the OGL source code in order to
properly debug this?

There is not "THE" OpenGL source code. Every driver has it's very
own implementation.

You've got a problem somewhere in your program. Did you even use
a debugger to get a call/stack backtrace?

Wolfgang Draxinger

[fungus]

Post by a***@gmail.com
And in response to fungus, I can't believe it either, but application
behavior seems to prove otherwise.

It could be memory corruption - bad pointers, etc.
which just happens to cause a crash in glClear()


--
<\___/>
/ O O \
\_____/ FTB. Remove my socks for email address.

[jbwest]

Post by fungus

Post by a***@gmail.com
And in response to fungus, I can't believe it either, but application
behavior seems to prove otherwise.

It could be memory corruption - bad pointers, etc.
which just happens to cause a crash in glClear()
--
<\___/>
/ O O \
\_____/ FTB. Remove my socks for email address.

Multiple dll's and MS software rendering? yikes. You've tried the debug
runtime I presume with memory checking.?
Don't forget the rules about freeing memory created in another DLL and other
M$ restrictions.

Yes, glClear will do a big block of memory wipe in the software renderer.
Start sprinkling glClear's all through your code
to "binary chop" down to the offending code section. I bet you'll find
someone is chasing a NULL pointer.

Good luck.
jbw

[Dave Eberly]

Post by a***@gmail.com
If I call glClear(clrDepthBufferBit), the application will crash
(sometimes in wglMakeCurrent, sometimes in glGetIntegerv, sometimes
even in a totally different part of the executable.
If I remove this line of code, the application will run just fine.

The cause is not likely an OpenGL thing. You speculated that
glClear might be overwriting a portion of memory it does not
own. More likely is that your application is overwriting memory
somewhere, possibly even data on the call stack within the
function that calls glClear.

Have you tried to run your application with something like Purify or
DevPartner studio or some other memory tracking package?

--
Dave Eberly
http://www.geometrictools.com

[a***@gmail.com]

Post by Dave Eberly
The cause is not likely an OpenGL thing. You speculated that
glClear might be overwriting a portion of memory it does not
own. More likely is that your application is overwriting memory
somewhere, possibly even data on the call stack within the
function that calls glClear.
Have you tried to run your application with something like Purify or
DevPartner studio or some other memory tracking package?
--
Dave Eberlyhttp://www.geometrictools.com

I've tried just about anything. Tool like Purify and MemoryValidator,
unfortunately, can't seem to find anything substantial in our
application.

I've today got verification that, with the glClear(DepthBufferBit)
removed, the crashes no longer occur on two other machines. And those
were crashes with VERY different behavior (in an entirely different
part of the application).

Plus, I had the crash absolutely reproducible on my machine, now I can
do what I want, it doesn't happen.

My code is in Visual Basic 6, so I don't have any pointers to
overwrite memory with. And I have removed all API calls that do direct
memory operations, while the crash still occurred (before I removed
glClear)

VB6 (plus some C and several 3rd party DLLs without debug information)
also makes the application difficult to handle for the likes of
Purify.
I located the error using "code skip" - I added returns / exits at the
beginning of various functions, until I had whole parts of the
application practically removed (because no code would run there),
without changing the memory layout of the app too much (really
removing the code would change the crash behavior too much, until the
crash would no longer occur, because the memory overwritten seemed to
be non-critical).

BTW, I don't use hardware-accelerated OGL on most machines, but use
software-GL (MS implementation), because while it does have it's
faults, I at least know most of them by now.

Robert

[fungus]

Post by a***@gmail.com
Plus, I had the crash absolutely reproducible on my machine, now I can
do what I want, it doesn't happen.

This add further weight to the "memory corruption"
theory.

Post by a***@gmail.com
My code is in Visual Basic 6, so I don't have any pointers to
overwrite memory with. And I have removed all API calls that do direct
memory operations, while the crash still occurred (before I removed
glClear)
VB6 (plus some C and several 3rd party DLLs without debug information)

Suspect those DLLs....


--
<\___/>
/ O O \
\_____/ FTB. Remove my socks for email address.