dyld: Symbol not found: _abort_report_np when dyld lazy symbol binding is disabled.

[Wowfunhappy]

I discovered something interesting. It might be absolutely nothing, but it also might also be the cause of random crashes or other glitches, I'm not sure.

While reading dyld's man page today, I noticed an interesting environment variable:

DYLD_BIND_AT_LAUNCH
              When this is set, the dynamic linker binds all undefined symbols
              the program needs at launch time. This includes function symbols
              that can are normally lazily bound at the time  of  their  first
              call.

This seemed like a good way to test apps for missing symbols, which they would not normally try to access immediately but would later in execution. (cc @RJVB on the above you might find this useful in general.)

I tried launching Chromium Legacy with this environment variable set:

$ DYLD_BIND_AT_LAUNCH=1 /Applications/Chromium.app/Contents/MacOS/Chromium 
dyld: Symbol not found: _abort_report_np
  Referenced from: /Applications/Chromium.app/Contents/MacOS/Chromium
  Expected in: /usr/lib/libSystem.B.dylib
 in /Applications/Chromium.app/Contents/MacOS/Chromium
Trace/BPT trap: 5

Chromium Legacy crashed due to an undefined symbol, _abort_report_np.

---

The question is, In real world use when lazy symbol binding is not explicitly disabled, does Chromium ever call this function? I've never noticed this symbol in a crash log.

In addition, I tried running Chromium with a stubbed version of the function (void abort_report_np() {}) and while this allowed Chromium to launch when DYLD_BIND_AT_LAUNCH=1, I did not otherwise notice any differences. #185, #94, and #75 still occur.

As I said at the jump, I have no idea if this is a real problem, but I wanted to document the finding, especially in case it's easy to proactively fix.

[RJVB]

On Thursday November 14 2024 07:47:15 Jonathan wrote: DYLD_BIND_AT_LAUNCH

[...]

This seemed like a good way to test apps for missing symbols, which they would not normally try to access immediately but would later in execution. (cc @RJVB on the above you might find this useful in general.)

I think this is more or less equivalent to passing `RTLD_NOW` to `dlopen(2)`, which is what my `dlsym` utility does. Remember the discussion about the `clock_gettime_nssec_np` function referenced by Firefox's XUL library? That's one of those symbols that gets resolved only when it's called the 1st time, and can be missing when the code never invokes it. That's how Apple's ***@***.***` can work; it's a true runtime #ifdef, except that it doesn't offer a safety net at all.

The question is, In real world use when lazy symbol binding is not explicitly disabled, does Chromium ever call this function? I've never noticed this symbol in a crash log.

It does, but it's supposed to be a variant of the old `abort(2)` function that is a bit more informative to the user. So it gets called when Chromium crashes deliberately. And it this case it'll probably still crash if the symbol isn't available (though we've seen with Firefox that it could also freeze if the crash happens in a sub-process). R

[Wowfunhappy]

Remember the discussion about the clock_gettime_nssec_np function referenced by Firefox's XUL library?

That's why I tagged you. It works to trigger that.

So it gets called when Chromium crashes deliberately.

Ah, okay, so probably not leading to problems in use. (I did try searching the symbol on Google but didn't find anything useful.) Thank you. I'm actually going to close this issue in that case. It would still be nice to fix and Bluebox can open the issue again if he really wants to, but it feels to me like there are much higher priority bugs than "Chromium crashes when it intentionally crashed."