[haiku-bugs] Re: [Haiku] #9896: DVD file copy stalls at ca. 1 GB, pegs CPUs

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Thu, 25 Jul 2013 14:57:38 -0000

#9896: DVD file copy stalls at ca. 1 GB, pegs CPUs
--------------------------------+----------------------------
   Reporter:  ttcoder           |      Owner:  nobody
       Type:  bug               |     Status:  new
   Priority:  normal            |  Milestone:  R1
  Component:  File Systems/UDF  |    Version:  R1/Development
 Resolution:                    |   Keywords:
 Blocked By:                    |   Blocking:
Has a Patch:  0                 |   Platform:  All
--------------------------------+----------------------------

Comment (by bonefish):

 The infinite loop can be at any level in the stack trace. So entering KDL
 multiple times to do a stack trace would indeed help to possibly rule out
 the functions in the upper stack. Fortunately the kernel debugger has an
 even more helpful tool for this case: breakpoint support. The "caller"
 column shows the return addresses, so setting a breakpoint at such an
 address can conclusively determine whether the callee returns to the
 caller.

 The only caveat of the method is that breakpoints cannot be restricted to
 certain teams or threads, so setting a breakpoint in a commonly used
 function (like in the memory allocation code) will likely not be very
 helpful, since it may repeatedly be triggered by other threads. The four
 UDF functions we see in the stack trace should be pretty good locations,
 though. The file map related kernel code might be OK, too. It is also used
 by BFS, but it shouldn't be hit very often (possibly only for the syslog
 writes), as long as you avoid doing stuff with files (e.g. in Tracker).

 The strategy as such is rather simple:
  1. Enter KDL and get a stack trace of the misbehaving thread.
  2. Pick one of the caller addresses, set a breakpoint via `breakpoint
 <address>`, and `continue`.
  3. If the breakpoint is hit (KDL will be entered with a respective
 message):
     - If it is in the wrong thread, just continue. If the breakpoint keeps
 being hit by the wrong threads, clear the breakpoint (`breakpoint
 <address> clear` -- use the command history to avoid address typos) and
 try 2. again with a different address.
     - If it is in the right thread, clear the breakpoint and try 2. again
 with an address lower in the stack trace.
    If the breakpoint is not hit, clear the breakpoint and try 2. again
 with an address higher in the stack trace.

 The goal of the exercise is to find the topmost caller that is not being
 returned to or at least narrow it down (i.e. find a lower boundary).

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

Other related posts:

  1. Home
  2. haiku-bugs
  3. Archive
  4. 07-2013