[Bug 33127] installer of Thunder 7.9 hangs

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Aug 22 17:52:44 CDT 2015


https://bugs.winehq.org/show_bug.cgi?id=33127

Michael Müller <michael at fds-team.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael at fds-team.de

--- Comment #4 from Michael Müller <michael at fds-team.de> ---
The installer tries to execute the installed Thunder.exe at 93% and freezes
because the started program enters an endless loop.

The root issue is caused by some custom packer in Thunder.exe. The packer tries
to find some suitable address by iterating over the free / allocated memory
blocks using VirtualQuery(). If VirtualQuery returns a free memory block which
is large enough, the code tries to allocate the memory using VirtualAlloc.

The problem is that Wine pretends in NtQueryVirtualMemory that all memory,
which is not part of Wine's memory management system, is allocated:

--------
            /* not in a reserved area at all, pretend it's allocated */
#ifdef __i386__
            if (base >= (char *)address_space_start)
            {
                info->State             = MEM_RESERVE;
                info->Protect           = PAGE_NOACCESS;
                info->AllocationProtect = PAGE_NOACCESS;
                info->Type              = MEM_PRIVATE;
            }
            else
#endif
--------

Since the application just started and only searches for addresses >= the
module base address, it can't find any free memory. The code to pretend that
all memory is reserved, was added for 32 bit applications to fix bug 4078.
Removing this code fixes the reported issue, but reintroduces the problem that
Wine doesn't know if the memory block is really unused or if it is allocated by
some system library.

The endless loop is caused by a programming mistake in the packer code. The
code tries to iterate over all memory blocks by computing the next address
using the returned BaseAddress and RegionSize. The problem is that they try to
round the addresses to the next page boundary but swapped an addition with a
subtraction. This breaks the iteration and in fact the code only tries two
different addresses in an endless loop.

-- 
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