PocketMatrix

What processor are you testing on? First thing I would try is to increase the stack size in the link settings. If you're using pointers to vars whose size is greater than a byte, then watch your alignment. John Carmack did quite a bit of this type of thing in Wolfenstein 3D:<br>[fixed]<br>unsigned char *c=something;<br>while (going) {<br>  *( ( int * ) c )=someNumber;<br>  c++;<br>}<br>[/fixed]<br>So in that contrived example, you see that the pointer c is being cast to a 4 byte integer, but c is incremented a byte at a time. The x86 family doesn't mind that at all, even if it starts at an odd address. However, StrongARM and SH3 require even alignment, and MIPS goes even further requiring 4 byte alignment.<br><br>Dan East

If it weren't for remote debugging I would have lost my mind long ago. It actually works pretty well. The only real catch if you plan on doing any real amount of CE development is that you need the fastest possible connection to the device. USB really sucks for CE connectivity. It can take around a minute to begin a debug session, and close to 30 seconds to step a single line. Of course standard serial is even worse. However, with ethernet or 802.11b wireless it is virtually instantaneous.<br><br>Dan East

I'm trying to think of all the times I've seen bizaare errors like your seeing (where the problem goes away when diagnostic routines are inserted).<br>Make sure you aren't overwriting an array somewhere. That can cause similar results. When you insert in other function calls, such as printf, you pad the stack with other vars, which when overwritten don't necessarily cause a critical error.<br><br>Dan East

Get remote debugging working first.  I can't imagine anyone trying to do software development without being able to properly debug code.<br>

Thanks Dan,<br>Not even close to a solution yet, but the whole program leans on a pointer based multidimensional sparse array, so yes, it's very likely something DOES get overwritten....just wished MSVC wouldn't crash me while I try to debug it, or my pocketPC debug setup did actually work. Somehow I'm doing something wrong there, because I can't get it to single-step, it crashes before the first line of code it seems...hard to tell when all I get in my stack trace is addresses and no line-info, suggesting it crashed in a DLL. Whatever. Maybe I should invest in more than a serial cable.., because it's very bad for my smoking addiction..crappy thing is I'm out of the country for a few months and don't think my laptop is upto any more beefing up<br>But, just wanted to say thanks, you've been more than helpful )<br><br>Kaj )<br>

Ha!<br>If I could get remote debugging to work this project would have been finished a month ago.<br>Any pointer on what I could be overlooking? (ARM setting). It asks for a missing DLL which I then locally point to....it runs for a bit (after a few cigarettes of course...serial cable)...and collapses with an error at address 0x00005....that sounds like approx the second instruction to me, or a return with a badly corrupt stack.<br>Sounds familiar to someone?<br><br>Kaj \

Digby:you can't? ohh well, you have seen me, haven't you?:) I do all the debugging on PC and it works without problems as for now on PPC, which makes me very happy. (ok, got some problems with file names, but my error.log file was enought to solve it:)

When you debug your app on your device, and it crashes, does eVC++ take you to the line the error occurs? If that line is not in your app (or points to some dissassembled machine code), then pull up the Call Stack. I can't remember if the call stack window is shown by default in a debug session or not. Follow the stack down until you see the a source file that is part of your app. Double click on it, and it should show the function you called in your app that eventually cased the exception.<br><br>Dan East

Mirek,<br><br>Maybe there are people who mow their lawns with scissors too.  I guess I shouldn't be surprised.  <br><br>Now I'm really curious as to why you don't use remote debugging.  Do you have some aversion to using remote debugging? Do you have trouble setting it up like Kaj?  Or maybe your code needs to run on the PC as well as the Pocket PC, so you make sure it runs on the PC first?<br><br><br><br>

Dan...<br>That's what scares me, I compile with debug info on, yet it crashes before it gets to my code it seems, I only see a call stack of two deep, and both point to disassembly....now...yikes...better check if I didn't point to the wrong local DLL....hrmmmm....but even then, it should pass SOME of my code I'd say....ah well, it's still an early sunday )<br><br>Kaj

It happens often that when an exception occurs the call stack is not available. I don't exactly know what causes this, but you will get an invalid address for the caller function. So you need to set a breakpoint at the very beginning of your app, then step through until it crashes, gradually narrowing in on the exact place.<br><br>Dan East

Kaj,<br><br>Is your code in a DLL?  There is a problem with the eVC debugger in that it won't allow you to hit breakpoints in your DllMain.  Since the OS is going to try to load your DLL at application load time, your code could be executed before WinMain.<br><br>There are limits to what you can do inside of DllMain.  While the restrictions are the same for CE as the are for the Desktop OSes, if you break those limits your code might actually run on the Desktop rather than CE.  CE is much more strict in this regard.<br><br>Anyway, if you aren't using non-system DLLs then ignore all of this as the problem is probably somewhere else.<br><br>If you are linked to your own DLL, or someone other 3rd-party DLL, try creating a simple app that calls LoadLibrary to load the DLL inside WinMain.  If the app crashed making the LoadLibrary call, the chances are pretty good that it's something in the DLL's DllMain that is at fault.<br><br>Have fun.<br><br>