1. RE: win32libs
Wolf wrote:
> I've got two demo's in this zip.
> One, written for win32lib version 0.55.1, GPF's frequently, on
> *closing*.
> The other, re-written for version 0.51, *never* seems to do this....
> ..darn !!!
> Tests, and feedback, appreciated.
Wolf,
I thought I'd try to help you out but when I ran the program it was
looking for a smile.bmp? Couldn't get past it, sorry. :(
Jonas
2. RE: win32libs
> -----Original Message-----
> From: Wolf [mailto:wolfritz at KING.IGS.NET]
>
> I've got two demo's in this zip.
> One, written for win32lib version 0.55.1, GPF's frequently,
> on *closing*.
> The other, re-written for version 0.51, *never* seems to do this....
> ..darn !!!
> Tests, and feedback, appreciated.
I used another bitmap, and it worked fine, unless I moved/resized the window
several times. Then I got the GPF. I tracked it down to tk_mem.e. It was
real easy to find using the translator:
tk_mem.e:116 VOID = c_func(xHeapFree,{ pHeap, 0, pAddress})
Rob, how about adding a trace feature like this to the interpreter? Maybe
trace(2) could direct all trace output to ctrace.out or something. Ex.err
works fine for normal Eu errors, but tracking down GPF's, especially in
win32lib, can be very difficult.
I'm not terribly familiar with tk_mem's guts, so I think I'll ask Derek to
take a look. I can't figure out why this would happen.
Using this technique, I located the point at which I've had GPF trouble
(once again, on closing).
I tracked it down to SubProc. The crash happens when a TabControl gets a
WM_NOTIFY with an LVN_DELETEALLITEMS notification. This happens when the
app is closed, and when there is a ListView with a TabControl as parent. I
added this code to SubProc right above the call to xCallWindowProc:
if window_type[id] = TabControl and iMsg = WM_NOTIFY then
VOID = fetch( lParam, NMHDR_code )
if VOID = LVN_DELETEALLITEMS then
return popSelf()
end if
end if
For some reason, the tab control can't handle this message, but this
prevents a GPF.
Matt Lewis
3. RE: win32libs
> -----Original Message-----
> From: Wolf [mailto:wolfritz at KING.IGS.NET]
> I've got two demo's in this zip.
> One, written for win32lib version 0.55.1, GPF's frequently,
> on *closing*.
> The other, re-written for version 0.51, *never* seems to do this....
> ..darn !!!
> Tests, and feedback, appreciated.
OK, I still can't explain _why_ the crash happens, but I think I know how to
avoid it. At least, I can't duplicate the GPF anymore. I checked the win32
docs, and HeapDestroy will free anything that was allocated before getting
rid of itself. So instead of freeing memory blocks one at a time, I
switched to using HeapDestroy for releasing all memory. In addition to
being (seemingly) more stable, it should be a lot faster (not that I've
heard anyone clamoring for speedy shutdowns):
--tk_mem.e
global procedure release_all_mem()
atom VOID
-- Matt Lewis 3/14/01
-- changed this to avoid GPF on close
if pHeap then
VOID = c_func(xHeapDestroy,{ pHeap })
-- reinitialize variables
pAllocated = { {}, {} }
pHeap = 0
pAllocationCounter = 0
pAllotted = 0
pStringSet = 0
end if
end procedure
Wolf, see if that solves your problem. If so, we ought to update tk_mem,
Derek.
Matt Lewis
4. RE: win32libs
Good one Matt.
I've been working on trying to fix it rather than work around, but heh! what
ever works right?
In my testing I'm now doing a check to see if the process owns the memory
block before freeing it. I suspect that because win32lib is not reenterent
that somehow some threads are trying to release memory twice, or access
memory that has been released.
Thanks for for this fix.
> -----Original Message-----
> From: Matthew Lewis [mailto:matthewwalkerlewis at YAHOO.COM]
> Sent: Thursday, 15 March 2001 11:31 AM
> To: EUforum
> Subject: RE: win32libs
>
>
>
>
>
> > -----Original Message-----
> > From: Wolf [mailto:wolfritz at KING.IGS.NET]
>
> > I've got two demo's in this zip.
> > One, written for win32lib version 0.55.1, GPF's frequently,
> > on *closing*.
> > The other, re-written for version 0.51, *never* seems to do this....
> > ..darn !!!
> > Tests, and feedback, appreciated.
>
> OK, I still can't explain _why_ the crash happens, but I think I
> know how to
> avoid it. At least, I can't duplicate the GPF anymore. I
> checked the win32
> docs, and HeapDestroy will free anything that was allocated before getting
> rid of itself. So instead of freeing memory blocks one at a time, I
> switched to using HeapDestroy for releasing all memory. In addition to
> being (seemingly) more stable, it should be a lot faster (not that I've
> heard anyone clamoring for speedy shutdowns):
>
> --tk_mem.e
>
> global procedure release_all_mem()
> atom VOID
>
> -- Matt Lewis 3/14/01
> -- changed this to avoid GPF on close
> if pHeap then
>
> VOID = c_func(xHeapDestroy,{ pHeap })
>
> -- reinitialize variables
> pAllocated = { {}, {} }
> pHeap = 0
> pAllocationCounter = 0
> pAllotted = 0
> pStringSet = 0
> end if
>
> end procedure
>
> Wolf, see if that solves your problem. If so, we ought to update tk_mem,
> Derek.
>
> Matt Lewis
>
>
>
>
>
