[haiku-bugs] Re: [Haiku] #11497: Media/mixer crash, either buffer "oops" or NULL indirection in float_to_float()

  • From: "pulkomandy" <trac@xxxxxxxxxxxx>
  • Date: Fri, 12 Dec 2014 16:59:34 -0000

#11497: Media/mixer crash, either buffer "oops" or NULL indirection in
float_to_float()
-----------------------------------+----------------------------
   Reporter:  ttcoder              |      Owner:  nobody
       Type:  bug                  |     Status:  new
   Priority:  critical             |  Milestone:  R1/beta1
  Component:  Add-Ons/Media/Mixer  |    Version:  R1/Development
 Resolution:                       |   Keywords:
 Blocked By:                       |   Blocking:  11584
Has a Patch:  0                    |   Platform:  All
-----------------------------------+----------------------------

Comment (by pulkomandy):

 So, to get debug infos enabled without making the crash go away:
 * Edit src/kits/media/Jamfile and add "SubDirC++Flags -ggdb ;"
 * Remove all files in generated/objects/haiku/x86_gcc2/release/
 * Build the lib again
 With this I could reproduce the crash and have a look with Debugger. The
 crashed thread is "Audio Mixer control". It crashes in
 CONSUMER_BUFFER_RECEIVED (that was easy to guess even without the debug
 info).

 This part of the code is about receiving media buffers, which comes from
 some producer. The buffers are recycled, after they are sent to the audio
 output, so they can be used by the producer again. This way, after an
 initial phase of creating buffers, things should stabilize and the buffers
 are reused in a loop.

 To make this fast, the buffers are stored in a cache (this is
 fBufferCache). What is stored here is a small object with a pointer to the
 data. The actual data for the buffer is in shared memory so it can be
 shared with other applications.

 The first time we get a buffer, it is not in the buffer cache yet and we
 create a new BBuffer object for it (this happens in GetBuffer). Then we
 fill that buffer with the relevant data and pass it to BufferReceived.

 There is a check there (this is our "oops") that the buffer we get from
 the cache comes from the right producer, and not from another one. And,
 this check fails. This means our buffers are mixed up. Either the buffer
 cache got somehow corrupted, or maybe it still references buffers that
 were deleted.

 I'm surprised by the complete lack of locking in that part of the code,
 which is probably on purpose to have good performance and low latency. I
 hope everything is carefully single threaded, but even then, it looks like
 things like a dropped message could put things out of sync here. How safe
 are ports with regard to this?

--
Ticket URL: <https://dev.haiku-os.org/ticket/11497#comment:11>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

Other related posts:

  1. Home
  2. haiku-bugs
  3. Archive
  4. 12-2014