OpenEuphoria

RE: win32libs

• Posted by Derek Parnell <ddparnell at bigpond.com> Mar 14, 2001
• 496 views

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
>
>
>
>
>