Bugzilla – Bug 1223
Click Track causes Audacity to crash when creating very many clicks
Last modified: 2018-08-20 11:45:45 UTC
See steps to reproduce. The problem occurs with Debug build on Debian Stable (Jessie). Not yet tested with a release build on Linux. The problem does not occur with Oct 1st Nightly on Windows XP running in Virtualbox. If the "SEQ" command is removed from near the end of clicktrack.ny, the plug-in completes generating the click track without crashing, but then does not have the final silence for the last beat, and does not have the start offset. To do this, replace the lines: ;add time offset and beatlen of silence to clicktrack, (seq (s-rest offset) ;offset (cue clicktrack) ;click track (s-rest(- beatlen ticklen)))) ;trailing silence with a single close bracket. The SEQ command appears to work normally in other contexts. It may be possible to work around this problem by writing the plug-in differently, but I don't yet see why this problem is occurring, or why it occurs on my Linux build but not the Windows Nightly.
(In reply to Steve Daulton from comment #0) The crash also occurs in a release build (preferences reset to default).
Windows does not crash (real hardware) but El Capitan and Ubuntu 14.04 32-bit both crash at these 12000 beats combinations: Beats 12 / Measures 1000, Beats 15 / Measures 800 or Beats 20 / Measures 600. 8000 beats does not crash. I think it's close to P3 but probably not quite there, assuming > 8 beats per measure is unusual. 4 Beats / 3000 Measures also crashes, but you have to modify the plugin to try that.
(In reply to Gale Andrews from comment #2) > assuming > 8 beats per measure is unusual More than 8 beats per bar may not be unusual. If the user wants to practice quaver passages in 4/4 they may well want 16 clicks per bar. More than 100 bars is probably unusual. Is this a regression against previous releases?
(In reply to Steve Daulton from comment #3) "semiquaver"
(In reply to Steve Daulton from comment #3) > Is this a regression against previous releases? 2.1.1 Release on Linux crashes the same, so it is not the most serious type of regression on that "measure".
This crashed because of stack overflow in libnyquist code. It ought to be reproducible on Windows too, with a long enough click track. Stack on Mac contained: #174368 0x006d6ac3 in snd_list_unref at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyquist/nyqsrc/sound.c:533 #174369 0x006d6ac3 in snd_list_unref at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyquist/nyqsrc/sound.c:533 #174370 0x006d6ac3 in snd_list_unref at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyquist/nyqsrc/sound.c:533 #174371 0x006d68e7 in sound_unref at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyquist/nyqsrc/sound.c:477 #174372 0x006d8b77 in sound_xlfree at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyquist/nyqsrc/sound.c:1609 #174373 0x00772d18 in sweep at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyquist/xlisp/xldmem.c:511 #174374 0x0077262e in gc at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyquist/xlisp/xldmem.c:344 #174375 0x006903c1 in nyx_get_audio at /Users/paullicameli/GitHub/audacity/lib-src/libnyquist/nyx.c:1063 #174376 0x001017db in NyquistEffect::ProcessOne() at /Users/paullicameli/GitHub/audacity/src/effects/nyquist/Nyquist.cpp:1182 #174377 0x000fcce7 in NyquistEffect::Process() at /Users/paullicameli/GitHub/audacity/src/effects/nyquist/Nyquist.cpp:698 And many repetitions of snd_list_unref above that until exhaustion.
Fixed at https://github.com/audacity/audacity/commit/8ad9fd257c6a90313d87dab8c4bf803a945b7076 but we need to tell Roger to push it upstream to Nyquist.
Tests ok on W10 audacity-win-r3410b60-2.1.3-alpha-22-jun-16 But part way through I did get a warning message to say it wasn't responding but thn it just carried on and completed
I say mark the crash bug as fixed. The lenghty calculation that makes the application unreponsive is just life.
OK for me too on Windows 10 but steps still crash for me on El Capitan and Ubuntu 14.04 at https://github.com/audacity/audacity/commit/56acdf6 (release builds in both cases, I made distclean in both cases). On Mac I saw no progress dialogue for Click Track, on Linux I did. In both cases the Audacity Debug Report was generated. I have attached the Ubuntu 14.04 backtrace assuming that will be more use. Roger is already on the Cc list for this bug.
Created attachment 682 [details] gdb backtrace from Ubuntu 14.04
I know it crashed with a stack overflow before on my MacbookPro, and now it does not. But the stack trace suggests that there is another deep recursion happening during the evaluation of the sound. Perhaps my stack space is enough not to overflow, and Gale's isn't. A similar code transformation exercise might fix this. But it is less obvious how to handle these mutually recursive functions. The fix I wrote just involved one self-recursive function.
I finally took a look at the click track code -- it puts the entire click track in Nyquist memory, so yes, long click tracks are going to allocate a lot of memory and if you don't have enough RAM, there will be a lot of swapping to disk. I'm working on a rewrite.
The fix was redone here, to be exactly as Roger rewrote it: https://github.com/audacity/audacity/commit/ba1b63a4352c3c6cab3ef716fded14fe3c11c064 I doubt this fixes Gale's latest crash, but try it.
Created attachment 683 [details] Fix clicktrack.ny to use lazy evaluation
Created attachment 684 [details] Here's the whole plug-in, modified to use lazy evaluation
clicktrack.ny was pretty simple to modify to avoid accumulating samples in Nyqvist -- I don't really have a good way to test this claim, and I was surprised that the (stats) function does not seem to generate output to Audacity. In any case, this runs about 25% faster than the previous version on my machine, and it does not crash (but neither does the old version). It would be nice for someone to test on a machine that had problems, even if the problems were just running slowly, and see what happens.
(In reply to Paul L from comment #14) > The fix was redone here, to be exactly as Roger rewrote it: > https://github.com/audacity/audacity/commit/ba1b63a > > I doubt this fixes Gale's latest crash, but try it. Testing at that commit, it does not fix the steps to reproduce on Ubuntu 14.04 netbook (1 GB RAM), either with the shipped Click Track or Roger's lazy_evaluation version. The stack track (attached, "bug_1223_gdb_240616.txt") is similar to before but does not have repeated in add_s1_nn_fetch (), in SND_get_first (), in SND_get_next (). On El Capitan (4 GB RAM), there is now no crash with the shipped Click Track but the lazy_evaluation version crashes every time, see attached "bug_1223_lazy_eval_mac_240616.txt". On Windows 10, I do not receive a crash with either the shipped or lazy_evaluation plugin, but the lazy one is twice as quick.
Created attachment 688 [details] New stack trace on Ubuntu 14.04
Created attachment 689 [details] Mac crash report for the lazy_evaluation version of Click Track
My guess from the stack is a dangling pointer somewhere from a failure to increase a reference count... Roger?
Thank you James for catching a silly mistake that escaped me and Roger! https://github.com/audacity/audacity/commit/016919a53bb8f17de2a9070fbe84ed88fb27e175 Try it again, Gale.
I tried the released Click Track and the faster, lazy version several times on El Capitan (Mac Mini) and Ubuntu 14.04 (netbook) and there were no crashes. And it was still OK on Windows. So RESOLVED - FIX and thanks to James.
