What does compiling in debug mode do?
BlitzPlus Forums/BlitzPlus Programming/What does compiling in debug mode do?
| ||
| I have an extremely rare crash bug in my BlitzPlus app, that just causes it to immediately drop to the desktop. I'm sure if it ever happened while I was running it with the IDE open in debug mode I'd get a helpful error showing me that I probably tried to access an invalid object at some point (most sudden drops have lead to that). Anyway, I haven't been able to reproduce it while playing in debug mode yet, since as I said it happens very rarely so probably has a very specific set of circumstances before it will happen. So I wanted to somehow find a way to make the executable itself spit out some kind of error in a log file or something to give me a hint of what's going on. But I can't find any error trapper routines documented anywhere, so I seem to have no way to spit out an error rather than dropping to the desktop. How does anyone debug a released product from customer reports with this?? Anyway, I thought perhaps if I compiled the .exe in debug mode it would be helpful, but even though I get a warning when compiling it that debug mode executables may run slower, it seems to run exactly the same and it still doesn't spit out any errors or log files that I can see (I even made it crash on purpose to check). So what exactly is the use of compiling a debug mode version of an exe in BlitzPLus? And does anyone have any tips on how I can track down a crash bug that I can't reproduce on demand (besides just playing it myself in debug mode for hours on end hoping it crashes)? |
| ||
| If you run it or compile it in debug mode you will get better error checking and reporting. If you want to do your own error checking, just open a debug file at program start and write any relevant variables to it using WriteLine(). Should be very simple. I always wrap non time critical functions with decent error checking. For example my SafeLoadImage() function checks to see if the image has loaded and reports an error otherwise. |
| ||
| When in debug mode, you can step through your program one line at a time. Just put a stop command in the code where you think the problem might be. Then the debug window will come up while your app is paused, and on the right side, you can see all the values of the global variables and variables in the current function. Then you can step forward one line at a time or continue execution. You can also alt tab out of your app if you want to stop it without using the stop command, and hit the stop button on the debug window instead. |
| ||
| Even with debug off, B+ should not just quit to the desktop. Sounds like a bug in the error trapper... |
| ||
| Yeah I know what debug mode does while running it in the compiler sswift, but what I wondered is what good it did in a compiled .exe file that therefore wouldn't have access to the debugger. There must be some point in compiling debug versions of an app, but all the stuff I've seen from these posts either A) only applies when running the program directly from the compiler or B) is stuff you could do in a non-debug version of a .exe anyway. I still haven't seen anything that a debug version of a compiled .exe running on a system that doesn't have Blitz installed will do for you. Hotcakes - I have the latest version of BlitzPlus installed, but if I ever run my game with a compiled .exe or with debug mode turned off while running from the compiler, it just boots to the desktop any time it tries to access an image frame that doesn't exist. So if I load an animated image with LoadAnimImage that has 15 frames and try to access frame 16, it will boot out. It's done this since I first got it for any project I've made. All my projects so far have been in full screen graphics mode, not in a windowed mode, could that be the difference? It also just boots to the desktop if I try to access a type that's been deleted. So if I have a type variable like Enemy.EnemyType = Each EnemyType and then use Delete Enemy and then try to access something like Enemy\x in the same loop, it will boot to desktop unless I am running it within the compiler and with debug mode enabled. |
| ||
| As far as I know, compiling with debug on doesn't do anyhting for you. |
   |