reconfiguring audio device on startup (segfault)

Bug #505643 reported by fenugrec
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Invalid
High
RJ Skerry-Ryan
1.8
Won't Fix
High
RJ Skerry-Ryan

Bug Description

(similar to bug #360805 )
This happens with both 1.7 #2541 as well as 1.8 trunk #2587 :
If mixxx was last config'd to use ALSA as output, when I restart with JACK running (hence blocking the soundcard), I get the "Sound Device Busy" message box. Choosing "Reconfigure" will segfault mixxx with the following output:
(note that the message box appears after the "invalid number of channels" line)
---------------------
Debug: [Main]: iLatencyMSec: 46
Debug: [Main]: output channels: 2 | input channels: 0
Debug: [Main]: iFramesPerBuffer 2048
Debug: [Main]: iLatencyMSec: 46
Debug: [Main]: Opening stream with id 0
Expression 'parameters->channelCount <= maxChans' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 924
Expression 'ValidateParameters( outputParameters, hostApi, StreamDirection_Out )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1968
Debug: [Main]: Error opening stream: Invalid number of channels
Debug: [LibraryScanner 1]: Scan finished cleanly
Debug: [Main]: FIXME: repaintEverything switches table model and shouldn't do that when viewing the playlist model in src/wtracktableview.cpp: 227
Segmentation fault
$>
-------------------
interestingly, running mixxx in gdb will sometimes delay the segfault:
I can make it to the configuration window, set JACK as the output, then on
pressing OK mixxx explodes.
Backtrace: http://pastebin.ca/1941819

RJ Skerry-Ryan (rryan)
Changed in mixxx:
milestone: none → 1.8.0
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Doh.. the pastebin expired. pastebin.com for the win! I know you guys have Canadian pride though ;)

Revision history for this message
fenugrec (fenugrec) wrote :

Hum yeah I set it to expire pretty quick... I thought it would get fixed by then ! p-) just kiddin' ... Did anyone manage to reproduce this or is it fixed in 1.8b2 or trunk ?

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

I never encountered this myself, I think it's specific to your hardware, which is why I need the backtrace to see what the deal is :).

Thanks
RJ

Revision history for this message
fenugrec (fenugrec) wrote :

Ok, I just updated the original post and re-generated a backtrace, as of 1.8 #2587

jackd 0.118
alsa-lib 1.0.23

Revision history for this message
fenugrec (fenugrec) wrote :
fenugrec (fenugrec)
description: updated
Revision history for this message
fenugrec (fenugrec) wrote :

http://pastebin.ca/1942489
contains whole mixxx output and backtrace.

If the reconfigure button is pressed quickly after the dialog apperas, the prefs dialog shows up. But changing the sound device and pressing OK segfaults, albeit differently:
http://pastebin.ca/1942502

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Turns out I can reproduce this, as you say it's pretty intermittent. I've found that if I set JACK and Mixxx to 48khz, it doesn't happen, but with JACK at 44.1khz it happens all the time. I'm tempted to say this is a PortAudio bug, and I'm trying to reproduce it using PortAudio's test programs outside of Mixxx.

Changed in mixxx:
status: New → Confirmed
importance: Undecided → High
milestone: 1.8.0 → none
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Ok, some more information. If you run JACK at a given sample rate then Mixxx can't open it at any other sample rate than that. So above I was running JACK at 48khz and with Mixxx at 48khz, everything is fine. But when I change Mixxx to 44.1khz I get the crashes.

I think I've tracked this down the the SoundManager. We do Pa_Initialize and Pa_Terminate an awful lot (every time SoundManager::queryDevices is called). I switched so that we only do Pa_Initialize in the SoundManager constructor and only do Pa_Terminate in the SoundManager destructor. Albert, is there a reason that Initialize/Terminate were done on a queryDevice() previously? Do you need to Terminate/Initialize to get a fresh list of available devices?

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

I often get a backtrace with jack_error() and this message "cannot lock down memory for RT thread (Cannot allocate memory)"

Perhaps this is a JACK configuration issue? Still it's not nice to segfault.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Definitely a JACK-related PortAudio bug. This simple program runs infinitely without jackd running and segfaults with it running. I can actually segfault the running loop by simply starting jackd.

while(1) {
        fprintf(stderr, "Initialize\n");
        err = Pa_Initialize();
        if (err == paNoError) {
            fprintf(stderr, "Terminate\n");
            Pa_Terminate();
        } else {
            fprintf( stderr, "Error number: %d\n", err );
            fprintf( stderr, "Error message: %s\n", Pa_GetErrorText( err ) );
        }
 }

Revision history for this message
William Good (bkgood) wrote : Re: [Bug 505643] Re: reconfiguring audio device on startup (segfault)

On Friday 17 September 2010 23:44:03 RJ Ryan wrote:
> Albert, is there a reason that Initialize/Terminate were done on a
> queryDevice() previously? Do you need to Terminate/Initialize to get a
> fresh list of available devices?

This is the case, I ran into this same thing working on my gsoc project. I had
moved the portaudio init and terminate calls to the soundmanager ctors and
dtors and noticed my device list never changed on calling queryDevices.

Revision history for this message
Albert Santoni (gamegod) wrote :

i just added a potential workaround for this in r2622 of the 1.8 branch. If anyone has time, could they please test?

Thanks,
Albert

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

I can't reproduce the original problem anymore. I think it was because I
added the following to my limits.conf:

rryan - memlock unlimited

I didn't have that in there before, now JACK seems a lot happier and doesn't
complain about being unable to lock memory.

On Mon, Sep 20, 2010 at 8:52 PM, Albert Santoni <email address hidden> wrote:

> i just added a potential workaround for this in r2622 of the 1.8 branch.
> If anyone has time, could they please test?
>
> Thanks,
> Albert
>
> --
> reconfiguring audio device on startup (segfault)
> https://bugs.launchpad.net/bugs/505643
> You received this bug notification because you are a bug assignee.
>

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Ok, it's definitely the memlock issue that was triggering the segfault in PortAudio.

I actually just tracked the problem down in PortAudio. The JACK HostAPI doesn't clear a pointer to NULL after free'ing it, which causes the segfault. They will commit the fix soon, but it won't be in Ubuntu 10.10.

Albert committed a workaround for this bug to 1.8.0 which always gives JACK the right samplerate, which unfortunately I don't think solves the problem totally. Mixxx crashes ANY time we fail to open an audio device, so that includes when you start up Mixxx and it tries to open your previous ALSA device when you also have a JACK server running.

We should consider sending chocolates to the PortAudio maintainer to get them to issue an update for the package.

William Good (bkgood)
Changed in mixxx:
assignee: nobody → RJ Ryan (rryan)
milestone: none → 1.9.0
status: Confirmed → Triaged
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

At this point the bug is upstream and already fixed. It's a rare enough circumstance that I'm just going to mark it invalid and it'll go away on its own.

Changed in mixxx:
status: Triaged → Invalid
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5278

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.