There was a typo in my above post, should say javascript.enabled, but I'll assume you didn't have the extra dot when tried yesterday.
> I installed debug symbols
I just realized this makes it sound like you installed firefox-dbg, which would give incorrect addresses because those symbols are for the public apt binary. Do you mean that you *rebuilt* with debug symbols (-g)?
> Can you check where that "crashes obscurely elsewhere" crashed ?
My NOP test earlier was flawed because it did not get the program counter back onto a 4-byte aligned instruction + switch out of Thumb mode. The fix was to hexedit in the thumb instructions 0020; 0047 (movs r0, #0; bx r0). With this, Firefox 58 continues further on and then crashes here:
Firefox 59 crashes at the same instruction sequence, although the addresses are of course different.
Getting a backtrace with symbols: Unfortunately for me if I install firefox-dbg, firefox -g just hangs indefinitely. I thought this was due to the limit of 1 GB RAM on a Raspberry Pi 3, but it doesn't get any further even if I add gigabytes of swap space or wait a while.
It's also possible that the crash you're hitting is in the neighborhood of the other one we were avoiding on Firefox 57 by specifically installing the 14.04 package. The 16.04 packages of 57, 58, and 59 don't even hit the SkJumper bug, instead crashing at an earlier point on this:
Although this does not appear the same as the crash on your custom build, interestingly in both cases the segfaulting instruction is precisely strd r2, r3, [r1]
To confirm if you're actually getting past the SkJumper problem point, after a few seconds the Firefox window frame should appear on the screen before it crashes. That's the behavior on firefox_58.0+build6-0ubuntu0.14.04.1_armhf.deb currently while firefox_58.0.2+build1_0ubuntu0.16.04.1_armhf.deb just aborts before getting that far.
There was a typo in my above post, should say javascript.enabled, but I'll assume you didn't have the extra dot when tried yesterday.
> I installed debug symbols
I just realized this makes it sound like you installed firefox-dbg, which would give incorrect addresses because those symbols are for the public apt binary. Do you mean that you *rebuilt* with debug symbols (-g)?
> Can you check where that "crashes obscurely elsewhere" crashed ?
My NOP test earlier was flawed because it did not get the program counter back onto a 4-byte aligned instruction + switch out of Thumb mode. The fix was to hexedit in the thumb instructions 0020; 0047 (movs r0, #0; bx r0). With this, Firefox 58 continues further on and then crashes here:
0x0040517c <_start+0>: 4f f0 00 0b mov.w r11, #0
0x00405180 <_start+4>: 4f f0 00 0e mov.w lr, #0
0x00405184 <_start+8>: 02 bc pop {r1}
0x00405186 <_start+10>: 6a 46 mov r2, sp
0x00405188 <_start+12>: 04 b4 push {r2}
0x0040518a <_start+14>: 01 b4 push {r0}
0x0040518c <_start+16>: df f8 24 a0 ldr.w r10, [pc, #36] ; 0x4051b4 <_start+56
Firefox 59 crashes at the same instruction sequence, although the addresses are of course different.
Getting a backtrace with symbols: Unfortunately for me if I install firefox-dbg, firefox -g just hangs indefinitely. I thought this was due to the limit of 1 GB RAM on a Raspberry Pi 3, but it doesn't get any further even if I add gigabytes of swap space or wait a while.
It's also possible that the crash you're hitting is in the neighborhood of the other one we were avoiding on Firefox 57 by specifically installing the 14.04 package. The 16.04 packages of 57, 58, and 59 don't even hit the SkJumper bug, instead crashing at an earlier point on this:
=> 0xf314e830: c1 e9 00 23 strd r2, r3, [r1]
0xf314e834: 05 9b ldr r3, [sp, #20]
0xf314e836: 06 9a ldr r2, [sp, #24]
0xf314e838: 1a 60 str r2, [r3, #0]
0xf314e83a: 9d f8 38 30 ldrb.w r3, [sp, #56] ; 0x38
Although this does not appear the same as the crash on your custom build, interestingly in both cases the segfaulting instruction is precisely strd r2, r3, [r1]
To confirm if you're actually getting past the SkJumper problem point, after a few seconds the Firefox window frame should appear on the screen before it crashes. That's the behavior on firefox_ 58.0+build6- 0ubuntu0. 14.04.1_ armhf.deb currently while firefox_ 58.0.2+ build1_ 0ubuntu0. 16.04.1_ armhf.deb just aborts before getting that far.