[OS X 10.9] dyld: Symbol not found: _pthread_chdir_np

[RJVB]

FF Dynasty 132.0 seemed to work fine for me in quick testing, so I set it up to run on a clone of the profile I use in Waterfox (G3.2.7-osxfix-eol).

It starts up OK, opening all the windows it should that even look like they do in Waterfox, but then it hangs after I've just been able to cancel the "make default browser" invitation. Launching from a terminal I see

> /path/to/FFDynasty-1320/Firefox.app/Contents/MacOS/firefox
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
2024-10-28 00:02:51.466 firefox[11376:10d03] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.
2024-10-28 00:02:51.467 firefox[11376:10d03] CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
[GFX1]: NextSurface returning false because of invalid mSize (0, 0).
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
console.error: "attribute_timeout: attachedFxAOAuthClients"
console.error: (new Error("attachedFxAOAuthClients targeting getter timed out after 5000ms", "resource://messaging-system/targeting/Targeting.sys.mjs", 139))
JavaScript warning: moz-extension://a4d71339-e05c-a94f-84ab-921ad5ea5077/js/Driver/Bookmarks.js, line 1642: unreachable code after return statement
dyld: lazy symbol binding failed: Symbol not found: _pthread_chdir_np
  Referenced from: /path/to/FFDynasty-1320/Firefox.app/Contents/MacOS/XUL
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _pthread_chdir_np
  Referenced from: /path/to/FFDynasty-1320/Firefox.app/Contents/MacOS/XUL
  Expected in: /usr/lib/libSystem.B.dylib

_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

It seems quite likely that the attempted use of pthread_chdir_np() is the culprit here; they appear just before the beachball A bit strange that FF wouldn't be prepared to handle XUL crashes though...

[RJVB]

FWIW, re: pthread_[f]chdir_np():

the Chromium source indicates that this concept exists since 10.5, but you have to use the syscall directly.

[RJVB]

It looks like the issue can be triggered by installing the "Video DownloadHelper" extension in a fresh profile:

https://addons.mozilla.org/en-US/firefox/addon/video-downloadhelper/

[Wowfunhappy]

It looks like the issue can be triggered by installing the "Video DownloadHelper" extension in a fresh profile:

Do I need to do anything with the addon once installed? I installed it but my Firefox is still working.

[RJVB]

Do I need to do anything with the addon once installed? I installed it but my Firefox is still working.

I didn't have to do anything, I just started with a new profile and only added the extension. What OS version did you try this on? The extension does have a helper application which I should have installed; I could try to move the copy out of the way and reinstall the extension to see if that makes a difference. The pthread_chdir_np function is available "as is" from 10.12 upwards. Anyway this is an extension I use and IMHO it's not an issue in that extension but in the XUL library which can call a function that doesn't exist. If the extension can trigger that call (a priori via javascript) then a site could do it too and since the functionality is available via a syscall I would argue that there is no excuse not to fix that. FWIW: I have a simple wrapper around the `dlsym(2)` function and if I use that to load the XUL library (with `DYLD_LIBRARY_PATH` set to `/path/to/XUL`) I get an error about another missing function (in the `clock_gettime` family). https://github.com/RJVB/legacy-tools/blob/master/dlsym.c

[Wowfunhappy]

I didn't have to do anything, I just started with a new profile and only added the extension. What OS version did you try this on?

10.9. It looks like the helper application needs Mojave, do you have an older version?

If the extension can trigger that call (a priori via javascript) then a site could do it too and since the functionality is available via a syscall I would argue that there is no excuse not to fix that.

I completely agree, I was just stating that I can't personally trigger it in the way you suggested.

I get an error about another missing function (in the clock_gettime family).

That should be trivially fixable with MacPorts Legacy Support, right?

[RJVB]

10.9. It looks like the helper application needs Mojave, do you have an older version?

Yes, I built a version myself, apparently long ago already. So I cannot exclude that the issue at hand is triggered by having an outdated version installed, but I can confirm that putting the helper app in the Trash helps prevent the issue. Putting it back will then trigger the issue as soon as the extension checks for it. I actually tested this in a profile that I had created to see if I could trigger the issue by connecting to my FF profile and fetching my settings, bookmarks etc. I had disabled the Video DownloadHelper addon which had apparently blocked syncing; it resumed as soon as I re-enabled the addon. It really seems to be only Video DownloadHelper that currently exposes the unresolvable symbol, but:

I completely agree, I was just stating that I can't personally trigger it in the way you suggested.

So the observation above suggests that it's indeed the extension that tries to do a thread-specific chdir (or that attempts an operation for which FF will use pthread_chdir_np) - possibly a chdir into the helper app's directory. That confirms my hunch that other extensions or sites might do this too.

> I get an error about another missing function (in the `clock_gettime` family). That should be trivially fixable with MacPorts Legacy Support, right?

```

env DYLD_LIBRARY_PATH=./FFDynasty-1320/Firefox.app/Contents/MacOS dlsym ./FFDynasty-1320/Firefox.app/Contents/MacOS/XUL

dlsym: can't open ./FFDynasty-1320/Firefox.app/Contents/MacOS/XUL (dlopen(./FFDynasty-1320/Firefox.app/Contents/MacOS/XUL, 6): Symbol not found: _clock_gettime_nsec_np Referenced from: ./FFDynasty-1320/Firefox.app/Contents/MacOS/XUL Expected in: /usr/lib/libSystem.B.dylib in ./FFDynasty-1320/Firefox.app/Contents/MacOS/XUL) Exit 1 ``` Sadly the function in question is not in Legacy-Support (but judging from the name it should be simple enough to emulate). It's a pity that I no of no way to get the full list of unresolvable symbols; who knows how many more there are!

[RJVB]

In ipc/chromium/src/base/process_util_mac.mm:26 :

extern "C" {
// N.B. the syscalls are available back to 10.5, but the C wrappers
// only in 10.12.  Fortunately, 10.15 is our current baseline.
int pthread_chdir_np(const char* dir) API_AVAILABLE(macosx(10.12));
int pthread_fchdir_np(int fd) API_AVAILABLE(macosx(10.12));

And from syscall.h:

#define   SYS___pthread_chdir 348
#define   SYS___pthread_fchdir 349

The (missing) C calls are just wrappers; it should be possible to replace the declarations at line 26 with actual definitions:

int pthread_chdir_np(const char* dir)
{
    return syscall(SYS___pthread_chdir, dir);
}

int pthread_fchdir_np(int fd)
{
    return syscall(SYS___pthread_fchdir, fd);
}

Patch:
pthread_chdir.diff

While we're at it:
third_party/rust/zeitstempel/src/mac.rs:31:

extern "C" {
    fn clock_gettime_nsec_np(clock_id: clockid_t) -> u64;
}

mozglue/misc/Uptime.cpp:77:

Maybe<uint64_t> NowExcludingSuspendMs() {
#if !defined(MAC_OS_VERSION_10_12) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_10_12
  struct timespec ts = {0};
  return Some(clock_gettime_missing(CLOCK_UPTIME_RAW, &ts)/ kNSperMS);
#else
  return Some(clock_gettime_nsec_np(CLOCK_UPTIME_RAW) / kNSperMS);
#endif
}

Maybe<uint64_t> NowIncludingSuspendMs() {
#if !defined(MAC_OS_VERSION_10_12) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_10_12
  struct timespec ts = {0};
  return Some(clock_gettime_missing(CLOCK_MONOTONIC_RAW, &ts)/ kNSperMS);
#else 
  return Some(clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW) / kNSperMS);
#endif
}  

mozglue/misc/AwakeTimeStamp.cpp:115:

AwakeTimeStamp AwakeTimeStamp::Now() {
#if !defined(MAC_OS_VERSION_10_12) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_10_12
    struct timespec tv;
    return AwakeTimeStamp(clock_gettime_missing(CLOCK_UPTIME_RAW, &tv)/ kNSperUS);
#else
    return AwakeTimeStamp(clock_gettime_nsec_np(CLOCK_UPTIME_RAW) / kNSperUS);
#endif 
} 
AwakeTimeStamp AwakeTimeStamp::NowLoRes() { return Now(); }

The reference to clock_gettime_nsec_np must come from the Rust file which has what seems to be a runtime detection of its availability. The two C++ files should build in a call to replacement functionality.

[RJVB]

Hoping the attached patch will help speed up fixing this issue!

[RJVB]

On Tuesday October 29 2024 15:15:28 Jonathan wrote: That should be trivially fixable with MacPorts Legacy Support, right?

Looks like we're going to have to get those symbols into that library (or fork it) ourselves if we want this (a priori trivial) issue resolved anytime soon! How about you write a dynasty-updating prefpane (I presume there's no updating functionality in FF Dynasty anyways)? ;)

[Wowfunhappy]

How about you write a dynasty-updating prefpane (I presume there's no updating functionality in FF Dynasty anyways)? ;)

I am planning on it, but it might take a while. I want to start on a stronger foundation this time so the codebase doesn't get out of control. I also have quite a few tweaks I want to apply on top, such as this code for fixing key equivalents. I'm working on extending that to add additional items to the menu such as "reload page", and then I want to make use of Firefox's theming support to make this look like a proper Aqua app.

[RJVB]

Sounds good, but you want to use Firefox for the looks of what exactly?

[Wowfunhappy]

Oops, I want to make Firefox look like a proper Aqua app. The toolbar should have the correct gradient and so on.

[RJVB]

Oops, I want to make _Firefox_ look like a proper Aqua app. The toolbar should have the correct gradient and so on.

Well, as long as you do that with regular themes you're welcome to :) I don't miss that gradient but rather appreciate how the combined title+tab bar and just the address bar are about as compact as can be.

[krackers]

Firefox look like a proper Aqua app. The toolbar should have the correct gradient and so on.

Back in the FF78 days I had a theme which does this. I can share with you, don't know how much of FF has changed since then. Developing firefox themes is a pain. Everything about firefox is jank, I can't believe this is supposed to be the browser by and for developers. You can't even have an unpacked extension loaded for more than 24 hrs.