| 19 Sep 2023 |
 K900 ⚡️ | Even before the crash handler is set up | 14:05:05 |
 nbp | strace says anything? | 14:05:07 |
| K900 ⚡️ | mprotect(0x7f389129c000, 4096, PROT_READ) = 0
mprotect(0x7f389129c000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f389129c000, 4096, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1ed40} --- | 14:05:14 |
| K900 ⚡️ | Looks sus but nothing immediate | 14:05:20 |
| nbp | I know there is a process which checks for GPU support which has been broken since 2/3 releases … | 14:05:38 |
| K900 ⚡️ | #0 0x000000000001ed40 in ?? ()
#1 0x00007f16c2763fae in call_init (env=0x7f16c2023400, argv=0x7ffcba590ae8, argc=1, l=<optimized out>) at dl-init.c:70
#2 call_init (l=<optimized out>, argc=1, argv=0x7ffcba590ae8, env=0x7f16c2023400) at dl-init.c:26
#3 0x00007f16c276409c in _dl_init (main_map=0x7f16c2034e00, argc=1, argv=0x7ffcba590ae8, env=0x7f16c2023400) at dl-init.c:117
#4 0x00007f16c276056e in __GI__dl_catch_exception (exception=exception@entry=0x0, operate=operate@entry=0x7f16c276a810 <call_dl_init>,
args=args@entry=0x7ffcba58c450) at dl-catch.c:211
#5 0x00007f16c276a7b6 in dl_open_worker (a=a@entry=0x7ffcba58c5f0) at dl-open.c:808
#6 0x00007f16c27604e1 in __GI__dl_catch_exception (exception=exception@entry=0x7ffcba58c5d0, operate=operate@entry=0x7f16c276a720 <dl_open_worker>,
args=args@entry=0x7ffcba58c5f0) at dl-catch.c:237
#7 0x00007f16c276ab4c in _dl_open (
file=0x7ffcba58d930 "/nix/store/ymhkgr4r99gjy3c3g5z5ylb6qmr2ka63-firefox-bin-119.0a1/usr/lib/firefox-bin-119.0a1/libnspr4.so",
mode=<optimized out>, caller_dlopen=0x564423812b84 <InitXPCOMGlue(mozilla::LibLoadingStrategy)+1860>, nsid=<optimized out>, argc=1,
argv=0x7ffcba590ae8, env=0x7f16c2023400) at dl-open.c:884
#8 0x00007f16c229bf0c in dlopen_doit (a=a@entry=0x7ffcba58c860) at dlopen.c:56
#9 0x00007f16c27604e1 in __GI__dl_catch_exception (exception=exception@entry=0x7ffcba58c7c0, operate=0x7f16c229beb0 <dlopen_doit>,
args=0x7ffcba58c860) at dl-catch.c:237
#10 0x00007f16c2760603 in _dl_catch_error (objname=0x7ffcba58c818, errstring=0x7ffcba58c820, mallocedp=0x7ffcba58c817, operate=<optimized out>,
args=<optimized out>) at dl-catch.c:256
#11 0x00007f16c229b9df in _dlerror_run (operate=operate@entry=0x7f16c229beb0 <dlopen_doit>, args=args@entry=0x7ffcba58c860) at dlerror.c:138
#12 0x00007f16c229bfc1 in dlopen_implementation (dl_caller=<optimized out>, mode=<optimized out>, file=<optimized out>) at dlopen.c:71
#13 ___dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:81
#14 0x0000564423812b84 in InitXPCOMGlue(mozilla::LibLoadingStrategy) ()
#15 0x0000564423812191 in main ()
| 14:06:06 |
| K900 ⚡️ | That's a spooky backtrace | 14:06:11 |
| nbp | wait what? It fails to open libnspr ? This is supposed to ship with Firefox itself. | 14:06:49 |
| K900 ⚡️ | It doesn't fail to open nspr | 14:07:06 |
| K900 ⚡️ | It fails to run the constructor for nspr | 14:07:11 |
| nbp | good point. | 14:07:24 |
| K900 ⚡️ | nspr itself looks like a normal ELF | 14:08:38 |
| K900 ⚡️ | Ish | 14:08:40 |
 vcunat | Don't we pull our nspr into the binaries? | 14:08:46 |
| K900 ⚡️ | That's Nightly so we shouldn't | 14:08:53 |
| vcunat | (I'm not really familiar with that flake.) | 14:09:26 |
| vcunat | * (OK, I'm not really familiar with that flake.) | 14:09:29 |
| nbp | if the flake is done like nixpkgs-mozilla, it just replace the source of firefox-bin. | 14:10:45 |
| vcunat | firefox-bin in nixpkgs takes lots of libs including nspr and stuffs it into RPATH. | 14:11:57 |
| vcunat | * firefox-bin in nixpkgs takes lots of libs including nspr and stuffs them into RPATH. | 14:12:11 |
| vcunat | * firefox-bin in nixpkgs takes lots of libs including nspr and patchelfs them into RPATH. | 14:12:37 |
| K900 ⚡️ | @nbp so uh | 14:23:28 |
| K900 ⚡️ | Any idea what "relrhack" is | 14:23:34 |
| K900 ⚡️ | https://hg.mozilla.org/mozilla-central/rev/032b87ff55061bcbdc7a85d9e18fde814797073a | 14:23:35 |
| K900 ⚡️ | That's the only sus commit I've found | 14:23:51 |
| nbp | elfhack used to be a mechanism to re-order the symbol of the binary such that they appear in the order in which the CPU would read them. | 14:50:02 |
| nbp | It is possible that patchelf does not like patching binaries produced by elfhack. | 14:50:59 |
| nbp | I do not know what relrhack is. | 14:51:43 |
| K900 ⚡️ | And relrhack, seemingly, is a ... reimplementation of elfhack? Maybe? | 14:51:49 |
| nbp | * It is possible that patchelf does not like patching binaries produced by relrhack. | 14:51:52 |
