Audacity crashes on Exit command through pipe interface

Hi. I’ve created a Python script to clean up my 4000+ MP3 library. It starts Audacity in an asynchronous thread and uses macro through pipe interface. All works fine until the Exit: command is sent. When that happens, 9 out of 10 times Audacity will crash. Perhaps first 2 crash reports were accepted, and all later failed to be submitted.

So, here I am reporting this issue. This is version 3.7.8 64-bit on Windows 10 x64. There seem to be 6 different crashes. Here is a shortened version of those crash reports.

Operating system: Windows NT
10.0.19045 7663
CPU: amd64
family 6 model 151 stepping 2
20 CPUs

GPU: UNKNOWN

Crash reason: EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x10
Process uptime: 10 seconds

Thread 0 (crashed)
0 lib-track.dll + 0xdd76
rax = 0x0000000000000000 rdx = 0x0000006d4e8ff100
rcx = 0x0000006d4e8ff140 rbx = 0x0000006d4e8ff140
rsi = 0x0000006d4e8ff140 rdi = 0x0000006d4e8ff280
rbp = 0x0000006d4e8ff0f8 rsp = 0x0000006d4e8feff0
r8 = 0x0000000000000000 r9 = 0x000001d62602c5b0
r10 = 0x0000000000008000 r11 = 0x0000006d4e8ff550
r12 = 0x00007ffd261eada0 r13 = 0x0000000000000020
r14 = 0x000001d62602c5b0 r15 = 0x0000000000000000
rip = 0x00007ffd261cdd76
Found by: given as instruction pointer in context

Stack contents:
 0000006d4e8feff0 70 58 5d 1b d6 01 00 00 df 85 bd a6 fd 7f 00 00  pX].Ö...߅½¦ý...
Possible instruction pointers:

Crash reason: EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x10
Process uptime: 10 seconds

Thread 0 (crashed)
0 lib-track.dll + 0x4b5e
rax = 0x0000000000000000 rdx = 0x000000f2eb4ff2e8
rcx = 0x0000000000000000 rbx = 0x0000020ce99b2410
rsi = 0x000000f2eb4ff4b0 rdi = 0x0000000000000000
rbp = 0x000000f2eb4ff370 rsp = 0x000000f2eb4ff270
r8 = 0x000000f2eb4ff470 r9 = 0x0000000000000001
r10 = 0x0000000000008000 r11 = 0x000000f2eb4ffa70
r12 = 0x0000000000000000 r13 = 0x000000f2eb4ff470
r14 = 0x0000020ce878ef50 r15 = 0x0000020ce8775e10
rip = 0x00007ffd26524b5e
Found by: given as instruction pointer in context

Stack contents:
 000000f2eb4ff270 10 24 9b e9 0c 02 00 00 00 00 00 00 00 00 00 00  .$ݎ............
 000000f2eb4ff280 00 00 00 00 00 00 00 00 1b a1 87 a6 fd 7f 00 00  .........¡‡¦ý...
Possible instruction pointers:

Crash reason: EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x1c0cad4fa60
Process uptime: 9 seconds

Thread 0 (crashed)
0 lib-menus.dll + 0x1bd54
rax = 0x0000000000000000 rdx = 0x0000000000000007
rcx = 0x000001c0cad4fa60 rbx = 0x000001c0c9bcc760
rsi = 0x000001c0c9a633d0 rdi = 0x000001c0c9bcc760
rbp = 0x000000ac233ff490 rsp = 0x000000ac233ff340
r8 = 0x000000ac233ff360 r9 = 0x0000000000000000
r10 = 0x0000000000000014 r11 = 0x000000ac233ff1f0
r12 = 0x000001c0cadc2208 r13 = 0x00000000ffffffff
r14 = 0x00000000ffffffff r15 = 0x000001c0c7316150
rip = 0x00007ffd2830bd54
Found by: given as instruction pointer in context

Stack contents:
 000000ac233ff340 60 c7 bc c9 c0 01 00 00 90 f4 3f 23 ac 00 00 00  `ǼÉÀ....ô?#¬...
 000000ac233ff350 d0 33 a6 c9 c0 01 00 00 50 42 d1 25 fd 7f 00 00  Ð3¦ÉÀ...PBÑ%ý...
Possible instruction pointers:

Crash reason: EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x498
Process uptime: 10 seconds

Thread 0 (crashed)
0 lib-menus.dll + 0x1bce9
rax = 0x0000000000000092 rdx = 0x0000000000000000
rcx = 0x0000000000000000 rbx = 0x0000004a0e6ff830
rsi = 0x0000020d2abfa7e0 rdi = 0x0000020d2abfa7e0
rbp = 0x0000004a0e6ff830 rsp = 0x0000004a0e6ff6e0
r8 = 0x0000000000000008 r9 = 0x0000000000000008
r10 = 0x00000100000001b3 r11 = 0x0000004a0e6ff590
r12 = 0x0000020d2bf8ade8 r13 = 0x00000000ffffffff
r14 = 0x00000000ffffffff r15 = 0x0000020d2840c760
rip = 0x00007ffd27dcbce9
Found by: given as instruction pointer in context

Stack contents:
 0000004a0e6ff6e0 d0 8f d8 2a 0d 02 00 00 5b 1e c9 db fc 7f 00 00  Ð.Ø*....[.ÉÛü...
Possible instruction pointers:

Crash reason: EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0xffffffffffffffff
Process uptime: 12 seconds

Thread 0 (crashed)
0 lib-menus.dll + 0x1dfd9
rax = 0x00007ff8772eab50 rdx = 0x0000000000000001
rcx = 0x000002a30d0707c0 rbx = 0x000002a30dfb60c0
rsi = 0x000002a30d0707c0 rdi = 0x000002a30dfb7640
rbp = 0x000000e48d98f5e0 rsp = 0x000000e48d98f270
r8 = 0x000002a30a9b6e40 r9 = 0x0000000000000001
r10 = 0x0000000000008000 r11 = 0x000000e48d98f290
r12 = 0x000002a30e2e05e8 r13 = 0x0000000000000000
r14 = 0x000002a30a86fa50 r15 = 0x000002a30df7d6b0
rip = 0x00007ff877f2dfd9
Found by: given as instruction pointer in context

Stack contents:
 000000e48d98f270 28 02 2e 0e a3 02 00 00 00 00 00 00 00 00 00 00  (...£...........
 000000e48d98f280 51 f5 2c d8 aa 4f 00 00 63 44 80 77 f8 7f 00 00  Qõ,تO..cD.wø...
Possible instruction pointers:

Crash reason: EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x10
Process uptime: 9 seconds

Thread 0 (crashed)
0 audacity.exe + 0xf03d6
rax = 0x0000000000000000 rdx = 0x0000008814d8ef00
rcx = 0x0000008814d8ef20 rbx = 0x0000008814d8ef20
rsi = 0x0000008814d8ef20 rdi = 0x0000008814d8eed8
rbp = 0x0000000000000000 rsp = 0x0000008814d8edc0
r8 = 0x0000000000000000 r9 = 0x000002751e338d90
r10 = 0x0000000000000014 r11 = 0x0000008814d8f1d0
r12 = 0x0000000000000000 r13 = 0x00007ffd281a35f0
r14 = 0x0000000000000000 r15 = 0x000002751d298b70
rip = 0x00007ff7987503d6
Found by: given as instruction pointer in context

Stack contents:
 0000008814d8edc0 b7 00 00 00 88 00 00 00 00 00 00 00 00 00 00 00  ·...............
 0000008814d8edd0 00 67 d7 76 00 00 00 00 70 51 5e 1e 75 02 00 00  .g×v....pQ^.u...
 0000008814d8ede0 d8 ee d8 14 88 00 00 00 83 a1 74 98 f7 7f 00 00  ØîØ.....ƒ¡t.÷...
Possible instruction pointers:


BTW, some of those crashes corrupt Audacity config file (audacity.cfg). Before I’ve added a workaround to Python script (to copy a backed up version over regular one each time before Audacity is started), I was getting the “welcome” screen that asks me to accept some things and continue.

I can upload the dump files if those can be useful, and I’ll gladly test any code with possible fixes.

As-is, Audacity is meant to be a GUI program. I think. Someone will correct me if I am wrong.

To use Audacity as a pipe source or destination you would need to custom compile it as a headless service, along with all the code changes necessary to make that work.

There seems to be other posts from the past where people have managed to get Audacity and Python to play nice. Since your 4000+ files are MP3 files, and not Audacity project files, could you expand on what you mean by ‘cleaning up’? Can you accomplish what you need using Python alone?
Is there anything in this post that might be helpful?

Well, Audacity has the pipe interface and macros, so you can do repetitive tasks without straining your fingers and orders of magnitude faster.

Yeah, I’m having exactly the same issue, but it’s not a showstopper. The main problem is that the error report windows stick around until manually closed, therefore after several hundred files processed the system resources get exhausted and eventually the Python process crashes. It is intended to run unattended, mostly overnight. The constant popping up of the Audacity window is extremely disruptive, therefore I run this when I don’t use my computer. The Python does roughly this:

  1. Loads MP3 file and saves the ID3 tags contents, including images.
  2. Launches Audacity
  3. Imports the MP3 file
  4. Executes the macro (“standardizes” the silence lengths at the beginning and the end, normalizes volume, etc.)
  5. Exports file as WAV
  6. Closes Audacity (this is when the crash happens after Exit: command is sent)
  7. Encodes WAV files as MP3 using LAME
  8. Restores ID3 tags.

And the process repeats for the next file. All works fine, except step #6 where there is a crash for no reason. I’ve been forced to program into Python scripts a lot of workarounds to deal with the Audacity issues that stem from the crashes. I delete the project files, session files, restore config file each time before Audacity is started. All of that took care of the issues that would need a manual intervention, but still the accumulation of the crash windows is the problem that can’t be dealt from Python.

If I get Audacity build with debug information, then I can have a test run to see the function names that crash and the whole call stack. My C knowledge is extremely rusty and so is my debugging experience, also coming from a completely different platform. I’m not volunteering to debug the code, but I can offer my assistance. I’m going on vacation for 2 weeks this weekend, so I’ll not be able to respond in time.