Clang doesn't like ZeroMemory, causes crash in Wine

[llvmbot]

Bugzilla Link	9830
Resolution	INVALID
Resolved on	Dec 17, 2012 16:52
Version	trunk
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#10638
Attachments	preprocessed clang file, preprocessed gcc file
Reporter	LLVM Bugzilla Contributor

Extended Description

See: http://bugs.winehq.org/show_bug.cgi?id=26754

likely a regression, though haven't retested with an older Clang yet. Compiling Wine with clang from trunk (clang version 3.0 (trunk 130453)), and running wine's builtin 'regedit' program causes a crash. The crash can be avoided by not using ZeroMemory, or compiling the particular file with gcc instead of clang.

Occurs with/without integrated assembler.

clang -E -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -std=gnu89 -g -O0 -o imagelist.i imagelist.c

preprocessed .i file attached (for Clang and gcc).attached

[llvmbot]

ZeroMemory is a macro which is why I can't find any reference to it in the .i file. Instead, ZeroMemory(x, y) expands to "memset(x,0,y)", which occurs two places in that file.

You said it can be avoided by not using ZeroMemory. Do you need to remove all uses of ZeroMemory? Does it always crash the first the time ZeroMemory-using the function is called, or does it work successfully sometimes?

[llvmbot]

ZeroMemory is a macro which is why I can't find any reference to it in the .i
file. Instead, ZeroMemory(x, y) expands to "memset(x,0,y)", which occurs two
places in that file.

You said it can be avoided by not using ZeroMemory. Do you need to remove all
uses of ZeroMemory? Does it always crash the first the time ZeroMemory-using
the function is called, or does it work successfully sometimes?

There are two uses of ZeroMemory in the original file (lines 906 and 1140). The problem is the second use. Removing the first makes no difference. I've never had it successfully work when the second ZeroMemory is left in.

[llvmbot]

Where does it actually crash? At the memset? Somewhere in ImageList_DrawIndirect? In the caller?

[llvmbot]

Where does it actually crash? At the memset? Somewhere in
ImageList_DrawIndirect? In the caller?

Backtrace is at http://bugs2.winehq.org/attachment.cgi?id=34075 (I'll attach in a sec).

Crashes at the memset:
Backtrace:
=>0 0x7e69f427 ImageList_DrawEx+0x87(himl=0x12f700, i=0x2, hdc=0x2e0, x=0x13, y=0xffffffff, dx=0, dy=0, rgbBk=0xff000000, rgbFg=0xff000000, fStyle=0) [/home/austin/src/wine-clang/dlls/comctl32/imagelist.c:1140] in comctl32 (0x0033f3b0)
1 0x7e69f387 ImageList_Draw+0x86(himl=0x12f700, i=0x2, hdc=0x2e0, x=0x13, y=0xffffffff, fStyle=0) [/home/austin/src/wine-clang/dlls/comctl32/imagelist.c:1100] in comctl32 (0x0033f410)
2 0x7e74148c TREEVIEW_DrawItem+0x59b(infoPtr=0x12dcf0, hdc=0x2e0, wineItem=0x1300d0) [/home/austin/src/wine-clang/dlls/comctl32/treeview.c:2608] in comctl32 (0x0033f5c0)
3 0x7e740cbb TREEVIEW_Refresh+0x19a(infoPtr=0x12dcf0, hdc=0x2e0, rc=0x33f6a8) [/home/austin/src/wine-clang/dlls/comctl32/treeview.c:2892] in comctl32 (0x0033f660)
...
0x7e69f427 ImageList_DrawEx+0x87 [/home/austin/src/wine-clang/dlls/comctl32/imagelist.c:1140] in comctl32:
1140 ZeroMemory (&imldp, sizeof(imldp));

[llvmbot]

wine backtrace

[llvmbot]

This appears to be a stack alignment issue, since adding force_align_arg_pointer fixes it. I don't know what you guys want to do at this point, so I'll leave this bug open for now.

[llvmbot]

It also doesn't crash with optimizers active (though the test fails), in either trunk or 2.9.

[llvmbot]

Still present, as of
git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@150433 91177308-0d34-0410-b5e6-96231b3b80d8

and wine-1.4-rc3-23-gd548af4. Using the following Wine patch works around it:
diff --git a/include/windef.h b/include/windef.h
index 9cf98e7..bc2d82e 100644
--- a/include/windef.h
+++ b/include/windef.h
@@ -53,11 +53,7 @@ extern "C" {
#ifndef __stdcall

ifdef i386

ifdef GNUC

-# ifdef APPLE /* Mac OS X uses a 16-byte aligned stack and not a 4-byte one */

define __stdcall attribute((stdcall)) attribute((force_align_arg_pointer))

-# else
-# define __stdcall attribute((stdcall))
-# endif

elif defined(_MSC_VER)

 /* Nothing needs to be done. __stdcall already exists */

else

[llvmbot]

Fixed in wine by http://source.winehq.org/git/wine.git/commitdiff/4adfb787f4e8c36a37ce1d53a7e6df16d03ecd8a