http://bugs.winehq.org/show_bug.cgi?id=34126
Bug #: 34126 Summary: RaidCall 7.2.6: high (100%) CPU usage (on login) Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: gonhidi@gmail.com Classification: Unclassified
Created attachment 45385 --> http://bugs.winehq.org/attachment.cgi?id=45385 MacPorts Wine 1.6 Raidcall 7.2.6 log: launch and login
Wine 1.6 causes RaidCall's 7.2.6 CPU usage to spike after a successful login. The offending process remains active after exiting the application preventing the wineserver and the other wine processes from closing.
I have observed this behaviour when running MacPort's 1.6 wine port, on OS X 10.8.4. It is not present on the previous version of the build, 1.4.1_4. Running winedbg and calling info processes before and after RaidCall login shows a new process likely to be the CPU hog, 'Wizard.exe' (part of the RaidCall installation).
Wine-dbg>info process pid threads executable (all id:s are in hex) 00000025 9 'raidcall.exe' 00000041 12 _ 'Wizard.exe' 00000022 2 'explorer.exe' 0000000e 5 'services.exe' 0000001a 3 _ 'plugplay.exe' 00000012 4 _ 'winedevice.exe'
The way I run RaidCall is by executing "wine start 'C:\Program Files\RaidCall\raidcall.exe'" (after having installed the program using "wine raidcall.exe"). The result of a "wine start 'C:\Program Files\RaidCall\raidcall.exe' &> log-run.txt" is attached.
Killing the offending process doesn't seem to break RaidCall, at least superficially. I have not tested deeper to see if it is a valid workaround.
I have tried using git bisect to trace the behaviour to a commit. I followed the instructions from “MacOSX/Building” section “Build Wine git version, the MacPorts way” (http://wiki.winehq.org/MacOSX/Building#head-ca82f43f942cbed405199780ca73d07f71fd5d40), but running wine from within the build directory (i.e. skipping the make install step):
make clean ./configure CPPFLAGS='-I/usr/X11/include -I/opt/local/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib -L/opt/local/lib' make DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib:/opt/local/lib" ./wine raidcall.exe DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib:/opt/local/lib" ./wine start 'C:\Program Files\RaidCall\raidcall.exe'
Doing nothing but that I soon started having build problems (likely reason being that of the “Compiling Wine on Mac OS X 10.8.2?” February 2013 wine-devel mailing list thread) so I set CC to MacPort's clang 3.3 (@3.3_0+analyzer+python27). From then on, things went smoothly and led to the following git commit:
[2f48b12c575c4e1afc6115a39d60722acda73d7d] gdi32: Use the Mac driver by default
Note that using the aforementioned build process the 100% CPU usage also appears when launching the RaidCall installer, so perhaps the issue is not the same or something else is showing up.
http://bugs.winehq.org/show_bug.cgi?id=34126
Gonzalo Higuera_Díaz gonhidi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Linux |Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=34126
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |kennybobs@o2.co.uk Component|-unknown |gdi32 Version|unspecified |1.6 Regression SHA1| |2f48b12c575c4e1afc6115a39d6 | |0722acda73d7d
--- Comment #1 from Ken Sharp kennybobs@o2.co.uk 2013-07-25 18:47:48 CDT --- Please don't confuse things: are you saying that the installer has the same problem in the same build? That will probably be a separate bug altogether.
Is this application available for download?
Possibly a duplicate of Bug 34095. There is a patch in that bug that you can test to find out.
http://bugs.winehq.org/show_bug.cgi?id=34126
--- Comment #2 from Gonzalo Higuera_Díaz gonhidi@gmail.com 2013-07-26 07:38:01 CDT --- (In reply to comment #1)
Please don't confuse things: are you saying that the installer has the same problem in the same build? That will probably be a separate bug altogether.
Using the described compilation process for the given build there are two 100% CPU usage issues. The one being tracked here is the one that occurs after login, post installation. The one during setup, as you say, is likely something different to be tracked elsewhere.
Is this application available for download?
Yes, via http://www.raidcall.com/.
Possibly a duplicate of Bug 34095. There is a patch in that bug that you can test to find out.
The patch there does not solve the issue.
http://bugs.winehq.org/show_bug.cgi?id=34126
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://update.raidcall.com/ | |download/raidcall.exe?v=7.2 | |.6
--- Comment #3 from Ken Sharp kennybobs@o2.co.uk 2013-07-26 10:41:49 CDT --- Thank you for testing.
http://bugs.winehq.org/show_bug.cgi?id=34126
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | Regression SHA1|2f48b12c575c4e1afc6115a39d6 | |0722acda73d7d |
--- Comment #4 from Alexandre Julliard julliard@winehq.org 2013-07-30 05:46:35 CDT --- Mac driver bugs are not technically regressions.
http://bugs.winehq.org/show_bug.cgi?id=34126
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #5 from Ken Thomases ken@codeweavers.com 2013-08-12 14:37:47 CDT --- I recommend that you use Activity Monitor to identify the process ID of the process using lots of CPU. Then, collect a sample report (View > Sample Process) and attach that.
Also, in a shell, issue the command "ps xww -p <pid of process using 100% CPU>" (e.g. "ps xww -p 1234"). Show the output of that.
http://bugs.winehq.org/show_bug.cgi?id=34126
--- Comment #6 from Ken Thomases ken@codeweavers.com 2013-08-12 14:38:57 CDT --- Oh, and try switching to the X11 driver to see if that changes the behavior.
[HKEY_CURRENT_USER\Software\Wine\Drivers] "Graphics"="x11"
http://bugs.winehq.org/show_bug.cgi?id=34126
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|kennybobs@o2.co.uk |
https://bugs.winehq.org/show_bug.cgi?id=34126
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #7 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-7.0-rc>5?