[Bug 28271] League of Legends installer crashes on startup

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Oct 28 03:51:18 CDT 2011


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

Dmitry Timoshkov <dmitry at baikal.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net

--- Comment #4 from Dmitry Timoshkov <dmitry at 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 at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list