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(a)winehq.org ReportedBy: gonhidi(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.