bugGNU Octave - Bugs: bug #50674, audiorecorder() crashes in...


bug #50674: audiorecorder() crashes in getaudiodata()

Submitted by:  Lars Kindermann <larskindermann>
Submitted on:  Wed Mar 29 22:37:45 2017  
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: Patch SubmittedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Thu Mar 30 21:24:12 2017, comment #3:

I verified the patch fixes things for me.

@jwe: You raised the suggestion that this might require more in-depth work to fix then just the mutex lock. Should you check in your patch as an immediate interim fix? If the concern is more about performance, should that be the subject of another bug report?

Rik <rik5>
Project Administrator
Thu Mar 30 13:42:03 2017, comment #2:

Using the attached patch, I was able to avoid the crash. So it seems that portaudio_record_callback could be called while getaudiodata is active. If so, and if the callback function causes the left and right data vectors to be resized/reallocated, then we are in trouble, and that would explain the double free crash.

However, the implementation looks like trouble to me since it can resize and possibly copy the left and right data buffers many times. Maybe we should use a list of buffers so that once once is created, its address can't change? And each buffer in the list should be allocated to have some predetermined size so that it is not resized. When a buffer fills, we just add another to the list. Then getting data out and into a contiguous array means concatenating all these buffers.

Even with a scheme like that, locking might be necessary, but it would be good to limit the time spent locked. I admit I don't understand exactly how all this works, but I imagine that locking could disrupt recording if copying a large buffer (or list of buffers) requires too much time.

(file #40211)

John W. Eaton <jwe>
Project Administrator
Thu Mar 30 05:07:02 2017, comment #1:

I used a slightly modified program which I have attached.

Here is a backtrace from gdb, also attached.

There is a double free or other corruption in malloc from the getaudiodata call.

(file #40205, file #40206)

Rik <rik5>
Project Administrator
Wed Mar 29 22:37:45 2017, original submission:

Executing this script hangs Octave after few iteratons and leaves it stuck at 100% CPU, both in GUI and on commandline.

CTRL-C then terminates the GUI. On commandline this info is shown:

I wonder if it is hardware dependent, a portaudio thing or Octave?

Lars Kindermann <larskindermann>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #40211:  diffs.txt added by jwe (2kB - text/plain)
file #40205:  tst_rec.m added by rik5 (428B - text/x-objcsrc)
file #40206:  btrace.log added by rik5 (6kB - text/x-log)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jwe (Updated the item)
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by larskindermann (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu Mar 30 21:24:12 2017rik5StatusConfirmed=>Patch Submitted
    Thu Mar 30 13:42:03 2017jweAttached File-=>Added diffs.txt, #40211
    Thu Mar 30 05:07:28 2017rik5StatusNone=>Confirmed
    Thu Mar 30 05:07:02 2017rik5Attached File-=>Added tst_rec.m, #40205
      Attached File-=>Added btrace.log, #40206

    Back to the top

    Powered by Savane 3.1-cleanup1