What could I have done to Firefox?

kc9udx

I have firefox102 installed (under NetBSD 9.3) on multiple machines. I use it regularly on my Pinebook Pro (aarch64). The other day I logged into my account (same account, same home directory (nis/NFS)) on an amd64 based server, via X forwarding, from my Pinebook Pro.

Since then, I can no longer use Firefox directly on my Pinebook Pro. It will start up but then lock up and eventually core dump. What could cause this?

Jay

kc9udx
Try launching Firefox with a clean profile on your Pinebook Pro to see if the issue persists. You can do this by running:
firefox102 -P
This will open the Firefox Profile Manager, where you can create a new profile to test if the problem is related to your existing profile.

push

If you run ff over ssh, it is running on remote machine (your amd machine).
It has nothing with ff on local (pinebook) machine.
Something else is wrong. I would try running it on other account, to check
installation. Reinstall as need it. If it is OK, delete ff local cache.

kc9udx

It runs fine on the amd64 machine, every time (over ssh).

When I run it locally, since then, that's the crash. Prior to running it on the other machine (with the same account) it ran fine.

I haven't tried running from another account yet; I'll try that.

I should clarify, that it must affect running it on the local machine: Both machines use the same home directory (on the NFS server). But I don't know what the one machine does that makes the other crash.

Jay

kc9udx If the issue persists, you might want to check for any relevant error messages in the terminal where you launched Firefox. Additionally, reviewing the Firefox logs or system logs on both the Pinebook Pro and the amd64 server may provide insights into what's causing the lockup and core dump.

rvp

kc9udx To add to what @Jay suggested (using a different profile), you could also go into about:support and Clear startup cache and, if that doesn't work, Refresh Firefox.

The one difference I can think of between the local/remote cases is related to the OpenGL accelerated graphics. When runlocally, Firefox (presumably) gets an accelerated X server; when run remotely it does not, and so the ~/.cache/mesa_shader_cache/* files probably will be different. And, maybe mixing these is what's causing your crash?

kc9udx

I tried a different (non-nis/non-nfs local) user on the Pinebook Pro. I was able to (only) start Firefox with -P —safe-mode and create a new profile, one time. The default profile did not work. But probably I haven't run Firefox as that user with this version of Firefox. I do not know why this only worked one time; but I recall having this problem after first installing Firefox on this machine. I don't recall how I fixed it.

I didn't get a chance to try anything else out as the normal (nis/NFS) user. There must be something in the home directory of that user which causes this problem; there was nothing else done to the Pinebook Pro at the time the problem appeared. I had just finished building Firefox on the amd64 machine and wanted to try it out.

Hopefully tomorrow I can try other things.

rvp

kc9udx So if I have this right, you have a shared home dir. and you want both the amd64 and arm64 versions to use the same dir. Hmm. I'm not sure if this is wise. Even if the FF versions were the same, they could write all sorts of arch-dependent crud in ~/.mozilla and ~/.cache/. Is the pinebook pro running in big-endian mode by any chance?

If you want to do this, I suggest you create separate profiles like @jay recommended. That's the thing to do even when you want to run 2 different versions of FF on the same arch.

kc9udx

rvp It's not that I want to do it; although in the past with older Firefox, I did do this all the time, as I've always had a common home directory, and multiple workstations.

The only issue is that by doing this without thinking about it, I wrecked a working profile. For some reason it isn't easy getting a working profile on aarch64.

How can I know which endian I'm using?

rvp

kc9udx How can I know which endian I'm using?

One way is:

gcc -E -dM - < /dev/null | fgrep -i end

Another is:

#include <stdio.h>

int main(void) {
	union {
		unsigned char c[4];
		unsigned int i;
	} u;
	u.i = 0x12345678;
	printf("%02x %02x %02x %02x\n", u.c[0], u.c[1], u.c[2], u.c[3]);
	if      (u.c[0] == 0x78 && u.c[3] == 0x12)
		printf("Little-endian\n");
	else if (u.c[0] == 0x12 && u.c[3] == 0x78)
		printf("Big-endian\n");
	else
		printf("PDP-11?\n");
	return 0;
}

Non-portable, but, WTH...

kc9udx

As I am rebuilding firefox102; I durst not try the latter. The former nets

#define __ORDER_LITTLE_ENDIAN__ 1234

...

#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__

does this indicate little endian?

rvp

kc9udx does this indicate little endian?

Yes...but, I was being too clever. A simpler method in your case would've been just:

uname -p

and for the binary itself:

readelf -h /usr/pkg/bin/firefox

(On some platforms one can set the endian-ness per binary--dunno if ARM is one of these.)

kc9udx

rvp uname -p nets only "aarch64"

I don't really know either. I've never really got my hands into anything that wasn't little- or pdp- endian.

Firefox is no longer there, but everything else I check is little endian.

rvp

kc9udx uname -p nets only "aarch64"

That's little-endian. Big-endian would've been aarch64eb.

kc9udx Freshly installed /usr/pkg/bin/firefox102 says "Failed to read file header"

Wha...? Is readelf producing that error? What does an ls -l /usr/pkg/bin/firefox102 show?

kc9udx

Freshly installed /usr/pkg/bin/firefox102 says "Failed to read file header"

kc9udx

rvp yes. It turns out it is a short script that runs /usr/pkg/lib/firefox102/firefox102 which nets "2's complement, little endian"

kc9udx

I spent a month installing and reinstalling the entire system and building and rebuilding every pkgsrc package I have, trying to figure out what causes this problem. The root cause of the problem is nsswitch.conf:
hosts: files dns nis
causes the problem to never happen.
hosts: files nis dns
causes Firefox to operate is some way that causes the problem. Not immediately, and not always. There is something that happens whilst using Firefox that triggers the problem when nsswitch.conf is configured that way. I don't understand it: I ran with the wrong configuration this time around for a very long time before it became an issue.
I don't know when Firefox first started behaving this way. That is, which version. Because certainly I had been using the "wrong" nsswitch.conf configuration for decades in NetBSD and Solaris; and never encountered this problem until the last few years.

rvp

kc9udx The root cause of the problem is nsswitch.conf

Bizarre!