[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile

  • From: "ttcoder" <trac@xxxxxxxxxxxx>
  • Date: Wed, 05 Oct 2011 15:58:38 -0000

#8007: [app_server] fully unresponsive when resizing window of big textfile
----------------------------------+----------------------------
   Reporter:  ttcoder             |      Owner:  axeld
       Type:  bug                 |     Status:  new
   Priority:  normal              |  Milestone:  R1
  Component:  Servers/app_server  |    Version:  R1/Development
 Resolution:                      |   Keywords:
 Blocked By:                      |   Blocking:
Has a Patch:  0                   |   Platform:  All
----------------------------------+----------------------------

Comment (by ttcoder):

 Steps:
 You may for instance...

 - wget ftp://ftp.fu-berlin.de/misc/movies/database/costume-
 designers.list.gz
 - expand the tarball
 - double click the .list textfile (it opens in a couple seconds)
 - resize the window (this step is only necessary the first time you run
 the test; next time StyledEdit will remember its size and bring the system
 to its knees without further ado).


 Expected behavior:
 - the OS should stay responsive, or at least sluggish (a la Windows) but
 not completely ''frozen'', while StyledEdit recalculates its Frame() and
 layout.

 Actual Behavior:
 - the mouse pointer stops moving completely for dozens of seconds.
 - keyboard unresponsive as well.
 - the screen itself stops refreshing.
 Basically the whole computer is frozen for up to a minute if the file is
 big enough.

 Hardware:
 This is an AthlonXP 1800+ with 512 MB of RAM. So only '''one "core" '''
 (or "CPU") in case it matters (and maybe it does, seeing the experiences
 in #7882 ? there seems to be an emerging pattern...)

 To be clear, there might be misbehaving (or at least unoptimized) code in
 StyledEditwindow::FrameResize(), who knows.. But the app_server really
 shouldn't be vulnerable to that, even from B_DISPLAY_PRIORITY threads! So
 I'm filing this against app_server initially (I have no idea if this
 problem goes deeper, into actual management of threads in the kernel?).

 To reproduce this bug, those with dual-core systems might want to open
 Pulse and disable one of the cores I guess.

 This is with r42760 .


 P.S. I swear I was not working on extending my torture tests in #7882 :-)

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:1>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: