TenFourFox built with gcc 6.4.0 causes bus error in XUL nsCSSFrameConstructor::ProcessChildren #464
Comments
|
I'm working at building gdb 7.6.8 104Fx patchlevel 4 but running into some hiccups with makeinfo. [Edit: that makeinfo issue appears to have been fixed by disabling the newer makeinfo installed by MacPorts, and using the ancient one installed on 10.4.11 by default ] |
|
I'm not totally sure I have gdb built correctly. But the parts that did build seem to work, so here's what it gave me: |
|
Those terminal assertions are really scary. I've never seen them before. Can you rebuild without I don't know why |
|
I didn't at first realize that the |
|
Odd, I thought I put the binary in -4 as well. Here it is. |
|
sadly the linker is failing to link XUL now, with a which I take to represent it is running out of memory / XUL is too big with no optimizations and all the debug information in it. I'm disabling parts of the build now and using some equivalent system libraries in the hopes of trimming it down. |
|
That's a bit alarming on its own, but how about changing to |
|
I have news: The TenFourFoxDebug I built today with gcc 6.4.0 ( I put |
|
This means there's an optimization issue. Does compiling |
|
I concur that building TenFourFoxDebug with gcc6 and with @NapalmSauce - I'm going to try the -O1 build next. |
|
Doing the -O2 one then. Depending on what works, I'll try narrowing it down to one of the flags the first optimization level to break executables expands into. |
|
|
|
Needless to say, I noticed there are alot However, something's really odd: if I |
|
I think the next thing to do is make this assert fatal, since this is the earliest point we can predictably see it goes wrong: Change that from |
|
Just as advised, here's the retrieved backtrace in question: |
|
When I used gcc6 with
then it doesn't crash any more, but doesn't open up any browser windows either. The Window menu shows the windows are being created and tracked, but there are no windows visible on the screen. Menus, about box, etc all work normally. |
|
@kencu It does that but, the browser kills itself with the assert. It is completely unloaded with a crashlog soon after in my case. What's in your console? |
|
I'm sceptical of that backtrace. Can you give the the debugger's view with |
|
Alternatively, after the |
|
gdb makes sense, most call parameters are present: I wonder why I can't read debug symbols correctly unless I run the standalone script. This in turn makes gdb flood my scrollback buffer with timestamps warnings. |
|
I'm not sure this is the same assertion. Does it always terminate with the |
|
Either using I'll also do a build with |
|
I put a MOZ_ASSERT(0) in the suggested spot, and this is what I obtained with gdb7 (on a fully assembled binary built with gcc6, optimize = -O1): |
|
That backtrace makes sense to me given the symptoms reported (it's a failure to handle the XUL for the window), but I'm not sure why it's gone wrong and the calls seem correct. The bad thing must have happened earlier. The other way to find the compiler bug -- and this would be labourious, but would work -- is to go one by one through the optimizations added by |
|
There's a ton of them. Since my This way we could use Using this with a G3 or G3-nostrip.mozcfg could also save time. Is it advisable to try something like this before falling back to trying every single option? |
|
That seems reasonable as far as the optimization options, but I'd still stick with the DEBUG configuration because it might crash with a different error and you'd be rebuilding DEBUG anyway. I'm actually suspecting |
|
You're right, keeping with DEBUG is more suitable than rushing all the builds then running into something unexpected. Especially when I have seen some strange debugging behaviour previously. |
|
Before proceding with your debugging you should apply the attached patch to the linker (ld64). |
|
The patch will apply against the current ld64-97 sources from macports, correct? Does that mean something like placing the two sections either before the branch island at the start of __text or after the branch island at the end of __text would allow these sections to grow a little more without harm? Not that it looks like a simple/feasible undertaking either. Anyway, thanks for the patch and the hint! |
|
Yes, the patch is against ld64 97.17 . |
|
I was thinking I might also try a build with gcc7 to see if any of these optimization issues have been resolved in that version. Just an FYI as well, not sure if you've seen Michael's work on building a newer ld64 on PPC. https://github.com/michaelweiser/ld64/branches |
|
This might not even be a compiler issue at all - might well be just that specific linker issue. Unfortunately Michael says that his forward ports don't solve the problems existing in ld64 127.2 - I know it fails to correctly link bigger binaries, like WebCore for example. I'd expect the same for XUL. |
kencu
added a commit
to kencu/TigerPorts
that referenced
this issue
Jan 22, 2018
|
I applied your ld64-97 patch, rebuilt TFF debug (without any MOZ_ASSERT changes added), with gcc6 and optimize=-O1 . I get a new assertion failure that I thought might be relevant. |
|
FWIW gcc7 does build TFF through to completion on 10.4 PPC, but very similar errors appear. |
|
I thought about this for a moment.. This fatal assert
up to now only showed up when compiling at while this assert (the one we tried to make fatal and didn't show up without forcing it)
has only been seen from my build at So even though we narrow it down to one single compiler flag that makes I'm not sure what can be done for now. |
|
I'm thinking of leaving 6.4.0 alone for awhile right now. Even more when I suspect After reluctantly doing a debug build using 5.5.0 with @classilla Can this issue be turned into something that sounds like "Find a later version of |
|
I'd prefer a new issue for getting gcc 5 off the ground, since there may still be a way to rescue the linker for gcc 6.
|
|
late in this discussion, I have not tried, but in ArcticFox I need these to compile and run witthout crash, I read the explanatino in some backports about code being optmizized away in constructors, newer FF then fixed that (but have no reference to the bugs that fixed it...)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looking towards a day when TenFourFox might be built with gcc6.
A debug build with gcc6, generic G3 has a bus error on launch:
====== mozconfig
run log:
crashdump:
The text was updated successfully, but these errors were encountered: