Audacity 2.1.1 crashes on OSX 10.8.5

Operation System: OSX 10.8.5

Audacity 2.0.6 was running flawlessly so far.

What I did now:

Logged in to my admin account.
Downloaded the Audacity 2.1.1 disk image.
Renamed the existing /Applications/Audacity to /Applications/Audacity206
Dragged the new version from the disk image to /Applications.
Started the new version once successfully. (“Gatekeeper” is disabled.)

Logged in to my user (non admin) account, started Audacity 2.1.1…

… and the program would crash immediately.

The “console” says:
17.07.15 14:02:13,858 com.apple.launchd.peruser.502[125]: ([0x0-0x13c13c].net.sourceforge.audacity[1302]) Exited with code: 255

I can still run the old version (2.0.6) from the renamed folder.
I can still start the new version (2.1.1.) when I’m using admin account.

Permissions of the old and the new version of the Audacity folder and the application seem to be identical, i.e., every user has read access, and only my admin acount has write access, too.

What’s wrong here? Ho can I fix it? Thank you in advance for any help!

It is not a good idea to disable Gatekeeper permanently (if you did that). You should only disable it temporarily if you cannot otherwise get an app to open.

Have you tried Go > Utilities > Disk Utility > then “Verify Disk” and “Repair Permissions”?

If the problem persists after that, please check at ~/Library/Logs/DiagnosticReports/ if there is a more detailed Audacity crash report. You can also find those reports by navigating down the tree in the Console.


Gale

I’ve disabled it only temporarily, so as to make sure it does not interfere with the actual problem.

Have you tried Go > Utilities > Disk Utility > then “Verify Disk” and “Repair Permissions”?

No I didn’t, but I have tried something else in the meantime: I’ve removed (actually: renamed) the directory where Audacity stores its settings: ~/Library/Application Support/audacity. Result: v2.1.1 doesn’t crash any more!

Strange: When alternating between v2.1.1 and v2.0.6, the settings for the locations of the Lame and ffmpeg libs are not recognized mutually…

Thanks for letting us know.

Audacity would still be writing its configuration files there, so that could mean that for some reason it could not do so before.

If LAME is not somewhere that Audacity automatically detects it, effectively deleting the Audacity settings directory will require you to relocate LAME, and you will have to relocate FFmpeg.

And if you do have underlying permissions issues, putting LAME or FFmpeg in system locations could cause flaky detection of those libraries.

I would be inclined to verify disk and repair permissions in any case.


Gale

I’d rather suspect that v2.0.6 had written something that the new version did not like…

If LAME is not somewhere that Audacity automatically detects it, effectively deleting the Audacity settings directory will require you to relocate LAME, and you will have to relocate FFmpeg.

You were misunderstanding me!

  1. I deleted the settings directory, which had been generated by v2.0.6.
  2. Started up v2.1.1, and entered the locations for the Lame and ffmgep libraries manually.
  3. Closed 2.2.1
  4. Started the old 2.0.6, which complained about missing libraries, now.
  5. Entered, again, the right places where Lame and ffmpeg reside. Closed 2.0.6
  6. Started 2.1.1, which would now no longer find the libraries.

Btw, the “old” seettings directory did have the correct permissions ; otherwise the previous Audacity version would have crashed, too! And the libraries are in the same places as before.

Something very similar happened when I was rummaging around with the latest RC and 2.1.0.

Audacity didn’t crash, but prefs didn’t stick until I deleted the map let Audacity recreate prefs and saved them in both versions. Previous prefs file dated back to 2.0.6.

Sorry, don’t remember much more as I was chasing something else at the time.

You didn’t double click and run the disk image (.dmg), did you? I’m betting you didn’t actually install Audacity. It might run, but it will be completely lost without the install.

Koz

Have you done Verify Disk and Repair Permissions yet? It does not matter what GetInfo says if your permissions are messed up.

Gale

But it was still liked when you were admin, presumably?

There is always a chance of corruption of some sort in audacity.cfg, where deleting that file will fix the problem. But such a problem rarely varies according to a user’s permissions at the time.

Where are those places? If either are in /usr/local, that location is very susceptible to permissions problems.

I can’t test anything without knowing where those places are.


Gale

Were these preferences for LAME and FFmpeg or other settings?

I toggle between different versions of Audacity a lot (as admin). The only problem I recall is if I go back from 2.0.6 or 2.1.x to Audacity 2.0.5, 2.0.5 won’t start first time because of incompatible FFmpeg libraries (2.0.5 requires an older FFmpeg 0.6.2).

But that is a problem in 2.0.5 only.


Gale

That only verifies and repairs some system permissions. Doesn’t do a thing for user owned data…

Yes - but against that, if the problem was that FFmpeg or LAME are in /usr/local and Mac is blocking read access to that location unless logged in as admin, we know from past experience that repairing permissions can fix that.

And if permissions are messed up, expected behaviour when logged in as standard user or expected behaviour when a folder has a specific permission set may not obtain any longer. Don’t you agree? I have certainly had problems like that on Mac several times.

Given this other user Audacity 2.1.1 and OS X 10.10.4 also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.

If you find steps to reproduce your (Cyrano’s) issues when switching between Audacity versions, please post the steps.


Gale

In my case the libraries were (and stll are) unter /Library/Application Support/audacity/

OK. That’s still a system location of course, but it is from our experience much less problematic than /usr/local.

Gale

It’s an almost religious thing in the OSX community that fortunately doesn’t do any harm. You can repair users’ home folders, but only after a restart into the recovery partition. See here for a bit more:

Running it from “normal” OSX, only repairs things like the kernel extension folder. I’ve only seen that to fix anything in 3 cases: one was a misbehaving kernel extension from a copy protection software, the other two were corporate management tools. In the last two cases, the Mac didn’t even start and repairing permissions enabled a startup again - once. And that was in the period from Snow to today.

In “El Capitan”, the button “repair permissions” is gone from Disk Utility.

And if permissions are messed up, expected behaviour when logged in as standard user or expected behaviour when a folder has a specific permission set may not obtain any longer. Don’t you agree? I have certainly had problems like that on Mac several times.

Frankly, it’s a complete mystery why it seems to solve something for some problems some of the time. I suspect flushing cashes has something to do with it. According to logic and the docs, it shouldn’t do anything. But usually, users also try a restart. And I believe changing permissions AND restarting will clear some caches.

Given this other user > Audacity 2.1.1 and OS X 10.10.4 > also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.

If you find steps to reproduce your (Cyrano’s) issues when switching between Audacity versions, please post the steps.

Remember I had the issue before, because I didn’t understand I needed to delete .cfg and not simply restart Audacity?

I also had 2.0.6 on my Mac before I installed 2.1.0. And when I upgraded to 2.1.1 it didn’t catch all prefs from the 2.1.0. I still have 2.1.0 installed and setting for default window behaviour (Waveform (dB) and range 0…120 dB) didn’t stick until I reaffirmed and saved in both versions of Audacity.

The Audacity settings in my admin account were totally different from those in the user account. I suppose that I had run the old version 2.0.6 maybe once from that account, immediately after the installation, just to make sure whether the program was working.

PS:
I have attached the latest audacity.cfg that was still written by v2.0.6 and that I could find on my backup disk. Until the moment where I installed v2.1.1, only export and import paths may have been changed. Except for theses paths, this must be the cfg file that made v2.1.1 crash.
audacity.cfg.txt (5.33 KB)

Again, many (not all) of the problems I have in mind are to do with LAME and FFmpeg installed to /usr/local/ - a problem that started with Lion.

Thanks for that, Cyrano.

Sometimes the Repair Permissions without restart has enabled users to read /usr/local/ again. Other times they had to go in as root to change permissions on that folder or just not use it for LAME or FFmpeg.

And yes sometimes Repair Permissions can “seemingly” fix issues with ~/Library/Application Support/audacity/ (with or without restart and without changing audacity.cfg).

I was recently able to get two instances of Audacity running on Mac from two audacity.cfg’s pointing to the same temp folder - it should have been impossible, but Repair Permissions stopped the problem.

Another problem Repair Permissions fixed without reboot was Audacity apparently reading the audacity.cfg in ~/Library/Application Support/audacity/ when I had audacity.cfg in a Portable Settings folder alongside Audacity which should have been read instead.

So I don’t know… but I can only speculate that system permissions issues were somehow messing up how unchanged user owned file permissions were being read. Repair Permissions is just one thing to try, and a real repair of user owned file permissions that you mentioned looks like another.

OK that’s useful. Did you ever have Audacity 1.2? One thing I noticed in the audacity.cfg for DJDemon and the other user from 2.0.6 was that the temp folder was that which 1.2 used.


Gale

OK - until you said that I was assuming they would be the same (or nearly so) and thus the different permission level behaviour seemed more pertinent.

Thanks for the audacity.cfg file.


Gale

But that sounds like an Audacity bug to me?

So I don’t know… but I can only speculate that system permissions issues were somehow messing up how unchanged user owned file permissions were being read. Repair Permissions is just one thing to try, and a real repair of user owned file permissions that you mentioned looks like another.

It probably also starts a number of maintenance tasks…

It’s a big, big problem that Apple either does not have docs, or hides them in the developer site. That makes a search very ineffective. And the appstore is even worse when it comes to documentation/support.

And in “EL Capitan”, some permissions can’t be changed by root, because OSX is rootless. You can still enable root (or switch OFF rootless, in Apple speak), but then still, you’re not master of your machine. It seems root is no longer able to delete some stuff in the system area. A good thing to protect the system from noob users, but I’m waiting for malware to pick up the trick.

Oh, well, all systems seem to hide more and more stuff from the user. Are we all noobs? Or do they need to hide something from us?

Given this other user > Audacity 2.1.1 and OS X 10.10.4 > also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.

It seems susceptible to what settings are in the prefs, I think. I tried to retrace (and reinstall 2.0.6) but it didn’t produce the same behaviour…

I also had 2.0.6 on my Mac before I installed 2.1.0. And when I upgraded to 2.1.1 it didn’t catch all prefs from the 2.1.0. I still have 2.1.0 installed and setting for default window behaviour (Waveform (dB) and range 0…120 dB) didn’t stick until I reaffirmed and saved in both versions of Audacity.

OK that’s useful. Did you ever have Audacity 1.2? One thing I noticed in the audacity.cfg for DJDemon and the other user from 2.0.6 was that the temp folder was that which 1.2 used.[/quote]

FWIW, I never had these older Audacity versions on this Mac. I can still remember using 2.0.5, but nothing older and certainly not that far back.

i’m pretty certain I have only one .cfg on this Mac, depite having two Audacity versions. Maybe I need to make a portable install. Do you think that may yield some insight?

Right. Both v2.0.x and v2.1.1 are using the same path and file names to store the settings. IIRC, these were already used by v1.x.