http://bugs.winehq.org/show_bug.cgi?id=13227
Summary: 100% CPU Usage with notepad - with dtrace output Product: Wine Version: 0.9.61. Platform: Sun OS/Version: Solaris Status: UNCONFIRMED Severity: major Priority: P2 Component: wineserver AssignedTo: wine-bugs@winehq.org ReportedBy: mritun@gmail.com
Created an attachment (id=13061) --> (http://bugs.winehq.org/attachment.cgi?id=13061) DTrace stacktrace of most often executed functions
wineserver is consuming 100% of CPU while running any application. I have created a test-case with notepad provided with wine. This bug is reproducible every time.
The system is openSolaris build 84 (nevada SXCE build 84).
Specifics are as following:
$ WINEDEBUG=-all wine notepad
$ wine --version wine-0.9.61
$ uname -a SunOS spot 5.11 snv_84 i86pc i386 i86pc
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ RAM: 2 GB DDR2 (single channel 2 GB x 1)
The dtrace script I used to create the backtrace log of where the "wineserver" process is spending most of its time is as following:
# cat wine.d #!/usr/sbin/dtrace -s pid14618:wineserver:: { @[ustack()] = count(); }
http://bugs.winehq.org/show_bug.cgi?id=13227
--- Comment #1 from Akhilesh mritun@gmail.com 2008-05-14 17:02:44 --- I have done some more investigation.
The tracing (on a live case, using dtrace) leads me to the following case:
1. in main_loop (server/fd.c), the poll gets woken up immediately without waiting. DTrace output tells that timeout is being properly set (and decremented every second), but poll wakes up immediately. On being woken up it looks for the fd on which the event happened, and fires fd_poll_event().
2. fd_poll_event ultimately leads to rserver/equest.c::receive_fd - Here the it tries to recvmsg() from socket (confirmed by dtrace - see attached backtrace) but receives 0 sized message (return value confirmed). So then it tries to kill the process by issuing a call to kill_process(process, 0).
3. server/process.c::kill_process - Does the following-
grab_object(..) while((ptr == list_head(&process->thread_list))) { ... kill_thread(...) } release_object(..)
grab_object and release_object are being called (confirmed by dtrace backtrace), but kill_thread() is NEVER getting called.
So I suspect that somehow the call to list_head is failing. I'm not able to trace the call to list_head() as it's being inlined in this build. But this the only way the loop would not get executed.
I am investigating why list_head() is returning a NULL value.
http://bugs.winehq.org/show_bug.cgi?id=13227
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
http://bugs.winehq.org/show_bug.cgi?id=13227
Albert Lee trisk+winehq@acm.jhu.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk+winehq@acm.jhu.edu
--- Comment #2 from Albert Lee trisk+winehq@acm.jhu.edu 2008-05-20 14:55:50 --- (In reply to comment #1)
I have done some more investigation.
The tracing (on a live case, using dtrace) leads me to the following case:
- in main_loop (server/fd.c), the poll gets woken up immediately without
waiting. DTrace output tells that timeout is being properly set (and decremented every second), but poll wakes up immediately. On being woken up it looks for the fd on which the event happened, and fires fd_poll_event().
For SFEwine, I implemented a main loop using the event completion framework: http://pkgbuild.svn.sourceforge.net/viewvc/*checkout*/pkgbuild/spec-files-ex...
Interestingly, this prevents the busy polling problem, although I could reproduce it if I (incorrectly) passed the event handler the full set of events to listen for instead of only the received eventm which presumably prevented the event from being consumed correctly.
- fd_poll_event ultimately leads to rserver/equest.c::receive_fd - Here the it
tries to recvmsg() from socket (confirmed by dtrace - see attached backtrace) but receives 0 sized message (return value confirmed). So then it tries to kill the process by issuing a call to kill_process(process, 0).
- server/process.c::kill_process - Does the following-
grab_object(..) while((ptr == list_head(&process->thread_list))) { ... kill_thread(...) } release_object(..)
grab_object and release_object are being called (confirmed by dtrace backtrace), but kill_thread() is NEVER getting called.
So I suspect that somehow the call to list_head is failing. I'm not able to trace the call to list_head() as it's being inlined in this build. But this the only way the loop would not get executed.
I am investigating why list_head() is returning a NULL value.
Perhaps this is a case where list_head was redefined that was overlooked when #11463 was fixed?
http://bugs.winehq.org/show_bug.cgi?id=13227
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED Target Milestone|--- |1.0.1
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2008-06-21 05:40:53 --- Fixed by 24ec4a6ed7bf5c7c8edadc7da3bd5f6160a4d53d.
http://bugs.winehq.org/show_bug.cgi?id=13227
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Alexandre Julliard julliard@winehq.org 2008-06-27 10:15:44 --- Closing bugs fixed in 1.1.0.
http://bugs.winehq.org/show_bug.cgi?id=13227
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|sparc |Other
--- Comment #5 from Austin English austinenglish@gmail.com 2013-03-11 18:10:59 CDT --- Deprecating sparc platform.
-
wine-bugs＠winehq.org