In article <88674@palm-dev-forum>, [EMAIL PROTECTED] says... > > I observed Register A7, which is the stack pointer. The stack overflow > occurs within an object member function, which does subsequent and > identical calls to other member functions: > > MemSet(&AusRec, sizeof(AusRec), 0); StrCopy(AusRec.rtcText, "SomeText1"); > PositionSetLost(); RecordInsert(); > MemSet(&AusRec, sizeof(AusRec), 0); StrCopy(AusRec.rtcText, "SomeText1"); > PositionSetLost(); RecordInsert(); > MemSet(&AusRec, sizeof(AusRec), 0); StrCopy(AusRec.rtcText, "SomeText1"); > PositionSetLost(); RecordInsert(); > > After call 1 A7 = A7 - 30, after call 2 the same a.s.o.. After each > subfunction call A7 had not retained its value (I thought it should, > because the stack should be restored to its state before the call). The > functions do nothing very special e.g.
If you're using CodeWarrior, make sure that you have A6 stack frames turned on. There is a bug with repeated constructor calls not fixing the stack correctly when this is turned off. Also, you can try adding #pragma stack_cleanup on to the top of your source file. This will make sure the compiler fixes the stack pointer after every function call. This should always be on when building Palm OS apps, but I've seen cases where it seems to have been reset. > void CTable::PositionSetLost() > _Position = DB_NORECSEL; > } > > simply assigns a value to a member variable. After a couple of calls A7 > points to a memory area which is out of stack. -- Ben Combee <[EMAIL PROTECTED]> CodeWarrior for Palm OS technical lead Get help at http://palmoswerks.com/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
