Bugzilla – Bug 251
Segfault when overdub recording with pulse
Last modified: 2018-08-20 11:45:56 UTC
Created attachment 55 [details] Backtrace of an assert found while testing this bug (recording first track in non-maximised window in debug build) - delete if appropriate Repeatable for Steve and Gale on Ubuntu. Presumably a byproduct of PortAudio upddate at: http://code.google.com/p/audacity/source/detail?r=10711
Created attachment 57 [details] Patch that appears to fix the crash I don't know if this is correct... more study required.
I just checked in a fix (r10777) suggested by Ross Bencina on the PortAudio mailing list. This fixes the problem for me.
(In reply to comment #2) Thanks, Al. On Ubunutu 10.10 I tried all available recording and playback options including (hw:0,0) and now get no crashes when overdub recording. I think we should wait a while to make sure there are no adverse effects on Win or Mac? However I don't have OSS as a host, only ALSA. I "thought" OSS was there before r10777. It was certainly there in the recent past and I thought it was there after the PortAudio update that created this issue. I only used default ./configure. Is this a problem?
(In reply to comment #3) I don't have OSS available (Ubuntu 10.10); I tried backing out the change and it doesn't come back (not surprising -- r10777 is a two-line change in an audio callback handler and has nothing to do with device detection). I know I've had OSS available in the past but I don't know how long it's been. Maybe Ubuntu removed it for 10.10. So the OSS thing is at least unrelated to this bug, but we should probably test it just to be sure. We'd need a system that's known to have OSS... Maybe I could get FreeBSD up in a virtual machine this afternoon? No guarantees on when that will happen, but I'll give it a shot.
(In reply to comment #4) Yes I think Ubuntu 10.10 may be the reason: http://ubuntuforums.org/showthread.php?t=1593651 Looks like I mauy need extra steps to get OSS back in Audacity. I did "think" OSS was there in Audaoity after I got 10.10 but I may just be wrong about that. Maybe easier to find out on our Forum; I'll ask there.
Bruno can get an OSS host when building HEAD on Debian Squeeze, so it seems it's Ubuntu that are not making OSS available. Thanks.
No sign of Ross's change making it into upstream portaudio, so I've pushed it there so we don't carry the local change. This works fine for me (where it used to crash). If there is a coherent problem with OSS (not just that it's not installed on your systems any more), please start a new bug for that because it's nothing to do with this issue. Given that Gale, Al and I have this fixed, I see no reason not to close this bug.
(In reply to comment #7) Yes as per comment 6, OSS isn't a problem - people who have OSS installed see it as a host. The reason for waiting was actually to test on Mac that the change hasn't broken anything there (test has been held up because the local fix was committed almost simultaneously with the last Mac nightly, so it wasn't clear if that nightly contained the fix). I think it's better to test now than find a problem later, and good to test because Mac gets relatively little testing. But yes, subject to that, OK of course.
If this change breaks anything on Mac I'll eat my hat, but it can't hurt to test I guess... it seems like we're worrying more about testing this fix than we worried about testing the merge of tons of new PortAudio code, from SVN HEAD, no less, not even a release. Maybe we need to have a regression test list for when we make changes to certain parts of the system, especially audio playback and recording. After a check-in is made the changer can send out a request to do these basic tests on our major platforms... perhaps track in on Bugzilla?
(In reply to comment #9) > If this change breaks anything on Mac I'll eat my hat, but it can't hurt to > test I guess... it seems like we're worrying more about testing this fix than > we worried about testing the merge of tons of new PortAudio code, from SVN > HEAD, no less, not even a release. Your hat can remain in one piece and no doubt logic is on your side, but I had been encouraging testing on the Forum since we last updated PortAudio, so testing the fix didn't break anything was part of that. > Maybe we need to have a regression test list for when we make changes to > certain parts of the system, especially audio playback and recording. After a > check-in is made the changer can send out a request to do these basic tests on > our major platforms... perhaps track in on Bugzilla? I quite like that idea, though it would happen informally anyway if I had time to arrange it on the Forum. We could add testing routines for playback and recording to the "tests" folder in SVN HEAD. Those could also be used for tests when a release is planned/under way, though if there is a problem it's easier caught soon after the commit than later. Whether a bug that is a result of a bug fix is a new bug or not is a bit moot - I find it easier to track in the original bug, modifying the title "Segfault overdubbing with Pulse (fixed, but fix causes overdub crash on Mac)" but others may not.
