This is quote from the site:
http://www.opengl.org/developers/code/features/KilgardTechniques/oglpitfall/oglpitfall.html
maybe this is the problem
"4. Overflowing the Projection Matrix Stack
OpenGL’s glPushMatrix and glPopMatrix commands make it very easy to perform a set of cumulative matrix operations, do rendering, and then restore the matrix state to that before the matrix operations and rendering. This is very handy when doing hierarchical modeling during rendering operations.
For efficiency reasons and to permit the matrix stacks to exist within dedicated graphics hardware, the size of OpenGL’s various matrix stacks are limited. OpenGL mandates that all implementations must provide at least a 32-entry modelview matrix stack, a 2-entry projection matrix stack, and a 2-entry texture matrix stack. Implementations are free to provide larger stacks, and glGetIntergerv provides a means to query an implementation’s actual maximum depth.
Calling glPushMatrix when the current matrix mode stack is already at its maximum depth generates a GL_STACK_UNDERFLOW error and the responsible glPushMatrix is ignored. OpenGL applications guaranteed to run correctly on all OpenGL implementations should respect the minimum stack limits cited above (or better yet, query the implementation’s true stack limit and respect that).
This can become a pitfall when software-based OpenGL implementations implement stack depth limits that exceed the minimum limits. Because these stacks are maintained in general purpose memory and not within dedicated graphics hardware, there is no substantial expense to permitting larger or even unlimited matrix stacks as there is when the matrix stacks are implemented in dedicated hardware. If you write your OpenGL program and test it against such implementations with large or unlimited stack sizes, you may not notice that you exceeded a matrix stack limit that would exist on an OpenGL implementation that only implemented OpenGL’s mandated minimum stack limits.
The 32 required modelview stack entries will not be exceeded by most applications (it can still be done so be careful). However, programmers should be on guard not to exceed the projection and texture matrix stack limits since these stacks may have as few as 2 entries. In general, situations where you actually need a projection or texture matrix that exceed two entries are quite rare and generally avoidable.
Consider this example where an application uses two projection matrix stack entries for updating a window:
void
renderWindow(void)
{
render3Dview();
glPushMatrix();
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glLoadIdentity();
gluOrtho2D(0, 1, 0, 1);
render2Doverlay();
glPopMatrix();
glPopMatrix();
glMatrixMode(GL_MODELVIEW);
}
The window renders a 3D scene with a 3D perspective projection matrix (initialization not shown), then switches to a simple 2D orthographic projection matrix to draw a 2D overlay.
Be careful because if the render2Doverlay tries to push the projection matrix again, the projection matrix stack will overflow on some machines. While using a matrix push, cumulative matrix operations, and a matrix pop is a natural means to accomplish hierarchical modeling, the projection and texture matrices rarely require this capability. In general, changes to the projection matrix are to switch to an entirely different view (not to make a cumulative matrix change to later be undone). A simple matrix switch (reload) does not need a push and pop stack operation.
If you find yourself attempting to push the projection or texture matrices beyond two entries, consider if there is a simpler way to accomplish your manipulations that will not overflow these stacks. If not, you are introducing a latent interoperability problem when you program is run on high-performance hardware-intensive OpenGL implementations that implement limited projection and texture matrix stacks."
Regards
Martin