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.
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.
Hal Mueller schrieb:
> At 12:26 PM -0700 6/10/02, Hal Mueller wrote:
> >What happens if you insert a few calls to MemPtrNew just before your
> >crash point? I bet you'll see that you're out of memory.
>
> Oops, of course that won't cause a failure, because those allocations
> won't come from the stack! Stupid of me.
>
> Hmm, how about a locally-declared array, and vary the number of
> elements to cause a crash?
>
> H
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
