Crash Debug

BlitzMax Forums/BlitzMax Programming/Crash Debug

Romanski(Posted 2011) [#1]
Hello,

I have a really hard time finding the bug that crashes the game I'm currently working on. There is no error message nor is there any line-indication from the debuglog that leads me to the problem.

I would like to find out where exactly the program crashes but the code is really big. So is there any hack or any way I can solve this problem?

any help appreciated
roman


ziggy(Posted 2011) [#2]
My suggestion would be to run the game from a computer with an IDE that integrates a debuger, and use a Debug build (not a release build).
You can also, on windows, make a debug build in console mode, and debug the program using the command line, but it won't be as nice and straight forward as using a proper debuger.


GfK(Posted 2011) [#3]
If the code is 'really big', there must've been a point where it worked, then you added some code, and it stopped working?


Romanski(Posted 2011) [#4]
thank you both.

@ziggy: what kind of ide or debuger do you recommend?

@Gfk: shure. I added and added and added and thought well this one problem I will solve later on ;)

It mostly happens when I unload and load a new level. but I don't know where the problem is.


ziggy(Posted 2011) [#5]
Well, I would recommend the one I've done, but it deppends on your target. If you're on MacOs, maybe the community IDE MaxIDE whould do it.
On window, you can try the free version of BLIde (the one I do, there's a free version) http://www.blide.org I don't think there are many alternatives other than this ones.


Czar Flavius(Posted 2011) [#6]
What are you using already? The default IDE comes with a debugger?


Tommo(Posted 2011) [#7]
It might be a stack overflow (too many recursive calls).
Blitzmax debugger has no report on this.


jsp(Posted 2011) [#8]
If you used recursive functions Blitzmax Version 1.32 was the last version which detected a stack overflow.
Not sure if you can try to compile with that one, just to check where the fault is.


Czar Flavius(Posted 2011) [#9]
Why did it stop?


xlsior(Posted 2011) [#10]
Possibly due to Blitzmax' switchover to a different garbage collector somewhere along the way?


jsp(Posted 2011) [#11]
The signal handling code that used to live in appstub is no longer there it seems.
If the app throws a segv or other, it will just fail.

Mark said:
I was uncomfortable with the sighandler in release mode because it meant Max wasn't behaving consistently across platforms and, worse, that Max had appropriated signals from the app.


Romanski(Posted 2011) [#12]
Thanks for all the many replies,

I was able to find the bug in the meantime by taking out everything and putting it back step by step. I was just wondering about this missing feature of the debugger in general, because when it crashes/stops it never to jumps to the line where it happens. Maybe I have to inform myself about the debugger and it's possibilities a bit more anyway..

btw it were several problems but mainly something with loading textures/entities and releasing it..., so nothing big. Now I'm happy that it runs flawlessly.