http://bugs.winehq.org/show_bug.cgi?id=28271
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru 2011-10-28 03:51:18 CDT --- I think the problem is related to how the sections of swt-win32-3349.dll (extracted into the user's temp directory) get mapped into memory. swt-win32-3349.dll is packed with UPX, so I first suspected its extraction mechanism to fail map the sections same way as it's done under Windows, but investigating UPX sources and playing with unpacked DLL shows the same behaviour.
First of all i did all my investigations with the following commit reverted, since the tests show that it's clearly wrong:
commit 33b0f0edffa0c8a06b4ee8831c92fdc373f83ece Author: Alexandre Julliard julliard@winehq.org Date: Fri Sep 9 12:29:20 2011 +0200
ntdll: Fix protection flags for uninitialized sections.
Here are the results of my investigation with unpacked swt-win32-3349.dll and a test app which does LoadLibraryEx with various flags and then dumps the resulting virtual memory of the loaded PE image. Loading the DLL under XP with DONT_RESOLVE_DLL_REFERENCES or LOAD_LIBRARY_AS_DATAFILE flags result in the same view, and matches the result under Wine with any flags used:
wine: ======== Loading swt-win32-unpacked.dll... loaded at 10000000 base 10000000, alloc base 10000000, prot 0002, alloc prot 0080, size 00001000, state 1000, type 1000000 base 10001000, alloc base 10000000, prot 0020, alloc prot 0080, size 00029000, state 1000, type 1000000 base 1002A000, alloc base 10000000, prot 0002, alloc prot 0080, size 00018000, state 1000, type 1000000 base 10042000, alloc base 10000000, prot 0008, alloc prot 0080, size 00007000, state 1000, type 1000000 base 10049000, alloc base 10000000, prot 0002, alloc prot 0080, size 00006000, state 1000, type 1000000
xp: ======== Loading swt-win32-unpacked.dll... loaded at 10000000 base 10000000, alloc base 10000000, prot 0002, alloc prot 0080, size 00001000, state 1000, type 1000000 base 10001000, alloc base 10000000, prot 0020, alloc prot 0080, size 00029000, state 1000, type 1000000 base 1002A000, alloc base 10000000, prot 0002, alloc prot 0080, size 00018000, state 1000, type 1000000 base 10042000, alloc base 10000000, prot 0008, alloc prot 0080, size 00002000, state 1000, type 1000000 base 10044000, alloc base 10000000, prot 0004, alloc prot 0080, size 00001000, state 1000, type 1000000 base 10045000, alloc base 10000000, prot 0008, alloc prot 0080, size 00001000, state 1000, type 1000000 base 10046000, alloc base 10000000, prot 0004, alloc prot 0080, size 00003000, state 1000, type 1000000 base 10049000, alloc base 10000000, prot 0002, alloc prot 0080, size 00006000, state 1000, type 1000000
The differences start from address 10042000. There are 2 regions with PAGE_READWRITE access (0x0004) injected into PAGE_WRITECOPY (0x0008) region.
Here is what winedump tells about the interesting section:
.data VirtSize: 0x00006380 VirtAddr: 0x00042000 raw data offs: 0x00042000 raw data size: 0x00003000 relocation offs: 0x00000000 relocations: 0x00000000 line # offs: 0 line #'s: 0 characteristics: 0xc0000040 INITIALIZED_DATA MEM_READ MEM_WRITE
The tests show that INITIALIZED_DATA | MEM_READ | MEM_WRITE section is supposed to be have PAGE_WRITECOPY access. With 33b0f0edffa0c8a06b4ee8831c92fdc373f83ece reverted Wine behaviour matches what Windows does. To test whether it's the loader who does something wrong I patched the DLL entry point to either return 1 or simply zero out the entry in the PE header. Both of them result in DLL having same virtual memory map like it was loaded as a data file or without deps. So, it looks like the DLL entry does something in the attach handler? Tracing it under Wine shows nothing interesting. Fortunately there the sources available of the swt.win32.extenstion project, but there are nothing enteresting there either, and the DLL binary distributed by the project differs from our win32-swt one. The offending section contents dumped by winedump look like some delay load data, with imported DLL names and APIs. Perhaps the section access gets changed once delay loaded APIs get resolved, but I'm not sure who is responsible for that: is it the OS loader, injected linker code, or custom application code?
I dare to add AF to the cc: list, perhaps if he has some interest and free time he could shed some light on this.