Coalescing of page allocator spans across Win32 VirtualAlloc regions causes GDI errors

[GoogleCodeExporter]

TCMalloc version 1.1 on Win32.  Visual Studio 2008 SP1 (VC9.0.30729.1) and 
Visual Studio 2003 (VC7.1.3088)

When using tcmalloc for allocation of the storage area of a Win32 GDI DIB, 
the resulting bitmap occasionally causes GDI operations to fail.  It 
appears that this occurs when the bitmap memory area spans multiple regions 
allocated using VirtualAlloc().

See this message for a more detailed description:

http://groups.google.com/group/google-perftools/msg/6d56b75640984bbb

In short, it appears that the normally beneficial step of coalescing page 
allocator spans is undesirable in this case.

Briefly:

Set up a BITMAPINFO structure that describes the bitmap.  Allocate space 
for the bitmap and pass the pair to StretchDIBits.  With a 200x100 bitmap 
this fails approximately every 17th time, about the number of 60,000-byte 
allocations that fit in a 1MB block.

Repeat 500 times.  StretchDIBits should succeed 500 times, but instead it 
fails 27 times:

111111111111111111111111111111111011111111111111110111111111111111101111111
111111111011111111111111110111111111111111101111...

See the example code in the attachment for a concrete example.

Original issue reported on code.google.com by Codeben...@gmail.com on 5 Apr 2009 at 8:57

Attachments:

• tcmalloc-Win32GDITest.zip

[GoogleCodeExporter]

Forgot to mention that this behavior was observed on WinXP SP2 and Windows 2003 
Enterprise Server SP2.

Original comment by Codeben...@gmail.com on 6 Apr 2009 at 12:15

[GoogleCodeExporter]

I've reproduced the problem locally.  I've asked folks around here to brainstorm
about the best possible fix.  Thanks again for the great bug report!

Original comment by csilv...@gmail.com on 6 Apr 2009 at 9:27

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Just to let you know, I haven't forgotten about this, though it was too 
difficult to
attempt a fix for the perftools 1.2 release.  I hope we'll have something for 
the 1.3
release.  I'm still hoping to come up with an idea that will let us solve this
without introducing much complexity or code overhead...

Original comment by csilv...@gmail.com on 18 Apr 2009 at 12:17

[GoogleCodeExporter]

In a QT-based GUI-application I noticed that when opening menus, there flashes a
black or random-dottet square on the screen for some fractions of a second and 
then
the correct menu is displayed at this position. Is this the same issue?

Original comment by weidenri...@gmx.de on 2 Jun 2009 at 8:45

[GoogleCodeExporter]

It may be, but without more specific information I can't say.  I'm not actively 
using 
QT at the moment, but if you can provide a simple demo of the problem under Qt 
4.x, I 
can look at it.

You could also use one of the Win32 "API Spy" applications to check for error 
returns 
from GDI functions.  Feel free to contact me if you would like more details.

Original comment by Codeben...@gmail.com on 2 Jun 2009 at 3:22

[GoogleCodeExporter]

I've talked with folks who have a lot more experience with patching windows 
memory-allocation calls than I do, and they say that this kind of problem is 
endemic -- you're never going to find (or fix) them all.  The recommendation I 
got was to do libc patching instead (as described in README_windowx.txt), which 
avoids all these troubles.

So I'm going to close this WillNotFix, with a suggestion to try the libc 
patching instead if this -- or any of a myriad other potential problem-cases 
with more complex setups -- occurs.

Original comment by csilv...@gmail.com on 31 Aug 2011 at 10:07

• Changed state: WontFix