Luc Le Blanc wrote:
During a lengthy drawing operation, I allow the user to abort this
drawing tapping on the screen. I detect this action with an occasional
check to EvtSysEventAvail( true ). When I detect this, I ask user
confirmation with a FrmAlert. Alas, POSE reports 2 memory leaks under OS
3.5 or 4.1. The log indicates this twice (40 and 682 bytes):
29889.839: Relocatable chunk leaked at 0x000061A6, size = 40
29889.839: Chunk allocated by:
29889.839: WinCreateBitmapWindow
29889.839: WinCreateOffscreenWindow
29889.839: WinSaveBits
29889.839: <Unknown @ 0x000652E2>
29889.839: <Unknown @ 0x000660BA>
29889.839: PrvSendEventToForm
29889.839: PrvRedrawDisplay
29889.839: FrmEraseForm
29889.839: FrmDoDialog
29889.839: FrmCustomAlert
29889.839: FrmAlert
29889.839: <Unknown @ 0x00060D36>
29889.839: <Unknown @ 0x0006504E>
29889.839: <Unknown @ 0x000660BA>
29889.839: PrvSendEventToForm
Is FrmAlert realy causing these memory leaks? How can I avoid this?
Just a stab in the dark, but when the alert closes, it's going to
cause your form to redraw, which means you're going to get a
frmUpdateEvent. I wonder if perhaps your code is getting nested
frmUpdateEvents and is unable to handle one while it's already
in the process of drawing. Do you call WinSaveBits() anywhere
in your own form-drawing code?
As I said, just an idea, but it seems possible that PrvSendEventToForm()
is being called after they dismiss the alert, and it's sending an
update event to your form event handler, which shows up as one of the
unknown symboles (between PrvSendEventToForm() and WinSaveBits()).
Which reminds me: have you tried running this same thing with a debug
build? If those functions are your own, that should give you the
missing symbols in the stack backtrace.
- Logan
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
