[Bug 34126] New: RaidCall 7.2.6: high (100%) CPU usage (on login)

[wine-bugs at winehq.org]

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 at winehq.org
        ReportedBy: gonhidi at 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.