At 09:17 AM 9/5/00 +0000, you wrote:
>yet another case of GDI heap overflow:
<snip>
Arranged trace :
Call kernel32.501: LocalAlloc(00000040,00000048) ret=1002caad fs=008f
Ret kernel32.501: LocalAlloc() retval=40381930 ret=1002caad fs=008f
Call gdi32.160: CreatePalette(40381930) ret=100257b3 fs=008f
Ret gdi32.160: CreatePalette() retval=000015ae ret=100257b3 fs=008f
Call kernel32.505: LocalFree(40381930) ret=1002cb1f fs=008f
Ret kernel32.505: LocalFree() retval=00000000 ret=1002cb1f fs=008f
This creates a palette, with a buffer created and freed immediately after.
Call gdi32.139: CreateDCA(1003e1e0 "DISPLAY",00000000,00000000,00000000) ret=10025803
fs=008f
Ret gdi32.139: CreateDCA() retval=000015c6 ret=10025803 fs=008f
Creates a DC
Call gdi32.429: SelectPalette(000015c6,000015ae,00000001) ret=10025825 fs=008f
Ret gdi32.429: SelectPalette() retval=0000ffef ret=10025825 fs=008f
Call gdi32.409: RealizePalette(000015c6) ret=1002582e fs=008f
Ret gdi32.409: RealizePalette() retval=00000010 ret=1002582e fs=008f
SelectPalette and RealizePalette don't create new handles.
Call gdi32.144: CreateDIBitmap(000015c6,4036c6bc,00000000,00000000,00000000,00000000)
Ret gdi32.144: CreateDIBitmap() retval=000015de ret=10025847 fs=008f
Creates a bitmap
Call gdi32.441:
SetDIBits(000015c6,000015de,00000000,00000168,4036c758,4036c6bc,00000000)
Ret gdi32.441: SetDIBits() retval=00000168 ret=10025877 fs=008f
Initialize it
Call kernel32.505: LocalFree(4036c758) ret=1002cb1f fs=008f
Ret kernel32.505: LocalFree() retval=00000000 ret=1002cb1f fs=008f
Frees the buffer used to set the bits of the bitmap
Buffer was allocated before the beginning of your trace.
Call gdi32.429: SelectPalette(000015c6,0000ffef,00000001) ret=10025891 fs=008f
Ret gdi32.429: SelectPalette() retval=000015ae ret=10025891 fs=008f
Restores the default palette of the DC, as said by
Win32 programming guidelines.
When you create a DC,there is a default object selected in it for
each type of object.
You select the object you want (here a palette), when you are
finished with the dc, you select back the previous object (the
ffef handle)
Call gdi32.174: DeleteDC(000015c6) ret=10025898 fs=008f
Ret gdi32.174: DeleteDC() retval=00000001 ret=10025898 fs=008f
Frees the DC
This programs creates 3 objects :
1 bitmap
1 palette
1 dc
It deletes a DC.
SelectPalette and RealizePalette don't create new handles.
This does not mean anything IMO, maybe the program has still some use
for the bitmap and the palette (obviously the goal of this code is to
create some bitmap to be used later).
If at this point the program crashes because of a lack of Gdi resources, the
problem may have been triggered much before. Having a bitmap and a palette
around have never crashed a Windows program (maybe with Windows 1.0?)
A trick I have used to try to catch these problems (I never succeded
in reproducing them) is to change slightly local.c to use Local_PrintHeap
by removing from it the basic trace and keeping only the heap corruption
messages, and call it each time an allocation is done, so the heap is
checked for each call.You can also use Local_GetFreeSpace in a similar
way, to check the resource level with each call.
AFAIK Windows does garbage collection for Gdi objects when the
program terminates :-). What could happen is for Windows to
be more resistant to leakages than Wine. I had a program leaking
directory handles, it was crashing in a few minutes under Wine but
running happily for hours under WinNt - leaking in the same way, but
each directory handle was taking a few hundred bytes under WinNT,
so after this time I had leaked some megabytes of memory, while each
time one Linux file handles was eaten under Wine (1000 per task by
default). You should check under Windows if the program is really
leaking (there are free (beer) tools like memproof)
Another thing to watch for would be for the program deleting a system
color brush or pen; the Corel version is protecting itself against this
slight problem (gdiobj/objects.c), but their trick is not politically
correct :-) So far the only case I have seen of a 'black and white' program
was a nice program deleting a system color brush :-)
Good luck
Gerard
