A possible memory heap problem

gerard patel g.patel at wanadoo.fr.invalid
Mon Aug 27 02:50:15 CDT 2001

On Sun, 26 Aug 2001 18:44:06 -0700, Duane Clark
<junkmail at junkmail.com> wrote:

>Okay, here is a bit around that area. I don't see any "region" messages 
>in the area.

Bad guess :-/

>By the way, what has happened at this point is that the 
>window has come up, the menus have been painted along with a status area 
>at the bottom of the content area. But the rest of the main window 
>content area is not painted.
>At this point, a fixed amount of the err messages are spit out. If I 
>obscure part of the window and and then bring at to the front again, a 
>steady rapid stream of error messages are generated until the 
>application is killed.
>trace:gdi:GetStockObject returning   ae

Argh, the line where this function is *called* should say
what is the type of the object :-/

>trace:gdi:GDI_GetObjPtr (0910): enter 2
>08066df8:Call x11drv.GetDeviceCaps(403982d0,0000005a) ret=40743de5
>08066df8:Ret  x11drv.GetDeviceCaps() retval=00000060 ret=40743de5
>trace:gdi:GDI_ReleaseObj (0910): leave 2
>08066df8:Ret  x11drv.SelectObject() retval=00001012 ret=4074de74
>trace:gdi:GDI_ReleaseObj (0910): leave 1
>trace:local:LOCAL_InternalLock 1032 returning 1206
>trace:gdi:GDI_GetObjPtr (1032): enter 1
>trace:local:LOCAL_Unlock 1032
>trace:gdi:GDI_ReleaseObj (1032): leave 1
>trace:local:LOCAL_InternalLock 1012 returning 10e2
>trace:gdi:GDI_GetObjPtr (1012): enter 1
>trace:local:LOCAL_Unlock 1012
>trace:gdi:GDI_ReleaseObj (1012): leave 1
>trace:gdi:dec_ref_count executing delayed DeleteObject for 1012

Here is the problem. 

If you don't know how is working SelectObject, here is
the scoop : there is only one kind of a given object 
type selected in a device context at a time. When you
select an object in a DC, the current object of this
type is returned. 

What is happening here is that Wine deletes automatically
the *replaced* object because its reference count is 0 (this
is incorrect : 1012 is selected, its reference count should
be 1 at least)

>trace:local:LOCAL_InternalLock 1012 returning 10e2
>trace:gdi:GDI_GetObjPtr (1012): enter 1
>trace:gdi:DeleteObject 1012
>trace:local:LOCAL_Unlock 1012
>trace:local:LOCAL_Free 1012 ds=01ef
>trace:local:LOCAL_Free real block at 10e2
>trace:local:LOCAL_FreeArena 10dc ds=01ef
>trace:local:LOCAL_GetHeap Heap at 0x4035a500, 0020
>trace:local:LOCAL_MakeBlockFree 10dc, next 119c
>trace:local:LOCAL_GetHeap Heap at 0x4035a500, 0020
>trace:gdi:GDI_FreeObject (1012): leave 1
>08066df8:Ret  gdi32.SelectObject() retval=00001012 ret=004451ad
>08066df8:Call gdi32.DeleteObject(00001012) ret=004451ce

Here you see that 1012 was probably an object created by the app.
Theoretically the scheme is as follow :
- create object
- select it in a DC
- save the returned value (it is usually the default object)
- use the DC
- select the previous value
- delete the created object

I think that is what the app is trying to do (unless it is
horribly bugged, of course - but my guess is that Wine
is horribly bugged :-))

>trace:local:LOCAL_InternalLock 1012 returning 0000
>trace:gdi:GDI_GetObjPtr (1012): enter 1
>trace:gdi:DeleteObject delayed for 1012 because object in use, count 2097152
>trace:local:LOCAL_Unlock 1012
>trace:gdi:GDI_ReleaseObj (1012): leave 1
>08066df8:Ret  gdi32.DeleteObject() retval=00000001 ret=004451ce
>My real email is akamail.com at dclark (or something like that).

I think you have *my* real email from the mailing list, no ?
In this case you can send me a full trace with +gdi,+relay.
I can now get mails up to 50 MB, but compress it please.


More information about the wine-users mailing list