http://bugs.winehq.org/show_bug.cgi?id=14275
Summary: Kontakt 3 fails at startup Product: Wine Version: 1.1.0 Platform: PC URL: http://www.native-instruments.com/index.php?id=kontakt3 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: skore@skore.de
Created an attachment (id=14566) --> (http://bugs.winehq.org/attachment.cgi?id=14566) An error trace from a Kontakt 3 startup
I will attach an error trace which should be of most help, but have to add here, that I actually tested the demo version of Kontakt 3 before buying it. Back then, there were some quirks, but it was starting. I think the wine version might have been something like 0.9.59. However, when I try to start the demo version with 1.0 or 1.1, it fails.
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #1 from David Deutsch skore@skore.de 2008-07-06 04:18:00 --- Created an attachment (id=14611) --> (http://bugs.winehq.org/attachment.cgi?id=14611) Kontakt 3.0.2 error
I have just updated to 3.0.2 and I now get a different bug. When I start it from a commandline, I get the error/trace you see in the attachment. When I start it from the WM, I get a Runtime Error from the Microsoft C++ Runtime Library ("This application has requested the Runtime to terminate it in an unusual way").
http://bugs.winehq.org/show_bug.cgi?id=14275
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #2 from Anastasius Focht focht@gmx.net 2008-07-06 06:55:15 --- Hello,
the app tries to VirtualLock() a range of previously reserved memory which fails and leads to crash due to buggy application error handling.
This won't work for linux anyway because wine calls mlock() which requires root or user must be a member of a group that has the MLOCK privilege.
Neither Windows VirtualLock() nor Linux mlock() guarantee that the pages requested for locking are never paged out. In Windows, the only pages that never get paged out are those allocated from non-paged pool (which never applies to user processes until explicitly requested by using some AWE API).
They followed the Windows guideline of trimming the process working set through SetProcessWorkingSet() first before trying to lock the memory, which is required prerequisite.
Relevant trace:
--- snip trace --- 0050:Call KERNEL32.GlobalMemoryStatus(0032fad8) ret=0053b4c0 0050:Ret KERNEL32.GlobalMemoryStatus() retval=68edcfff ret=0053b4c0 0050:Call KERNEL32.GetCurrentProcess() ret=0053b5c6 0050:Ret KERNEL32.GetCurrentProcess() retval=ffffffff ret=0053b5c6 0050:Call KERNEL32.SetProcessWorkingSetSize(ffffffff,6aa15000,6ea15000) ret=0053b5cd 0050:Ret KERNEL32.SetProcessWorkingSetSize() retval=00000001 ret=0053b5cd 0050:Call KERNEL32.GetLastError() ret=0053b5df 0050:Ret KERNEL32.GetLastError() retval=00000000 ret=0053b5df .. 0050:Call KERNEL32.VirtualAlloc(00000000,00100010,00001000,00000004) ret=0053b729 0050:Ret KERNEL32.VirtualAlloc() retval=03e80000 ret=0053b729 0050:Call KERNEL32.VirtualLock(03e80000,00100010) ret=0053ac32 0050:Ret KERNEL32.VirtualLock() retval=00000000 ret=0053ac32 0050:Call KERNEL32.GetLastError() ret=0053ac41 0050:Ret KERNEL32.GetLastError() retval=00000005 ret=0053ac41 0050:Call KERNEL32.GetLastError() ret=009ddab3 0050:Ret KERNEL32.GetLastError() retval=00000005 ret=009ddab3 0050:Call KERNEL32.TlsGetValue(00000003) ret=009dd971 0050:Ret KERNEL32.TlsGetValue() retval=7b827efc ret=009dd971 0050:Call KERNEL32.FlsGetValue(00000000) ret=009ddac2 0050:Ret KERNEL32.FlsGetValue() retval=03d70118 ret=009ddac2 0050:Call KERNEL32.SetLastError(00000005) ret=009ddb1d 0050:Ret KERNEL32.SetLastError() retval=00000005 ret=009ddb1d .. 0050:trace:seh:raise_exception code=c0000005 flags=0 addr=0x4290e1 0050:trace:seh:raise_exception info[0]=00000000 0050:trace:seh:raise_exception info[1]=00000004 0050:trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000015 edx=00000000 esi=0032fa78 edi=03dad760 0050:trace:seh:raise_exception ebp=0032fa3c esp=0032fa38 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 0050:trace:seh:call_stack_handlers calling handler at 0xa28dd8 code=c0000005 flags=0 --- snip trace ---
I suggest that wine just pretends "success" to let such applications continue because the POSIX calls won't succeed anyway. The following hack lets the app successfully start. It ignores mlock/munlock errors, pretending success.
--- snip hack --- diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c index ef97eb2..8db0a32 100644 --- a/dlls/ntdll/virtual.c +++ b/dlls/ntdll/virtual.c @@ -1862,7 +1862,11 @@ NTSTATUS WINAPI NtLockVirtualMemory( HANDLE process, PVOID *addr, SIZE_T *size, *size = ROUND_SIZE( *addr, *size ); *addr = ROUND_ADDR( *addr, page_mask );
- if (mlock( *addr, *size )) status = STATUS_ACCESS_DENIED; + if (mlock( *addr, *size )) + { + WARN_(virtual)( "mlock() failed, pretending success\n"); + } + return status; }
@@ -1899,7 +1903,10 @@ NTSTATUS WINAPI NtUnlockVirtualMemory( HANDLE process, PVOID *addr, SIZE_T *size *size = ROUND_SIZE( *addr, *size ); *addr = ROUND_ADDR( *addr, page_mask );
- if (munlock( *addr, *size )) status = STATUS_ACCESS_DENIED; + if (munlock( *addr, *size )) + { + WARN_(virtual)( "munlock() failed, pretending success\n"); + } return status; } --- snip hack ---
Though the app's error handling remains questionable. I verified the demo crashes the same way in Windows when I simulated the error in the debugger.
Regards
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #3 from David Deutsch skore@skore.de 2008-07-06 08:28:15 --- Ah, good to know. If anybody can fix this, just let me know. I'd be happy to negotiate a donation via PayPal to get this done quickly, preferably for the next wine release (if that is within the next two weeks) or with a fool-proof guide how I can fix it myself.
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #4 from Anastasius Focht focht@gmx.net 2008-07-06 09:01:50 --- Hello,
--- quote --- Ah, good to know. If anybody can fix this, just let me know. --- quote ---
Alexandre Julliard will probably come up with proper fix/workaround, now the issue has been tracked down.
--- quote --- I'd be happy to negotiate a donation via PayPal to get this done quickly, preferably for the next wine release (if that is within the next two weeks) or with a fool-proof guide how I can fix it myself. --- quote ---
Either compile from source (GIT) and apply the patch by yourself or just wait some time - you'll be notified when the bug is fixed.
This is a startup bug, happening in early initialization phase of app - so don't get too excited... There might be various other bugs lurking around, once this app is seeing a thorough testing.
For the matter of donating/helping ... see here: http://www.winehq.org/site/contributing Anything is welcome ;-)
If people keep coming up with interesting/challenging bugs, then I'm happy lending a hand - as my limited spare time allows. (BTW this one was a random pick).
Regards
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #5 from David Deutsch skore@skore.de 2008-07-06 09:23:38 --- Uh... you random picked just the right bug then ;)
Looking forward to a fix, will see what I can do about compiling the change myself...
And I already am a Crossover Professional XYZ whatever (I guess that somehow helps you guys as well?). But I will look into some wine donations soon as well.
Thanks for the reply!
http://bugs.winehq.org/show_bug.cgi?id=14275
David Deutsch skore@skore.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14611|0 |1 is obsolete| |
--- Comment #6 from David Deutsch skore@skore.de 2008-08-05 18:12:05 --- Created an attachment (id=15308) --> (http://bugs.winehq.org/attachment.cgi?id=15308) New error output for latest wine version 1.1.2
Slightly different output with wine 1.1.2
http://bugs.winehq.org/show_bug.cgi?id=14275
David Deutsch skore@skore.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #15308|0 |1 is obsolete| |
--- Comment #7 from David Deutsch skore@skore.de 2008-08-30 10:33:02 --- Created an attachment (id=15743) --> (http://bugs.winehq.org/attachment.cgi?id=15743) New error output for latest wine version 1.1.3
http://bugs.winehq.org/show_bug.cgi?id=14275
David Deutsch skore@skore.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.0 |1.1.3
http://bugs.winehq.org/show_bug.cgi?id=14275
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.3 |1.1.0
--- Comment #8 from James Hawkins truiken@gmail.com 2008-08-30 10:43:23 --- Don't change the original reported version.
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #9 from David Deutsch skore@skore.de 2008-08-30 11:01:34 --- Sorry, my bad - got that field wrong.
http://bugs.winehq.org/show_bug.cgi?id=14275
David Deutsch skore@skore.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #15743|0 |1 is obsolete| |
--- Comment #10 from David Deutsch skore@skore.de 2008-09-16 18:18:08 --- Created an attachment (id=16129) --> (http://bugs.winehq.org/attachment.cgi?id=16129) Tested with latest 1.1.4 Release
Error output has changed with 1.1.4. Also, I no longer get a "Microsoft Visual C++" Error when I don't start it from the console.
http://bugs.winehq.org/show_bug.cgi?id=14275
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #11 from Damjan Jovanovic damjan.jov@gmail.com 2009-01-03 09:19:07 --- You can mlock() memory even if you're not root. But the default maximum seems to be only 32 kilobytes which is much less than the 0x00100010 (1 Megabyte) the application wants.
From the mlock man page: "Since Linux 2.6.9, no limits are placed on the amount
of memory that a privileged process can lock and the RLIMIT_MEMLOCK soft resource limit instead defines a limit on how much memory an unprivileged process may lock."
Try with a higher RLIMIT_MEMLOCK?
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #12 from David Deutsch skore@skore.de 2009-01-03 11:16:31 --- A quick google didn't turn up any noob-safe results. Would you be able to point me to a resource where I can learn about how to do this?
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #13 from Damjan Jovanovic damjan.jov@gmail.com 2009-01-04 01:32:46 --- The only way I can see to increase RLIMIT_MEMLOCK is this:
$ sudo bash # ulimit -l unlimited # su <user> $ export USERNAME=<user> $ wine ...
Replace <user> with your usual username, and give it a try. I am not a bash expert, I can't guarantee it won't hose your ~/.wine (or other) permissions.
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #14 from David Deutsch skore@skore.de 2009-01-05 11:17:31 --- Hmm, that didnt run too well:
$ sudo bash # ulimit -l unlimited # su skore $ export USERNAME=skore $ wine /home/skore/.wine/drive_c/Program\ Files/Native\ Instruments/Kontakt\ 3/Kontakt\ 3.exe wine: /home/skore/.wine is not owned by you $ sudo chown skore .wine $ wine /home/skore/.wine/drive_c/Program\ Files/Native\ Instruments/Kontakt\ 3/Kontakt\ 3.exe wine: Call from 0x7b844f60 to unimplemented function ntoskrnl.exe.KeInitializeMutex, aborting wine: Unimplemented function ntoskrnl.exe.KeInitializeMutex called at address 0x7b844f60 (thread 0020), starting debugger...
And that is basically where it stops - the program goes to 14TiB Memory Usage and nothing happens for at least 15 minutes (thats as long as I checked - let me know if I should try to let it running longer).
Does that help? Does it even mean something?
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #15 from Damjan Jovanovic damjan.jov@gmail.com 2009-01-06 01:13:27 --- It seems to be trying to load a kernel mode driver. That's a separate problem.
If you don't increase the memory lock limit, does it die sooner?
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #16 from David Deutsch skore@skore.de 2009-01-06 03:50:31 --- No, then it just complains about the memory directly afterwards:
$ wine /home/skore/.wine/drive_c/Program\ Files/Native\ Instruments/Kontakt\ 3/Kontakt\ 3.exe wine: Call from 0x7b844f60 to unimplemented function ntoskrnl.exe.KeInitializeMutex, aborting wine: Unimplemented function ntoskrnl.exe.KeInitializeMutex called at address 0x7b844f60 (thread 0020), starting debugger... wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart.
...with the same pathology of a dead process that runs wild on imaginary memory.
I have recently updated wine a couple of times, so I guess this would be the most recent error trace.
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #17 from Austin English austinenglish@gmail.com 2009-07-08 15:08:35 --- Is this still an issue in current (1.1.25 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=14275
David Deutsch skore@skore.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16129|0 |1 is obsolete| |
--- Comment #18 from David Deutsch skore@skore.de 2009-07-09 05:55:06 --- Created an attachment (id=22291) --> (http://bugs.winehq.org/attachment.cgi?id=22291) Bug Trace in Wine 1.1.25
Yes, it still fails to start. Latest Bug Trace attached.
http://bugs.winehq.org/show_bug.cgi?id=14275
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #19 from Anastasius Focht focht@gmx.net 2009-12-28 18:22:14 --- Hello,
--- quote --- Yes, it still fails to start. Latest Bug Trace attached. --- quote ---
backtrace -> any reason you use native overrides (rpcrt4)? Only use clean WINEPREFIXes for testing - not existing ones filled with other Windows mal^H^H^Hsoftware.
Anyway, my analysis (comment #2) still applies.
Regards
http://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #20 from Austin English austinenglish@gmail.com 2011-03-29 19:30:18 CDT --- This is your friendly reminder that there has been no bug activity for 6 months. Is this still an issue in current (1.3.16 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=14275
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Status|UNCONFIRMED |NEW Summary|Kontakt 3 fails at startup |Kontakt 3 fails at startup | |(VirtualLock/NtLockVirtualM | |emory of region fails due | |to low per-user default | |"ulimit -l" value) Ever Confirmed|0 |1
--- Comment #21 from Anastasius Focht focht@gmx.net 2011-12-19 16:13:23 CST --- Hello,
--- quote --- This is your friendly reminder that there has been no bug activity for 6 months. Is this still an issue in current (1.3.16 or newer) wine? --- quote ---
yep, still applies but you can work around by raising RLIMIT_MEMLOCK (comment #11).
The lowest limit seems to be around 4 MiB. You get a message box "WARNING: memory is getting low. This may cause dropouts or other artefacts" but the app still starts.
Lower than that it just crashes as I explained in comment #2
'ulimit -l 16384' (16 MiB) seems a safe bet.
Maybe Wine could print a warning once when mlock() fails (looking at errno ENOMEM), suggesting to raise limit like it does when running out of file handles (ulimit -n).
Source:
http://source.winehq.org/git/wine.git/blob/332eee40530f698c74f16d27c9833cccc...
As already explained in comment #2 the app tries to ensure that these lock calls don't fail by relying on SetProcessWorkingSetSize():
From MSDN:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366895.aspx
--- quote --- Applications that need to lock larger numbers of pages must first call the SetProcessWorkingSetSize function to increase their minimum and maximum working set sizes. The maximum number of pages that a process can lock is equal to the number of pages in its minimum working set minus a small overhead. --- quote ---
This API is a no-op in Wine (doesn't touch rlimit on Linux).
If no warning message is desired, it seems feasible to close this bug as WONTFIX.
---
$ sha1sum Kontakt3_Demo_Win.zip 5ae3cba688c835e8ea41923a879cd78103430cc0 Kontakt3_Demo_Win.zip
$ sha1sum Kontakt\ 3\ Demo.exe 3ee4b10f6be8518baecd7372ddc02f3cdef30a28 Kontakt 3 Demo.exe
$ wine --version wine-1.3.35-43-gd9d4a06
Regards
https://bugs.winehq.org/show_bug.cgi?id=14275
--- Comment #22 from Austin English austinenglish@gmail.com --- http://co.native-instruments.com/index.php?id=k3demo
https://source.winehq.org/patches/data/103403
https://bugs.winehq.org/show_bug.cgi?id=14275
jordan triplesquarednine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |triplesquarednine@gmail.com
--- Comment #23 from jordan triplesquarednine@gmail.com --- Hi, I noticed the patch on wine-patches, which led me here and after reading some of the comments, i thought i would point out a few things;
1. *There is an implementation of SetProcessWorkingSetSize for Wine, It just isn't merged (and i couldn't tell you if it is even suitable for merging). That being said, I have been using the patch for a couple of years.
The original patch was for wine 1.3.27, however, in 2012 i had to rebase the patch, as it wouldn't apply cleanly on newer releases.
Kontakt 3 is pretty old, i doubt it is used much anymore. I own Native Instruments Komplete 9 (2013 release) and use Kontakt 5.2.1 in Wine [well, the entire suite actually], quite successfully. However, in order to really be able to use Kontakt - you need more out-of-tree patchwork for Wine.
2). Set realtime without wineserver patch; http://pastebin.com/NEKDLRbw - this patch attempts to fastpath calls to wineserver (applies to THREAD_PRIORITY_TIME_CRITICAL threads, only).
2.a). The famous 'Wine-rt patch"; https://aur.archlinux.org/packages/wine-rt/ - would also be an option, as it is similar, in that it swaps out win32 threads with pthreads for THREAD_PRIORITY_* (i believe by default, it increments in prio by 5 or 10. [it however, doesn't attempt to fastpath these calls and uses polling].
3). ntdll use unix pipes for synchronization objects patch; http://pastebin.com/8g8WcRSA - this patch improves SMP support in Kontakt, significantly.
3.a). 0050-pipe-check-and-thread-safe-read.patch; http://pastebin.com/RMeVAaZU - this patch applies with the unix pipes patch above, and as the name implies does a safety check...
These patches essentially make VSTs/proaudio software usable in Wine, for the most part....
That being said (and i will file a new bug report for this! ...possibly later today) as of wine-1.7.12/13 some changes to ole32's drag and drop code broke NI plugins for me [including kontakt] - they crash due to drag and drop stuff now, on upstream-wine... I reverted those changes, rebased an old patch that solved the crashing [originally, circa wine-1.3.27] by bringing back OLEDD_TrackMouseMove() and restoring the old behavior; http://pastebin.com/s0XPQjnY
anyway, i am sure that is almost too much information, but assuming one actually wants to be able to use NI Kontakt - these patches make it very usable - and obviously i thought SetProcessWorkingSetSize implementation may be of interest to someone here.
cheerz
https://bugs.winehq.org/show_bug.cgi?id=14275
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX
--- Comment #24 from Austin English austinenglish@gmail.com --- <julliard> austin987: just ignore failures <austin987> I had a simpler patch here https://www.winehq.org/pipermail/wine-patches/2014-March/131330.html <julliard> the winediag is not useful <julliard> the app won't see the difference anyway
https://bugs.winehq.org/show_bug.cgi?id=14275
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org