Audacity 2.3.1 crash on El Capitan 10.11.6

Audacity 3 Help Forum macOS
1

I’ve been using Audacity for some simple editing. Trimming, normalising, EQ, exporting to MP3 and WAV. Input is 48 kHz, 24 bit. Audacity 2.3.1 on Macos 10.11.6.

As long as I work with one project file, everything is hunky dory.

However, I have four backup channels I need for a couple of tracks. Unfortunately, I forgot to take a note of which track is what and these come from a Soundfield mic. While trying to figure out what the channel order was, I created about eight project files with different channel orders, 4 channels each. I saved and exported two of them without any issues.

Stopped for lunch. Decided to close the projects I didn’t need. The first one closed without error. When saving the second one, the following error came up:

“atos needs to take control of another process for debugging to continue.”

The dialog needed my admin pw to continue, which I provided. It started generating an error report or something. Audacity froze. Couldn’t kill it from Activity monitor. Did a restart.

After the restart, upon opzning Audacity again, there weer four projects listed for repair. When trying to repair, the same error appeared. This time, I cancelled, to be greeted with another error:

“Developer Tools Access needs to take control of another process for debugging to continue. Type your password to allow this.”

A short search revealed nothing in connection with Audacity, or El Capitan. I have Xcode installed and command-line tools enabled, which also appeared in the search.

Any ideas? Or do I still need to take Audacity as a one-project-at-a-time tool?

Crash report from the second session in attachment.
Audacity crash report 2019-05-07.txt (804 KB)

2

Take care if you search for the errors. I usually use Qwant. No problem there. But Google seems to have picked up a few pages trying to inject malware through your browser, pretending to be an annual site survey.

3

Do you need any of the crashed projects that are being offered for recovery?

4

I could recover one. I’ll survive losing the rest. It’s just half a day work. Plenty of backup. Have gone back to one project open, lots of save.

The interruption is the worst thing really, as I lost my train of thoughts :slight_smile:

I’m just wondering what the reason for this error is. A search yielded some problems with Bento (a simple database that was no longer supported under Yosemite), Xcode and a few others. Smelled a bit like a 64-bit app problem.

5

Are you using the official release version of Audacity 2.3.1?

Why is that?

Are you able to reproduce this problem?

6

It seems the only way to install command line tools these days is to install Xcode. I need command line tools for web development stuff like Docker, python… Don’t remember exactly what it was that needed it.

I’ll see if it happens again but that will take a while, as it only seems to happen after a period of inactivity.

Could it be related to the audio interface disconnecting while the Mac sleeps? Every other app seems to handle that fine, but Audacity needs to be restarted to find the audio interface again.

7

Yes it could.

Or you can “Rescan Audio Devices” (Transport Menu - Audacity Manual)

If a device disconnects and then reconnects, it may have a different process ID, so that in effect it is a “new device”. As you are aware, Audacity only looks for devices on launch, and when you specifically tell Audacity to rescan.

8

Thanks, Steve.

That rules out Audacity as recorder in this case. It’s for live use and Macs need to lock between sessions. I can only lock them by invoking the screensaver. So I can’t just set them to “never sleep”. Damn.

Back to Reaper’s complexity, I guess.

I suppose other apps recognise the audio device by name and not process ID?

9

but it shouldn’t cause Audacity to crash. If Audacity (or more specifically, “Portaudio”) can’t communicate with the device, it should throw an error, not crash. You would then be able to Rescan Audio Devices and continue working.

If you can discover step that will predictably cause a crash, please post them so that the issue may be logged for the Audacity developers to fix.

10

I’ll see what I can do. The thing that makes testing it slow, is that it only happens after a while in sleep modus. Not when sleep is just activated.