[Bug 35837] The progress bar always stop at %87 when installing the Kingsoft disk installation package
wine-bugs at winehq.org
wine-bugs at winehq.org
Sat Mar 22 10:15:04 CDT 2014
http://bugs.winehq.org/show_bug.cgi?id=35837
Anastasius Focht <focht at gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |download, Installer
Status|UNCONFIRMED |NEW
URL| |http://kad.k.wps.cn/kuaipan
| |/setup/kuaipan_setup.exe
CC| |focht at gmx.net
Depends on| |20466
Summary|The progress bar always |The progress bar always
|stop at %87 when installing |stop at %87 when installing
|the Kingsoft disk |the Kingsoft disk
|installation package . |installation package
Ever confirmed|0 |1
--- Comment #3 from Anastasius Focht <focht at gmx.net> ---
Hello folks,
the installer suffers from multiple bugs .. so it's a bit annoying to sort that
out.
BTW the app bundles a network filter kernel driver and a disk encryption kernel
driver - this won't work anyway.
I don't know what the app is actually supposed to do .. if it depends on those
features this is a lost cause.
Anyway, the installer spawns multiple processes, and one of them is actually
crashing with stack overflow.
The command line parameters can be extracted from the main installer trace log
to run and analyse it stand-alone:
For less noise it's advised to set both kernel drivers (services) to manual
start because the spam the console with non-functional stub calls (kernel
object wait events).
The installer also bundles VC++ 2010 runtime (preferred over Wine builtin).
--- snip ---
$ WINEDEBUG=+tid,+seh,+relay wine "C:\\Program
Files\\Kingsoft\\Klive\\kuaipan.exe" -infohttp "infotype='install'
channel='0101-0201-001'" >>log2.txt 2>&1
...
First chance exception: page fault on execute access to 0x01293fb8 in 32-bit
code (0x01293fb8).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:01293fb8 ESP:0182e3d4 EBP:0182e3f4 EFLAGS:00010206( R- -- I - -P- )
EAX:01293fb8 EBX:006ff040 ECX:0182e430 EDX:00000384
ESI:0182e430 EDI:00000002
Stack dump:
0x0182e3d4: 78ab0715 00000000 0182e6e0 0182e430
0x0182e3e4: 78ab0733 0182e430 78ab076a 0182e6b0
0x0182e3f4: 0182e68c 78b1c784 00000000 0182e6d0
0x0182e404: 01293e64 00000000 00000000 01280f40
0x0182e414: 01000002 01294190 01261b50 01294a20
0x0182e424: 011e3014 00000002 011e3110 0182e518
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0x01293fb8 (0x0182e3f4)
1 0x78b1c784 in msvcr100 (+0x7c783) (0x0182e68c)
2 0x78b060b1 in msvcr100 (+0x660b0) (0x0182e6d0)
3 0x00506b33 in kuaipan (+0x106b32) (0x0182e6f0)
4 0x00506fb9 in kuaipan (+0x106fb8) (0x0182e73c)
5 0x0062ac5d in kuaipan (+0x22ac5c) (0x0182e7a4)
6 0x0062b3cc in kuaipan (+0x22b3cb) (0x0182e98c)
7 0x0046806b in kuaipan (+0x6806a) (0x0182e9c4)
8 0x003445fc in dispatch (+0x45fb) (0x0182e9dc)
9 0x00348465 in dispatch (+0x8464) (0x0182ea48)
...
--- snip ---
The app makes use of the 'XDispatch' Open-Source Framework:
http://opensource.mlba-team.de/xdispatch/docs/current/index.html
--- quote ---
XDispatch provides the power of Grand Central Dispatch not only on Mac OS 10.6+
but also on Windows and Linux. The XDispatch framework consists of three
libraries:
libdispatch
libxdispatch
libQtDispatch
--- quote ---
The crash happens within msvcr100 code during access of C-runtime per thread
data structures (_getptd).
The fault address 0x01293fb8 is actually a valid memory block - unfortunately
not allocated by C-runtime itself and also not excutable.
The reason why this needs to be executable is that newer C-runtime don't store
the per-thread data directly in the slot anymore (what Wine calls
'msvcrt_get_thread_data') but a function pointer to kernel32.FlsGetValue()
instead which is in turn used (executed) for retrieving the actual data.
The mingw page mentions C-runtime use of Fiber Local Storage (FLS) on newer
Windows versions here:
http://sourceforge.net/apps/trac/mingw-w64/wiki/Internal%20thread%20Local%20Storage%20%28TLS%29%20and%20Fiber%20Local%20Storage%20%28FLS%29
If you enable full relay trace, removing 'RelayExclude'/'RelayFromExclude'
filters (registry) you can see those calls from C-runtime
(GetProcAddress("FlsGetValue"), SetTlsValue( slot, FlsGetValue), ... later
FlsGetValue()).
This goes for each newly created thread:
--- snip ---
...
002c:Call PE DLL (proc=0x78ab1dfc,module=0x78aa0000
L"MSVCR100.dll",reason=PROCESS_ATTACH,res=0x1)
...
002c:Call KERNEL32.TlsAlloc() ret=78abbaa2
002c:Ret KERNEL32.TlsAlloc() retval=00000000 ret=78abbaa2
...
002c:Ret PE DLL (proc=0x78ab1dfc,module=0x78aa0000
L"MSVCR100.dll",reason=PROCESS_ATTACH,res=0x1) retval=1
002c:Call PE DLL (proc=0x34a7b9,module=0x340000
L"dispatch.dll",reason=PROCESS_ATTACH,res=0x1)
...
002c:Call KERNEL32.TlsAlloc() ret=003425a6
002c:Ret KERNEL32.TlsAlloc() retval=00000001 ret=003425a6
...
--- snip ---
dispatch.dll internally uses a global TLS slot for managing the libkqueue part
and additional per thread slots -> '_pthread_tls'.
Once a new thread is created each dll gets the thread attach notification.
The C-runtime checks if the slot index (0) has the FLS API pointer already set
and sets it appropriately if not.
During debugging of the app I noticed that TLS slot 0 got overwritten once
dispatch.dll has processed the thread attach notification.
The data was not a function pointer anymore but pointed to something allocated
by xdispatch framework.
When the thread later called C-runtime functions that worked on thread storage
(see mingw page for list of data that is stored per thread), the crash occurred
due to previous overwrite.
Relevant source of library:
https://github.com/mlba-team/xdispatch/blob/master/libkqueue/src/windows/platform.c
--- snip ---
...
#if NO_IMPLICIT_TLS_WORKAROUND
...
/*
* Per-thread evt event buffer used to ferry data between
* kevent_wait() and kevent_copyout().
*/
#define iocp_buf (*( (struct event_buf*)TlsGetValue(event_buf_tls) ))
static DWORD event_buf_tls;
...
// workaround for implicit TLS initialization
// bug on Windows prior to Windows Vista
void libkqueue_thread_attach(){
struct event_buf* ev_buf = malloc(sizeof(struct event_buf));
assert(ev_buf);
TlsSetValue(event_buf_tls, ev_buf);
}
...
void libkqueue_process_attach(){
event_buf_tls = TlsAlloc();
libkqueue_thread_attach();
}
--- snip ---
'event_buf_tls' ought to hold the slot index.
Guess ... libkqueue_process_attach() is _never_ called.
I downloaded v0.7.2 (28/01/2013) "the latest, heavily tested stable release"
Interestingly the Chinese company bundled a private version 0.7.3 of the dll
for which no official sources exist (I dumped version resource, the copyright
is there: 'Marius Zwicker 0.7.3').
I analysed the binaries of both, the official release and the private one and
didn't find any variable/call reference on allocation/setting 'event_buf_tls'.
libkqueue_process_attach() ought to be called from DllMain through init()
(process attach event) - the code is simply not present, neither in source nor
in binaries.
Why does this work on Windows?
Well, I remembered bug 20466 ("Brothers in Arms: Hell's Highway crashes on
startup (TLS slot index allocation must start at non-zero indexes)") I analysed
not long ago.
Same thing: Windows doesn't guarantee that TLS slot index allocation starts at
zero.
What happened is that on Windows the C-runtime gets TLS slot index > 0 while
the broken app/library worked an slot 0 that never got explicitly allocated.
So the whole thing works by pure luck on Windows -> app bug.
And yes, Wine might fix this for compatibility reasons to work around all the
broken apps.
$ sha1sum kuaipan_setup.exe
9b0c617dc67943ff3fecdc7937b83ed784a2774b kuaipan_setup.exe
$ du -sh kuaipan_setup.exe
9.1M kuaipan_setup.exe
$ wine --version
wine-1.7.15
Regards
--
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