Description of problem: When using the 'wineboot.exe --init' in wine, the process consumes 100% of one CPU core for several minutes, then the process dies and several dupliacte errors are printed to the console: modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument ... Version-Release number of selected component (if applicable): 1.7.16-2.fc20.x86_64 How reproducible: Every time tried. Steps to Reproduce: 1. Install wine-1.7.16-2.fc20.x86_64 and ancilliary components (all wine*-1.7.16-2.fc20.{x86_64|noarch} packages, plus wine-mono-4.5.2-1.fc20.noarch) 2. Run 'wine C:\\windows\\system32\\wineboot.exe --init' as a normal user 3. Monitor the process through 'htop' or similar in another terminal. Actual results: The command causes excessive load on one processor core for 4 to 5 minutes(90-100% CPU load, "AMD Athlon(tm) 64 X2 Dual Core Processor 4200+", yes it's old) with no apparent work being done, then dies to command prompt with several duplicate error messages, stating only: modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument Expected results: The command completes without error. Additional info: This may have to do with bug 1096725, I will link it here. It has to do with the kernel update to version 3.14.3. Regressing wine to version 1.7.5-1.fc20 ('yum downgrade wine*') solves the issue, no errors noted and above wineboot command completes the task efficiently within a few seconds (system load dependent), without consuming much CPU. It would seem that the recent kernel version update and the Fedora-packaged wine update to 1.7.16-2.fc20 together cause this issue to come forth.
Forgot to say, VERY IMPORTANT: my shell had 'export WINEARCH=win32' run in it, wine was set to run in 32-bit mode. Sorry, I missed this.
I experienced the problem, but downgrade to wine 1.7.5 didn't work. I did a complete de-install of wine* and mingw-wine-gecko* followed by install of i686 wine on my 64bit F20 machine (3.14.4-200.fc20.x86_64). Still get the wineboot --init problem as described (same with 'winecfg') and then also: ...$ winetricks mdac28 Executing w_do_call mdac28 Executing load_mdac28 Using native,builtin override for following DLLs: odbc32 odbccp32 oledb32 Executing winetricks_early_wine regedit C:\windows\Temp\_mdac28\override-dll.reg Setting Windows version to win98 Executing winetricks_early_wine regedit C:\windows\Temp\_mdac28\set-winver.reg Executing wine mdac_typ.exe modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument modify_ldt: Invalid argument (hangs, unresponsive to CTL-C, 20 of 8 cores at 100%) err:ntdll:RtlpWaitForCriticalSection section 0x7bccecc0 "loader.c: loader_section" wait timed out in thread 0041, blocked by 0040, retrying (60 sec) (repeats every minute) err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x7bc3cbe9 ------------------------------------------------------ Note: command 'wine mdac_typ.exe' returned status 148. Aborting.
That should have bee "2 of 8 cores at 100%" not 20 :)
I recently did a yum update to my F20 install which installed kernel 3.14.4-200.fc20.x86_64, and installed an updated wine (1.7.18-1.fc20.x86_64). The problem noted in the original report resurfaced, this with the WINEARCH=win32 variable set. I again did a 'yum downgrade wine' to wine-1.7.5-1.fc20.x86_64. Noting the report from Wayne Stidolph, I used the latest winetricks to attempt installing the mdac28 tag into a new wine prefix set up as a 32-bit prefix. I ran the command 'WINEARCH=win32 ./winetricks' as a normal user, but the process 'C:\windows\system32\wineboot.exe --init' again ran one of my cores up to around 95-100% and would not complete. It appeared to be hogging system resources in conjunction with another thread running 'cmd.exe /c echo %CommonProgramFiles%', which ran continuously at around 85% CPU. Both the process had to be kill -HUP'ed, they did not complete after 20 minutes wait. From this test and the ones performed by Wayne, it appears that no 32-bit Wine items can be run on the newer 64-bit kernels. This is especially notable for winetricks users, as the GUI interface will warn you when trying to use a 64-bit Wine prefix and reccomend running in a 32-bit prefix to avoid trouble. As I can see in the winetricks installation listing, there are a lot of older 32-bit items that people might want to use, and indeed on the Windows systems that I administer there are a lot of current Windows programs that install in the 32-bit side of the house. I am not sure why my system allowed it to run sucessfully during the original test after downgrading Wine, perhaps I accidently ran the second test in the original report without the 'WINEARCH=win32' variable in that particular shell.
Updated kernel to 3.14.5-200.fc20.x86_64 no change in symptom with wine-1.7.18-1.fc20.i686 "wine --init" gets 5 "modify_ldt" messages and wineboot consumes one CPU (almost no memory load) until "err:process:__wine_kernel_init boot event wait timed out" then repeat. Removed wine-1.7.8, installed wine.x86_64 0:1.7.5-1.fc20, get same effect. Remove wine.x86_64 0:1.7.5-1.fc20, install wine.i686 0:1.7.18-1.fc20, export WINEARCH=32bit, still same effect.
Updated kernel to 3.14.9-200.fc20.x86_64 and get slight change in symptom with wine-1.7.20-1 (both x86_64 and i686 have same symptom) ... after the "modify_ldt" messages I get one CPU core locked at 100% and: err:process:__wine_kernel_init boot event wait timed out wine: cannot find L"C:\\windows\\system32\\--init.exe" In case it helps, an 'strace' of the spinning process shows a continuous stream of that starts like this: Process 19385 attached --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x14} --- [ Process PID=19385 runs in 32 bit mode. ] rt_sigreturn() = 16 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x14} --- rt_sigreturn() = 16 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
Wayne, bug 1096725 gives you the workaround you need. Other workarounds include not running in Windows ME/9x mode or using the default WINEPREFIX on your 64-bit system. Don't include WINEARCH. Wine can properly take care of WOW 32-bit/64-bit calls. I'll leave this open for now in the case that upstream develops a patch to alleviate the lockup.
Michael, thanks!
The very latest kernels (3.14.17 for F19, 3.15.9 for F20) have 16-bit support enabled by default. Feel free to try those out.