[quote user="DaBookshah"]
I don't think either of you understand the WTF here. The WTF is that I wrote an opengl program, and deliberately introducing a stack overflow makes it work PERFECTLY. Removing the stack overflow results in weird behaviour.[/quote]
Reminds me of a bug I tracked down about 15 years ago in AIX 3.1, which also curiously featured SG's GL (the precursor to OpenGL).
I was working on a module for a scientific visualization package that read a particular data file format. The renderer for this package ran on a number of devices, including the "Sabine" graphics card for the RS/6000. Sabine was basically a rebranded SG graphics subsystem, and it ran GL, so the device-dependent portion of the renderer would open a GL window (on the X desktop) with the "openwin" function and then make a bunch of GL calls to draw in it.
Problem was, when you read a data file in this particular format and then tried to process and render that data, the openwin call would fail. Get the data into the program in any other fashion and you were fine. The file-processing code itself was some public-domain C code, and it did a lot of memory allocation and freeing, so on a hunch I commented out all the calls to free (with a macro, natch) in case the underlying problem was heap corruption. Bingo - openwin worked.
OK - so there was clearly a dup-free or a buffer overrun or some such thing in the file processor... but I desk-checked the whole thing and couldn't find it. I instrumeted the code and logged every single allocation and free, then processed the log with an awk script, which verified that they were all fine. So then I wrote a C program that read the log, performed all the same allocations and frees, touched the first several bytes of each allocated area, and then called openwin. And openwin failed.
I eventually cut this down (using binary search, of course) to a C program that allocated 11 areas, touched the first 16 bytes of each, freed 3 of them, and called openwin, which would fail. (To this day, this remains my personal favorite cut-down demonstration of a bug.) I sent that off to AIX support.
I got a response the next day: there was a bug in the AIX C runtime implementation of free, and under the right conditions it would stomp some memory that the GL library used. Apparently prerelease testing of both the C runtime and the GL library failed to catch it.
So in that case, deliberately introducing a bug (a memory leak) did make a program work correctly.