Exception Access Violation when closing via [X]
BlitzMax Forums/BlitzMax Programming/Exception Access Violation when closing via [X]
| ||
| When I close my game by clicking on the X icon in the corner of the window I get: Windows Exception EXCEPTION_ACCESS_VIOLATION If I close may application normally there's no error. I've recently switched to multi threaded if that's any help but the error occurs even if I don't create any threads. |
| ||
| Modified the game so it compiles in non threaded mode and the error still happens so I don't think it's related to threading. Anyone have any ideas? |
| ||
| Since it's crashing, you might find a GDB backtrace could help determine the location of the issue. :-) |
| ||
| Are you calling AppTerminate () in your loop? This is needed to detect the Close [X] gadget hit. I'm a bit surprised it's crashing though -- it normally just gets ignored without AppTerminate. (By closing the appplication normally, do you mean via End?) |
| ||
| Yeah I mean end. No I'm not calling AppTerminate. Never heard of it! I'll try that. So far it seems to be related to the sound commands. If I make the game hang (infinite loop) and use [X] to terminate it crashes after the first sound command but not before. I'm using the B3D SDK but I recently switched to the Bmax sound commands so I don't know if that's an issue. Could it be the SDK that's detecting the [X]? Hence it working without Appterminate? JP |
| ||
| Ah, AppTerminate probably won't count, then, if you're using the Blitz3D SDK to open/handle the window. An infinite loop followed by [X] click would probably cause Windows to shut the program down (after a few clicks with no response from the program anyway). Not sure if that would trigger the Blitz exception thing, but it would be how Windows normally deals with a program not responding to a Close hit. |
| ||
| I don't mean a 'not responding' type of loop. I mean just make the program stop progressing so I know exactly how far it's progressed when I click [X] I think it was something like: local x=0; while x=0;clscolor rnd(255),0,0;cls;flip(0);delay(1);wend. This just gives some old 8-but style loading bars. Just a convenient way of making the game 'hang' so I could test what the [X] did. If I placed that line before any sound commands the game exits normally. If I placed it after the first sound command I get the exception. |
| ||
Hmm. I don't think AppTerminate () will work with the B3D SDK, but this works in plain BlitzMax:Graphics 640, 480 Local x=0 While x=0 SetClsColor Rnd(255),0,0;Cls;Flip(0);Delay(1) If AppTerminate () Print "Hello" End EndIf Wend You could try something like this, but I suspect it'll fail since the B3D SDK will be handling the window input/updates, etc. Have you tried working with bbSetBlitz3DTitle? This can throw up a requester when the [X] gadget is hit, allowing you to catch the hit, though the user then chooses whether to exit or cancel (resume). |
| ||
| It looks like Appterminate is irrelevant as you suspected. Adding the bbsetBlitz3DTitle command does inded bring up the confirmation box. But if you click OK the exception appears. There's obviously some difference between clicking [X} and END. If I add an OnEnd command the cleanup function gets called by both methods of ending but the [X] still triggers the exception. |
| ||
| I guess the BlitzMax audio playback routine doesn't like being interrupted 'externally' (ie. by the SDK input stuff). I kind of suspect all this might be work-around-able with the SDK's event callbacks, but that's all a little outside my grasp, I'm afraid... How about going back to the Blitz3D SDK audio commands? I don't think there's much real benefit to using the BlitzMax-native audio if you're just using the basics. Does the problem still occur there? You might consider dropping Mark an email if that doesn't help, as the low-level interactions between the SDK's window handling and BlitzMax (or BlitzMax's audio) would be way outside of my understanding, sorry! BTW 'End' means the program itself is deciding to call it a day, and that can be handled nicely. Clicking [X] means Windows just sends a 'quit' message to the program's window (handled by the SDK DLL in this case), so what happens is dependent on how that quit message is handled by the app. It can easily be ignored by the app (nothing happens), mis-handled, or not even received by the main program, so they're certainly different. |
| ||
| Yeah, I'll try going back to the old commands. Or just removing all audio temporarily. I think I switched because I wanted to load the audio on a separate thread to increase boot up times (which worked) and thought it prudent to not use SDK commands in a thread. The blitzmax commands seemed better too once I'd re-written everything. Sounds like I may end up back to square one and ditch the multi threading. |
| ||
| Well I've ditched the thread thing and switched back to SDK sounds. All fine apart from music. The bbplaymusic command doesn't seem to work at all. In fact it returns a channel even if you try to play a non existent file. And silence even if the file exists. I'm using .ogg files which work with loadsound. |
   |