EXCEPTION_ACESS_VIOLATION is Killing me
BlitzMax Forums/BlitzMax Programming/EXCEPTION_ACESS_VIOLATION is Killing me
| ||
| Hi, I'm about to finish a long project with blitmax. Program ran fine, I then updated from 1.39 to 1.44 (new GCC and stuff). Had to recompile all the modules (including the bah modules from brucey). The thing is, my program crashes with an exception access violation error, and it's kind of random. I mean... It always happens in the same "state" or moment of the application but it doesn't happen all the time. When I run it in debug mode I can play the game for an hour and never crashes. In release mode it does, but not always... What would you do? I've tried to wrap the Update() and Render() methods of my app in a Try Catch, do a catch for TBlitzException and store it in a log. Still, program crashes w/o catching... What would you? I'm running out of ideas.. =/ Last edited 2011 |
| ||
| Which Brucey modules are you using, and which video card type have you got? Cheers Charlie |
| ||
| Are you running in threaded mode, or non-threaded? Did you disable Quick Build? |
| ||
| Hi, Brucey's modules are: bah.cairo bah.freeimage bah.database bah.dbsqlite bah.inet bah.libcurl Out of those, only bah.database connections are used in the offending code so, I dont know if I should worry about the rest. Didn't Disable Quick Build, running in non-threaded mode. Now that you mention Quick Build, how can it be the problem? Never thought of that... Video card is discarded i think, since it crashes on other computers as well (with different video cards). My "game" is being used in a classroom with 20+ users each one in a different computer. If I just could translate that exception_access_violation into something less... generic... or at least into something more detailed... Perhaps the debug version will crash too.. given time.. because I have never released a debug version of the software in the classroom to see if It crashes... Debug tests were done in my own computer.. Last edited 2011 |
| ||
| redownload 1.39 |
| ||
| redownload 1.39 Lol, That's my last resort. The "white image" bug in the macs haunts my application, and I think that was fixed past v42? I will indeed do that if I can't fix this...(jump to last update before 44) but I really want to give it a try and take advantage of the newer GC. Last edited 2011 |
| ||
| Didn't Disable Quick Build, running in non-threaded mode. Now that you mention Quick Build, how can it be the problem? Never thought of that... If you have quickbuild enabled and have code that uses multiple files, then it's possible that you are linking with some of the code that was compiled earlier with the old MinGW and possibly run into problems with Blitzmax design changes (garbage collector, etc.) Any time you switch MinGW versions or there are structural blitzmax changes, it's imperatives to recompile your stuff without QuickBuild... (Quickbuild speeds up compilation times by only recompiling things that have changed -- by leaving it on through a MinGW update you are essentially switching compilers mid-way through your project, which can lead to unexpected results.) |
| ||
| Any time you switch MinGW versions or there are structural blitzmax changes, it's imperatives to recompile your stuff without QuickBuild... I see... I will recompile all bah directory with bmk makemods -a bah, and do the same with all the other modules, and see what happens. Hope that fixes my problem! If not, I'll have to do what H&K said... Thanks for the advice =), Will update as soon as I see a change or something.. |
| ||
| The new GC was I thought, just a threaded build improvement. And as you a single threading... etc |
| ||
| Today I ran the 1.42 version of my program (before the newer GCC) and it had the same issue, so I can discard 1.44 as the main reason for my problem.... Is there a way I can have a more specific error besides "exception access"? Any technique you know or something? Try/Catches dont work =( |
| ||
| You can try a different debugger: http://code.google.com/p/beaverdbg/ |
| ||
| Hi Adam, So, you suggest me to replace the blitzmax debugger for this one and hope that the error it throws to the windows screen is more specific? Didn't know it was even possible to replace the default debugger... |
| ||
| I'm pretty sure you can, I've tried it in monkey mingw. Just run the debugger, then run the file, just make sure the file is built with debug mode. You may have to run the file OUTSIDE of Blitzmax IDE. |
| ||
| No. The BlitzMax debugger is a custom debugger. What you could do, is to run the application via gdb. When the program crashes, gdb will break at the crash and you would be able to view a backtrace. It may not be terribly useful though, since BlitzMax functions are not named in the trace - but others (c/c++ libs) are. |
| ||
| @Adam Thanks for the suggested alternative! I'll take it into account. @Brucey Will take a look at gbd too, thank you too! I again see the light at the end of the tunnel :) Last edited 2011 |
| ||
| Brucey's right, you can't debug with beaver (which is GDB). here's why i guess: http://stackoverflow.com/questions/1727945/how-to-debug-programms-written-in-fasm-under-linux-using-gdb Unless: http://code.google.com/p/fasmsyms/ But in the meantime, try Olly debugger, you might be able to get some clue to where it crashes... http://www.ollydbg.de/ Last edited 2011 |
| ||
| Thanks Adam, will check ollydbg too... next week will be a debugging one! |
   |