Exit errors on Linux Apps

Closing a graphics window (pressing the "x" button in the window's corner) on Linux gives me:

XIO:  fatal IO error 22 (Invalid argument) on X server ":0.0"
      after 57 requests (57 known processed) with 0 events remaining.

The app does end, but not without throwing this error to the system

I've tried to put in an "If AppTerminate() = True" statement in the loop to see if I could catch the event and shut down "properly", but it seems to ignore this line (could be that I am doing wrong?).

Ubuntu 8.04, nVidia 7900GTX, BlitzMax 1.30

Did this happen to you before?

Unsure when this started (i.e. before Ubuntu 8.04, or before BlitzMax 1.30) as I just noticed it while trying to hunt down why I am getting exit error messages on Linux,

A small sample program will display this error just fine-

Graphics 640, 480
Repeat
   Cls
   Drawline Rand(640), Rand(480), Rand(640), Rand(480)
   Flip
Forever

...now press "[X]" to close the window.

Also, another exit error message on Linux is to call GCCollect() before calling END. If your program has a lot of variables, you'll get an "appstub.linux signal handler 11 WARNING: Child process terminated by signal 11" error because the GCCollect() process isn't finished before the program terminates. Easy enough to fix: leave GCCollect() out of there...but it probably shouldn't spit that error.

Ok, I'm running Ubuntu 8.04 and BMax 1.30 with SVN modules and when I compile the above code and click the X it closes without an error message.

Hmmm....

I am running a nVidia GeForce 7900 card with restricted drivers, with mid-level visual effects. How about you?

I have an ATI Radeon VE/7000 with no hardware drivers and no effects.

Are you sure that's the case?

The problem with the signal 11 handler is that it catches the seg fault, handles it nicely, but in turn makes it hard to see where it went wrong - ie. if you try running your mini example it will probably not stop at the seg fault point.
It is possible to disable that handler, so that running it through gdb will allow you to pinpoint the exact location of the error (although, depending on where the error occurs this may or may not be helpful to you - eg. if it breaks in a library, fine, if it breaks in BlitzMax generated assm, bad luck).