Bugzilla – Bug 1808
Crash using SBSMS pitch change at low sample rate
Last modified: 2018-08-20 11:46:03 UTC
As per steps to reproduce. This was originally reported by a forum user on W10 (they did not have step 4 I confirmed this in my W10 laptop. My first run - on 2.2.2 on Windows 10 Home (December Creator's Update) ran through just fine. As second attempt immediately after cause a crash. Steve confirmed this on Linux - but needed to add Step 4 I can reproduce this on my Macbook Pro under macOS 10.13.2 High Sierra a) it needs Steve's extra step to get the failure b) as with my Windows test it ran OK on first pass - and crashed on second use See this Forum thread for more details - callstack and backtrace: https://forum.audacityteam.org/viewtopic.php?f=68&t=98199 The original poster wrote: "May take more than one attempt, possibly depends on uninitialised memory being in a particular state for the heap allocator to pick up on the problem."
Not a regression - happens on all vns back to and including 2.1.3
I see it too in 2.1.2 but intermittently. Quite possibly and old infrequently encountered bug. Some bad memory access happens in a stack deep in the SBSMS library, but some callback functions we define are also in the stack. Suspect stuff in SBSMSEffect.cpp starts at about these lines: // SBSMS has a fixed sample rate - we just convert to its sample rate and then convert back float srTrack = leftTrack->GetRate(); float srProcess = bLinkRatePitch ? srTrack : 44100.0; Perhaps one might figure the but out deductively from what follows.
I looked a bit at this and found out this much: Unusual paths are taken through SBSMSEffect, only when there is a rate other than 44100. The crash is not new in recent Audacity versions. I reproduced it in 2.1.3, and suspect it can be done in very old versions too. The crash is not always reproducible. Peter's steps used a very short sound of 0.3 seconds. It might happen only in such cases, but even so be intermittent. The immediate cause of crash is a bad memory access, deep inside the SBSMS library, but the call stack also includes some functions in our own code that were passed as callbacks into SBSMS; these callbacks then called into SBSMS again. I gave up, sensing deep weeds here that I don't know very well. The possibility of a bug in the library is not excluded, but neither do I know its API well enough to prove that there is no misuse of it on our part. Considering that the bug might be ancient and yet the use case so obscure that it evaded detection by us until now -- I suggest a demotion of its priority.
The bug also appears in "Change Pitch" when using the "High Quality" stretching. 1) Launch Audacity 2) Set Project rate to 11025 3) Generate 0.3 s 440 Hz tone. 4) Apply "Change Pitch" effect: % change: 5 Use High Quality: enabled Audacity stops responding and is thrashing 1 processor core at 100% until forced to quit. Updated description.
(In reply to Paul L from comment #3) Paul wrote: >Considering that the bug might be ancient and yet the use case so obscure that >it evaded detection by us until now -- I suggest a demotion of its priority. We cannot downgrade it as it causes a crash - and thus a P1 It may be obscure, but it was not detected by us - it was first reported by a user on the Forum who was trying to use it.
This may be a very difficult bug to figure out for very little gain. Who on the Team is most familiar with the SBSMS libraries? The basic code here goes back before 2010, the horizon of history that is easily read from our GitHub repository.
As RM I would overrule that. Unless we find someone with expertise in this old library, which seems ill documented (almost nothing in the header files explaining it) -- then I think there is little hope of figuring it out without much diversion of effort, just to satisfy one user. We can suggest to the user the workaround, that they resample to 44100, then apply the effect, then resample down to 11025 again.
But we could use Audacity to block those effects at the extremes that cause the crash, couldn't we?
In other words, partly hobble the feature. We could do that. I don't know the condition we should impose. Allowing it only for sample rates of 44100 might be too restrictive. I don't know.
Here's the one-line eureka fix in lib-src. https://github.com/audacity/audacity/commit/df1d9a08fe9aa2c62fc98862028ca9371b8f6169
(In reply to Paul L from comment #10) Testing on macOS 10.13.2 audacity-macos-nightly-2.2.2-8724a5a.dmg - 26.17 MB | version: 2.2.2--07Jan18 The Steps to reproduce with "Sliding Time/Pitch Shift" do not fail now on Mac Steve's additional steps in Comment #4 with "Change Pitch" also now work correctly. Marked as ok on Mac
Works OK for me on Linux, and it was previously very easily repeatable. I'd recommend testing on Windows before closing, simply because it's P1.
Tested on a 2.2.2 Windows build that James made for me 2.2.2 JC002 07Jan18 The Steps to reproduce with "Sliding Time/Pitch Shift" do not fail now on W10 Steve's additional steps in Comment #4 with "Change Pitch" also now work correctly. Marked as ok on Windows
