From Audacity Wiki
Jump to: navigation, search

Summary Points

Our code does 'clever' things with DYLD_LIBRARY_PATH and execv. So (apparently) does Apple's Gatekeeper and dl-loader. Between the two we may have a race condition that leads to these libraries not being found, and possibly the wrong version of a wxWidgets library being found - and a crash in that case.

The Bug Cluster

IDPStatusSummary (4 tasks) ID
1702P2RESOLVEDMac: Summary: LAME, FFmpeg and other dll loading woes.1702
290P2RESOLVEDMac: LAME: Audacity looks for LAME in a restricted folder that Mac no longer supports290
1567P2RESOLVEDMac Sierra: LAME, FFmpeg and some plugins disappear. (intermittent)1567
543P4RESOLVEDMac: "Kind" information not sufficiently visible.543

History (Brief)

  • (version 1.3.14) We packaged the executable with a shell script to change environment before invoking Audacity, just so that certain libraries -- which are not loaded until AFTER startup -- would be located correctly by the dynamic loader. (Bug 290)
  • (version 2.0.6) To mitigate a very minor downside of the script, not the binary, being the click target in the bundle (bug 543), we got rid of the script, but make Audacity do an execve shortly after starting, a measure which now seems very suspect.
  • (version 2.1.3) Possibly as a consequence of that, we got the intermittent bug 1567, only on the newest version of macOS (Sierra), which held up 2.1.3. To fix it sometimes, we compounded the strangeness of the execve with a fork and crash too, and some other work to cleanup .DS_STORE files. We don't fix bug 1567 to our complete satisfaction, but ship 2.1.3 as good enough.
  • (version 2.2.0) We observe other weird behavior on Sierra: small changes in size of the executable cause wxWidgets libraries to load from the wrong place at startup; double-click on .aup brings up empty project window.
    • Peter 03Aug17: the latter was bug #1703 which was fixed and now marked resolved quickfixed.

History (Detail)

Old Proposal (Paul)

My suggestions for the present:

1 Do away with the strange fork, crash, and execve, which I suspect are the unusual things in our program that cause various griefs on macOs Sierra.

2 The loading of LAME and FFmpeg libraries happen AFTER startup, not during. So we should be able to change the environment variables that influence that while Audacity runs, not necessarily before. So there was no need for either the execve or the shell script that existed before that.

Paul: Experiment shows this doesn't work. The environment variable really must be set before the Audacity process is spawned.

3 Perhaps do away with .DS_STORE cleanup if it isn't needed either. Re-verify bugs 290, 543, and 1567 if we can. (But they may be reports on obsolete OS versions, or intermittent, so verification is difficult.)

Now I think number 2 seems obvious, but in comment 15 of bug 290 Leland mentioned "runtime updates" of environment variables as being available on Windows -- as if they aren't on macOS ?? Or if they are, dyld ignores them?

Paul: I think he meant to say, updates just to this variable are ignored by dyld.

Comments (James)

  • +1 to 1 and 2.
  • We could/should also add something so we log env variables that are involved in loading so we know if them changing is causing a problem.

Resolution (Paul)

After I wrote the above, I decided differently.

I reverted to the original fix for bug 290, as of https://github.com/audacity/audacity/commit/dba49dd485d718a7ce5e42cf1cf4a7990d2e6a59

The fix removes the execve funny business, and instead makes a tiny script, Audacity.sh, as part of the bundle, which changes the environment and invokes Audacity. I know GIMP at least is one other program doing the same trick, as you can see by exploring its package.

This reopens Bug 543, but I decided to resolve that as won't fix. (It might be fixed if the shell program is rewritten as a C program. Not worth the effort.) I now think the fix for 543 was the cause of all the other grief.

As for Bug 1567, it may be impossible to test now. It happened only to a few users, according to rumors at the forum, and only to Gale among team members. Even he saw the symptom only with dozens of rapid starts and exits of Audacity. I am inclined, though, to take the fix of 1703 as circumstantial evidence, that removing the funny business cures a variety of unintended side effects at process startup. So let's mark this bug not reproducible and simpy wait for reports of recurrence.

This said, I am still puzzled by DYLD_LIBRARY_PATH. Apparently SIP (System Integrity Protection) since El Capitan includes very special treatment of this environment variable. Experiments with interactive sh show that the shell quietly refuses to export the changed variable to a sub-shell or other process. And yet experiment also showed that this was not so when Audacity.sh was invoked as part of the bundle.

Did the original Bug290 happen (as the report says, only on some systems) because DYLD_LIBRARY_PATH was somehow set by default (by malicious programs maybe)? Is this just not possible after SIP? Does that make 290 a non-issue on those systems? And yet we are still supporting an earlier minimum macOs version than El Capitan.