My company has an application that, among other things, allows
the user to convey an address from its own database to the Palm
address book, for which we use the Exchange Manager.
When this operation is performed under Palm OS 3.5, the Exchange
Manager's progress dialog is activated (a control bit in
ExgSocketType, "noStatus", which can suppress this dialog, has no
effect in Palm OS 3.5), then immediately hidden by the Address
Book's confirmation dialog ("do you want to accept Xxxx into
Address?"). When the user dismisses the confirmation dialog with
a "Yes", the progress dialog is again visible for a moment before
the Exchange Manager closes it. We use the ExgSocketType flag
bit "noGoTo" to avoid actually launching the Address application.
Under a very specific set of circumstances, the
send-to-address-book operation results in data corruption. The
circumstances include:
- Using the application menu (rather than an available button)
to initiate the send.
- Opening the application menu by tapping the application menu
icon, not the form title.
- Doing the whole send twice.
- Following it up by bringing up a Note dialog.
The symptom, which we observe on the Palm Emulator running a
non-debug Palm OS 3.5 ROM, is this error alert from the Emulator:
NearSpace (unknown version) just wrote to memory location
0x........, which is in Memory Manager data structures.
The call stack at the time of the alert looks like this:
__Startup__
PilotMain
StarterPilotMain
normalLaunch [part of our application]
AppEventLoop
PrvSendEventToForm
FrmHandleEvent
FrmEraseForm
WinRestoreBits
WinCopyRectangle
BltCopyRectangle
BltCopyRectangle
PrvCompressedInnerBitBlt
The event being handled here is a frmCloseEvent. It is generated
when our application calls FrmGotoForm(NewNoteView) to launch the
(standard) Note dialog, closing the form from which the
send-to-address operation was initiated. This form has its
"saveBehind" attribute set, like most forms, and I think the
bit-blitting being done at the time of the error is in the
service of restoring that form's saved bitmap. The actual
offending CPU instruction is the one marked here:
10C46D52: 38C0 move.w d0,(a4)+ <----------
10C46D54: 536EFFD8 subq.w #1,-40(a6)
10C46D58: 66E6 bne.s PrvCompressedInnerBitBlt
(0x10c46d40); 0x10c46d40
10C46D5A: 4A6EFFD8 tst.w -40(a6)
An "hd 0" command results in a heap display that starts out
normal, but ends after 28 entries with the message "#ERROR:
Invalid Handle field".
This would probably be a lot easier to diagnose on a debug ROM,
but of course the problem doesn't occur there, because of the
forced suppression of normal save-behind functionality.
We'd be interested in anyone's idea of whether an operating
system bug might be involved, and would welcome any suggestions
for a workaround. Not that we're too worried about real users
performing the requisite weird sequence of operations, but we'd
like Gremlins to run for a while!
Thanks for anyone's input.
Greg Lutz
NearSpace, Inc.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
