[Bug 13227] 100% CPU Usage with notepad - with dtrace output

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=13227


Albert Lee <trisk+winehq at acm.jhu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trisk+winehq at acm.jhu.edu




--- Comment #2 from Albert Lee <trisk+winehq at 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:
> 
> 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().
> 

For SFEwine, I implemented a main loop using the event completion framework:
http://pkgbuild.svn.sourceforge.net/viewvc/*checkout*/pkgbuild/spec-files-extra/trunk/patches/wine-04-event-completion.diff

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.

> 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.
> 
Perhaps this is a case where list_head was redefined that was overlooked when
#11463 was fixed?


-- 
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.