How to trace code when running?
BlitzMax Forums/BlitzMax Beginners Area/How to trace code when running?
| ||
| I'm working on my first BlitzMax game, which is a simple 2-D shoot-em up. Right now I'm running into a bug and I can't figure out the cause. Is there a way I can follow the code line-by-line while the game is running? If there is, then I think I can find the line of code which is causing the problem. Thanks. Bill |
| ||
| debugstop() |
| ||
| Yah just stick a DebugStop() call where you think you'd like to start tracing, the debugger will kick in and put you in the IDE, then you can use the `step` and `step in` and `step out` buttons in the IDE to go through the source line by line. stepping in seems to mean going inside of functions that you're calling (otherwise it runs them in full and comes back), and step out does sort of the opposite - stopping at the next debugstop. |
| ||
| Along with debugstop, you can use debuglog which will output to the console... |
| ||
| Thank you for the tips. |
| ||
| debugstop doesnt do anything...... It doesnt start the tracing, doesn't pause execution, etc... |
| ||
| debugstop doesnt do anything...... It doesnt start the tracing, doesn't pause execution, etc... Is your app compiled (and run from the IDE) in Debug mode? |
| ||
| debugstop doesnt do anything...... It doesnt start the tracing, doesn't pause execution, etc... Works here. |
| ||
| Is your app compiled (and run from the IDE) in Debug mode? Meaning that little check next to "Debug Build" under Program->Build Options? Yes.... |
| ||
| You're not using Blide, are you? Blide always had a habit of compiling in release mode after you enable debug mode. You tend to need to disable Quick Build once, and then it will pick things up again. After that you can re-enable quick build and it will still be in debug mode. Not sure if that's been fixed or not, I'm running a very old version. |
| ||
| @Gabriel: That was fixed long ago (BLIde diferenciates debug builds and release builds, as the regular IDE does). If using BLIde and debug mode is ON, once the debugstop is reached, you'll have a stack trace window at the bototm of the debugger panel. You can follow the call stack trace there while debuging step by step. It's very useful! |
| ||
| @Gabriel: That was fixed long ago (BLIde diferenciates debug builds and release builds, as the regular IDE does). I assumed as much, but when Dark Half was discussing another BlitzMax issue recently, I distinctly remember him talking about using a pre-1.30 version of BlitzMax. Hence I thought it was possible he was also using a very old version of Blide. |
| ||
| You're not using Blide, are you? Whatever IDE comes with Blitzmax.... I distinctly remember him talking about using a pre-1.30 version of BlitzMax. Ahh, yeah I wasn't using a pre-1.30, I was toying with the idea to get around linux dependencies at the time. Right now I am coding in WindowsXP with the current version of BM If using BLIde and debug mode is ON, once the debugstop is reached, you'll have a stack trace window at the bototm of the debugger panel. You can follow the call stack trace there while debuging step by step. It's very useful! So the stack tracing is a Blide only thing and not built into Blitzmax? I would think that Blide is ONLY an IDE and doesn't add any functionality to the BMK. I can't, for the life of me, get the debugstop to stop the code (with debug build turned on) and it really annoys me as I need to see why garbage collection isn't picking up and destroying an object... In my past few weeks I've discovered quite a few 'inconsistencies' with Blitzmax that really annoy me. It boils down to keeping my mouth shut regarding them as I'd hate to be hung as a witch again..... But this debugger thing is near the top of the list... |
| ||
| ok, so I found a way for it to work... put it in the main source file, then it works YEAY, but now the tracer/debugger is gone from the IDE BOOOOO and I cant find where to bring it back.... steaming pile...... |
| ||
| Ahhh there it is, it's in the config file for the IDE under:split_orientation=1 (instead of 2) Now that I've wasted a few hours trying to get the [swearing edited by mod] debugger to come up (in a usable way), I can finally debug the code... |
| ||
| Oppps, well, it sort of works (debugstop)... I can only put it in the main include for some reason (for it to stop the app). So I made a global int, and set it to 1 somewhere deep in the source. Then in the main include did a "if then debugstop" on the global int. Now it wont stop anymore..... Double finger bang to Blitzmax! |
| ||
| LOL |
| ||
| I'm so frustrated..... I have a complete TCP/UDP client working in C#. I even have it interfaced into Unity (multithreaded and everything). Blitzmax on the other hand.... Well it doesn't work anything like expected..... DebugStop() doesnt work. Scratch that, it works, but only in the main source file. Any other source files and it wont work (well, I've tested it in methods of an instanced class, and it doesnt stop the code or bring up the debugger). SocketStream will throw an exception when you try to read a byte of 0 from a UDP stream (or a TCP stream). So thats out TSocket.Recv( byte ptr, length ) doesnt actually receive in just the length you pass to it, it disregards the entire rest of the datagram if you take less than whats available. Since Reading a 0-value byte from the socketstream throws an exception you essentially have to create your own stream class and hope to god your getting the whole datagram as you build a stream manually... Secondly where is the documentation for TSocket? Looking at source code just to figure out how to use something is a very annoying and indicates laziness for he who made the product originally. Interestingly enough, a TCP socket will not queue up a whole packet as 'ready' (will happen in chunks, I've even seen a packet of 6 bytes split up) but UDP wont (the datagram, and any behind it, is lost if you dont read the whole 'ready' buffer right then and there). Which is strange because in c# I've noticed that UDP can come in and be pulled off the stack in any way you like where TCP comes in to the stack as a complete packet. Threading is a royal pain. Easy as pie in c# and I understand synchronization but Blitzmax and the whole mutex concept and rules around what you can run in a thread and what you cant is documented nowhere.... Debugging is semi-useless. Globals show up, the function your in shows up, but Class level variables dont (which I prefer to use over app wide globals), nor does any really relevant info (stack info, etc). I have an object that isn't being garbage collected and I cannot figure out where the hell a ref for it is... I went through it 10+ times in code making sure I release all the references to it, but it still isn't being garbage collected.... |
| ||
| DebugStop() should work anywhere. Are you sure you are saving and recompiling the changes to the "any other source files"? In debug mode? Without an example of how your files are arranged, included, imported, etc, we can't really help you figure out why the debugstop() is not being reached, but my guess is that the change that added the debugstop() is not getting compiled into your app. |
| ||
| Any other changes I make to that include file are being compiled. Why wouldn't the debugstop be compiled as well? |
| ||
| Like I said, without an example or being there, I do not how you would expect me to know the answer to that. Maybe your are not actually compiling in debug mode? |
| ||
| Dark Half - can you try not to swear on the forums. (I've edited your offending post above.) |
| ||
| I appologize, I'll keep my language in check in the future. |
| ||
| @TaskMaster: DebugStop will only work if it's placed in some code that is actually run! @Dark Half: Work out roughly where you think the problem is, and then add the DebugStop command to that function/method. |
| ||
| Muttley, i think that is a basic understanding that debugstop will stop when execution hits that line. That is why I asked him if he was sure the code where he put the debugstop was getting compiled into his app, so it could get run. That is also why I told him without examples, there was no way we could help him understand why that code was not being reached. Anyway, probably a good idea that somebody pointed it out. Kinda like when you don't ask somebody "Is it plugged in?" when something isn't working, but after 15 minutes of troubleshooting, you realize it isn't. |
| ||
| Yeah, it's somewhere where it is getting ran, I have a print function right before it, so I know it's hitting the debugstop (or at least the print right before it). But blitzmax doesn't stop..... Oh well, I've been just moving ahead by implementing my own debugger of sorts. I have come to a very astute conclusion that blitzmax is very very far from the final solution. Even for quick development, it seems to have too many short comings to consider it a 'timesaver'. Sure, some may argue the opposite, but if I can get something up and running as expected in C++ or C# (given expected behavior with reference to documented functionality) then it cannot be disqualified as a valid opinion.... Thanks again for putting up with my antics, and for the assistance. |
| ||
| Dark Half, like anything else, it is about understanding. I am sure there is just something you are not understanding, that has slipped past you about the debugstop. Like the code you are trying to debugstop in is not actually running in debug mode, or the section of code is not actually being reached. Without some sort of example, or code snippet that we can see and possibly try ourselves, there is no way we can tell you exactly what the problem is. Or, it is also possible you just have some other issue that may be fixed with a rebuild of your modules or something? |
| ||
| Honestly, I appreciate the help your offering however I have wasted too much time trying to get simple concepts to work to go into it any further. With most things I'd agree with you, it's a matter of understanding. But Blitzmax is more than that, its a matter of having enough time to learn every undocumented quirk BEFORE you try to piece something together you'd expect to work (based solely on theory and understanding). I have ported many of my projects between c++, c#, Java, Delphi and so on (even a few to/from VB, and yet a few others simple enough from php). Having the time to port isn't the issue, finding the needed documentation to get a good handle on a language to come up with a decent design isn't an issue. But finding the time to blindly use trial and error and have to continually come back here to ask for help on something that should be straight forward is a waste of time. Again, I appreciate the help, I really do, but I've fallen too far behind by hoping Blitzmax was more mature than what it really is (in terms of a product, not as a language). |
   |