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

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(a)winehq.org
        ReportedBy: mritun(a)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();
}


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

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

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





--- Comment #1 from Akhilesh <mritun(a)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.


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

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

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


Dmitry Timoshkov <dmitry(a)codeweavers.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal




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

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

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


Albert Lee <trisk+winehq(a)acm.jhu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trisk+winehq(a)acm.jhu.edu




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

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

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


Alexandre Julliard <julliard(a)winehq.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |1.0.1




--- Comment #3 from Alexandre Julliard <julliard(a)winehq.org>  2008-06-21 05:40:53 ---
Fixed by 24ec4a6ed7bf5c7c8edadc7da3bd5f6160a4d53d.


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

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

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


Alexandre Julliard <julliard(a)winehq.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED




--- Comment #4 from Alexandre Julliard <julliard(a)winehq.org>  2008-06-27 10:15:44 ---
Closing bugs fixed in 1.1.0.


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

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

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

Austin English <austinenglish(a)gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|sparc                       |Other

--- Comment #5 from Austin English <austinenglish(a)gmail.com> 2013-03-11 18:10:59 CDT ---
Deprecating sparc platform.

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