Re: Breakpoint stopping code, But I removed it!
At 06:44 PM 8/3/2003, Randall Pulsifer wrote: Anyone have any tips on how to remove a breakpoint that just won't quit? I'm using CW9 on Win2k with Sony's OS5 Simulator (NZ90). I had placed the BP and used it to debug as usual, then tapped the little red dot to get rid of it - the dot went away, but the [EMAIL PROTECTED]' debugger stops in the same place anyway! I removed object code, recompiled, hit "Clear All Breakpoints" from the menu, deleted the line that it stops on (that stopped it until I put the line back in), checked for accidental EventPoints, rebooted, moved lines of code around that didn't mind - but the breakpoint continues to follow this subtraction operation. I could just F5 it, but the line in question is in my DmComparF routine which gets called 179 times each time a sort occurs. Only odd thing - it doesn't stop with the solid blue arrow, but with the dotted blue arrow, that might indicate waiting for user input if you were single stepping. Any Ideas??? Did you save the simulator state and restore it while your program was loaded? It sounds like the program is loaded at a different location in memory than the debugger expects, so its not seeing a breakpoint there, but the instructions are still modified in memory to set the breakpoint. Try deleting the pSYM file for your project, and also start from a totally clean simulator session. -- Ben Combee <[EMAIL PROTECTED]> CodeWarrior for Palm OS technical lead Palm OS programming help @ www.palmoswerks.com -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Breakpoint stopping code, But I removed it!
> -Original Message- > Subject: Re: Breakpoint stopping code, But I removed it! > > At 06:44 PM 8/3/2003, Randall Pulsifer wrote: > >Anyone have any tips on how to remove a breakpoint that just won't > quit? > > > >Only odd thing - it doesn't stop with the solid blue arrow, but with > the > >dotted blue arrow, that might indicate waiting for user input if you > >were single stepping. > > > >Any Ideas??? > > Did you save the simulator state and restore it while your program was > loaded? It sounds like the program is loaded at a different location in > memory than the debugger expects, so its not seeing a breakpoint there, > but > the instructions are still modified in memory to set the breakpoint. > > Try deleting the pSYM file for your project, and also start from a > totally > clean simulator session. > I fixed the problem - it's not the IDE, it was just coincidence that the line that I had the breakpoint on (the diffC =...) did not cause an error when you stopped on it, then continued, but failed miserably when run at "full speed". The difference lies in the treatment of pointers. As far as I knew this should work (tho I can't recall ever doing it quite this way before): Int16 * NumberTimes1Ptr, * NumberTimes2ptr NumberTimes1Ptr = (Int16 *) ((UInt32)rec1 + FishStr1Len + 1); NumberTimes2Ptr = (Int16 *) ((UInt32)rec2 + FishStr2Len + 1); diffC = *NumberTimes1Ptr - *NumberTimes2Ptr; It doesn't, at least not with CW9. The following code DOES work: Int16 NumberTimes1, NumberTimes2 NumberTimes1Ptr = (UInt8 *) ((UInt32)rec1 + FishStr1Len + 1); NumberTimes2Ptr = (UInt8 *) ((UInt32)rec2 + FishStr2Len + 1); MemMove(&NumberTimes1,NumberTimes1Ptr,2); MemMove(&NumberTimes2,NumberTimes2Ptr,2); diffC = NumberTimes1 - NumberTimes2; Would anyone like to venture a guess as to what the difference is? BTW, recx is a packed database record which starts with a string (hence the +1 to get by the null char) followed by a Int16 which is what I'm trying to subtract. So, in the first instance, even though no variables are ever declared, the calculated pointers do indeed point into a allocated and locked record. Or so I thought. As I look at it, I bet that, in the first instance: NumberTimes1 = *NumberTimes1Ptr; NumberTimes1 = *NumberTimes1Ptr; diffC = NumberTimes1 - NumberTimes2; WOULD work. What do you think? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Breakpoint stopping code, But I removed it!
I fixed the problem - it's not the IDE, it was just coincidence that the line that I had the breakpoint on (the diffC =...) did not cause an error when you stopped on it, then continued, but failed miserably when run at "full speed". The difference lies in the treatment of pointers. As far as I knew this should work (tho I can't recall ever doing it quite this way before): Int16 * NumberTimes1Ptr, * NumberTimes2ptr NumberTimes1Ptr = (Int16 *) ((UInt32)rec1 + FishStr1Len + 1); NumberTimes2Ptr = (Int16 *) ((UInt32)rec2 + FishStr2Len + 1); diffC = *NumberTimes1Ptr - *NumberTimes2Ptr; If this code, the computation of diffC would fail if either NumberTimes1Ptr or NumberTimes2Ptr were misaligned (on an odd address). Any 16-bit or 32-bit memory access on the 68K must be on an even memory boundary. It doesn't, at least not with CW9. The following code DOES work: Int16 NumberTimes1, NumberTimes2 NumberTimes1Ptr = (UInt8 *) ((UInt32)rec1 + FishStr1Len + 1); NumberTimes2Ptr = (UInt8 *) ((UInt32)rec2 + FishStr2Len + 1); MemMove(&NumberTimes1,NumberTimes1Ptr,2); MemMove(&NumberTimes2,NumberTimes2Ptr,2); diffC = NumberTimes1 - NumberTimes2; This works because you use MemMove to copy the values into aligned memory first. -- Ben Combee <[EMAIL PROTECTED]> CodeWarrior for Palm OS technical lead Palm OS programming help @ www.palmoswerks.com -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
