I ran Audacity 2.2.2 for more than 2 days, used mod-script-pipe and also Nyquist prompt. After loading a 100 MB WAV file when played for few seconds and stopped, it hung. After waiting one hour I killed Audacity with kill -9. Now whenever I exit audacity it is giving me this assert failure before exiting
…/…/…/lib-src/mod-nyq-bench/NyqBench.cpp(171): assert “gBench != __null” failed in ModuleDispatch().
Debug: 1 threads were not terminated by the application.
Also the two pipes in /tmp are not getting deleted when audacity exits.
i have removed the /tmp pipes which debug thread I need to kill?
I compiled the source with these options
…/configure --with-lib-preference=“local system” --with-ffmpeg=“system” --disable-dynamic-loading --with-mod-script-pipe --with-mod-nyq-bench
Did you build and enable Nyquist Workbench?
Do you use Nyquist Workbench?
That is known issue (see bottom of this page: https://alphamanual.audacityteam.org/man/Scripting), but it is (to quote Douglas Adams) “mostly harmless”. On most Linux system, when you reboot the computer the pipes will be deleted automatically.
Yes, I built Nyquist Workbench and copied the .lib files to ~/.audacity-files dir. I also enabled Nyq bench. BTW I didn’t use Nyquist Workbench, I only used Nyquist prompt. I am the only user on this Linux system and I used audacity only as one command at a time.
I agree pipes are not a big issue but this assert seems to be very consistent whenever I exit audacity after the hang I faced.
I’m guessing that the assert is a bug in Nyquist Workbench, but I don’t currently have it built so I can’t test right now.
Try disabling Nyquist Workbench in modules preferences, then restart Audacity. Does that stop the assert?
I am sorry for the delay as I was travelling. Yes, you are right when I disabled the Nyq bench the assert is going away. Also if I re-enable Nyq bench the assert is coming back.
I think the assert has been fixed in the current development code.
I’ve logged the “1 threads were not terminated by the application” debug warning on the bug tracker (all threads should be properly terminated on exit).