1256687 - gcc6 - when compiling nightly with gcc6, tabs regularly crash when a new tab is opened

Status: RESOLVED DUPLICATE of bug 1245783

(Firefox :: Extension Compatibility, defect)

Description

[u532768]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160314204525

Steps to reproduce:

Just opened a tab for a link at reddit in nightly 20160314.
http://www.theverge.com/2016/3/15/11213518/alphago-deepmind-go-match-5-result



Actual results:

The tab crashed.  A dialog came up asking if I wanted to report the crash.  See attached png.  But clicking yes, merely brings up a second dialog asking to report the crash.  When that is clicked yes, it brings up the first crash report dialog.  An endless cycle.  The only thing that works is closing the crashed tab.


Expected results:

The tab should have opened.

Comment 1

[u532768]

Attachment: This is the configuration I use to compile nightly.

This is the .mozconfig used to compile nightly.  If I use -O0 instead of -O3, the browser is slower, but completely stable, and tabs don't crash.

Comment 2

[u532768]

Attachment: This is the first dialog that comes up when a tab crashes.

This is the first dialog that comes up when a tab crashes.  If it is clicked, the second dialog comes up.

Comment 3

[u532768]

Attachment: This is the second dialog, after clicking on submit a crash report.

This is the second dialog that comes up when clicking on submit a crash report from the first dialog.  If this dialog is clicked to submit a crash report, the first dialog comes up again.

The only way I've found to break the cycle is to click close the crashed tab.

Comment 4

[u532768]

Attachment: This is the configuration I use to compile nightly.

The earlier configuration had the wrong compile options in it.  This is correct.

Comment 5

[u532768]

There was an update of gcc today on my OS, and when I compiled today's nightly with the above .mozconfig, it no longer has this issue.  It is fast, and the tabs are stable.  Things that would have caused a tab crash yesterday are no longer doing so.  There were also updates to nightly, of course, so I don't know what fixed the issue.  

However, I'm closing this as notabug, since it isn't anymore.

Comment 6

[u532768]

Darn.  Right after I closed this ticket, I clicked on a link and the browser crashed.  I submitted a crash report, and then opened the browser again.  I was at reddit.com and clicked to visit this link,
http://www.cnn.com/2016/03/15/americas/argentina-chinese-fishing-vessel/index.html
and this exact problem showed up again.  Tab crashed, dialogs cycled, had to close the tab.

So, I'm re-opening the ticket again.

Comment 7

[ovidiu boca[:Ovidiu]]

Hi Stan,

I have tested this issue on Ubuntu 15.04 with Nightly 48(2016-03-20) and I can't reproduce you crashes ussing both links. 
How often do you have this crashes? Please test if the issue can be reproduced in the safe mode of Firefox: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager


Please type in URL bar "about:crashes" without commas and press enter, you will see crash id, please send the crash id from your crash. You can use this link for a better understanding: https://support.mozilla.org/en-US/kb/mozillacrashreporter

Comment 8

[u532768]

Thanks for looking into this.  I haven't tested the safe-mode yet, but I have tried with and without optimization, because I suspect it has to do with optimization in gcc 6.  A guess, because, while it would compile without the options below, it would crash immediately on start.  With the options, it runs fine most of the time, but has the tab crashes, and occasional browser crashes.  I noticed yesterday that if I start an optimized nightly with lots of tabs, the browser crashes.  I had a bunch of youtube videos open in tabs when it crashed, and when I restarted every one of them started to play.  The browser crashed immediately.  So I used the production version (45) to clean everything up.  It doesn't have any problems.

I don't remember that behavior in the past, where videos from youtube started immediately on loading.  Usually, I had to start them, which is the way I want it.

I see these pretty regularly, but unpredictably, when nightly is compiled with
#ac_add_options --enable-optimize=" -Wall -fno-lifetime-dse -fno-delete-null-pointer-checks -O3"
and never when it is compiled with
ac_add_options --enable-optimize=" -O0 "
Unfortunately, the last is very slow on some operations.  Videos play well, but communication with a website is glacial.

I'll test again after I compile today's nightly.

Comment 9

[u532768]

I forgot to mention, that when I compile using O3 optimization with an older version of gcc (4.9), in an older version of Fedora, I don't have these problems.  Nightly runs just fine.

Comment 10

[u532768]

Today's nightly20160321 crashed when I asked it to refresh a page in a tab.  I'll attach a png of all the crashes due to this issue, the image of about:crashes.

I am currently running it in safe-mode, and have experienced no crashes so far, but that isn't viable on the web.  But even if it no longer crashes, running without add-ons is pretty much useless because it allows everybody and their dog to track me.  There are usually at least half a dozen third party websites disabled on every website I visit because they are trackers.  Most the ability to customize firefox, especially to harden it, goes away.

I just noticed that in safe-mode, hitting the alt keys doesn't bring up access to the menus.  I wanted to check if the file menu allows saving web pages in maff format in nightly in safe mode, since it doesn't in regular mode.

Anyway, I'll run this for a while longer, to see if it will crash.  I've thought before that everything was all right, and then had a crash.  These intermittent crashes are hard.

Comment 11

[u532768]

Attachment: Capture of about:crashes page as png

This is the list of crashes related to this problem.  Some of the earlier crashes *might* be before I discovered the gcc options that would allow nightly to run when compiled with gcc6.  But I've had a lot of these tab crashes, so they might have scrolled off.

Comment 12

[ovidiu boca[:Ovidiu]]

Hi Stan,

First of all I want to thank you for your time.
About the crashes, please copy the  Report ID crash and past it here. 
From you comments I understand that when you are in safe mode you don't have any crashes, and you are right when you are in safe mode all the add-ons are disabled. Based on that I assume that this problem is related with some add-ons, and to be sure of that the only way to find out is to disabled all you add-ons and after that you enabled them one at the time and run the browser to see which one is related with the crashes. 

You said that with Firefox 45 you don't have any problems, that is correct?

Comment 13

[ovidiu boca[:Ovidiu]]

Stan if you use Nightly without e10s, do you have the same results? You can do that by going to Menu and choose New Non-10s and see if you can reproduce the crashes. Thank you

Comment 14

[:Gijs (he/him)]

With your self-built Nightly the stacks on the crash reports are going to be useless:

https://crash-stats.mozilla.com/report/index/b304cfab-219a-431c-921b-f21402160322

libxul.so 	libxul.so@0x3cadfb0 	
libxul.so 	libxul.so@0x61b3197 	
libxul.so 	libxul.so@0x61b3197 	
libxul.so 	libxul.so@0x61b3197

which tells us nothing.

We're going to need an actual stack from your machine, and even then, with all the custom compile options I have no idea if the browser is even expected to be stable, or if it isn't a problem in some of the system stuff that your build might be using. Do you see the same crashes with a stock build from mozilla.org ?

Comment 15

[u532768]

@ovidiu boca, comment 12, 13
Yes, no problem with firefox 45.  Rock solid.  The only issue I see is that after one of these nightly crashes, if I start firefox 45, it gets a seg fault the first time.  The next time I start it, it runs as normal.

It could be an add on, but the exact same code and configuration runs fine with the same add-ons when compiled using gcc 4.9.  I actually only ran about an hour in safe mode, so it is likely OK, but not certain, because I've gone for 2 to 3 hours without a crash in the non safe mode version.  I can try disabling the add-ons and then enabling them one at a time.

What is e10s?  Is that the new multi-user?  I know that multi-user is enabled in configuration.

@Gijs Kruitbosch, comment 14

Lots of good points.  It sounds like looking for a needle in a haystack.  And I'm a corner case; if I wasn't, you would be swamped with records like this.

I'll run mozregression on a non existent problem to see if the standard nightly builds have the problem.  It will take a while, because I'll have to actually run the browser for a while to see if the problem occurs.  That will be painful, without the history and password manager.

And I'll stop sending crash reports with my custom builds, since they're useless.  The reason I run nightly is so that I can custom configure it.  If I'm just going to run stock firefox, I'll just use the distro firefox, with all the bells and whistles.

What if I compile with debugging and run using gdb?  When it crashes, gdb should put out a stack trace and symbols.  It won't be very good, because with O3, the running code isn't going to correlate very well with the actual source.  I could also remove my custom .mozconfig, and just copy the default nightly .mozconfig so I compile locally with the default options.

@all
Because this is so obscure, you can close the ticket if you want.  If there really is a problem with optimization using gcc6 for nightly, it will get solved via other bugs eventually.  In the meantime, I *can* run nightly compiled with my custom .mozconfig just fine, if I compile without optimization, -O0.
No crashes, which sounds like optimization is creating a race condition of some sort.  It thinks some code isn't necessary, but it really is at a global level in order to prevent a race.

This is going to take a while, since I've got other things to do as well.  But I'll keep plugging away at it, even if you close the ticket.

Comment 16

[u532768]

I ran the latest production nightly using mozregression, for over an hour, and had a couple of errors on youtube videos, but no tab crashes.  Man, all those ads on youtube are irritating!

Comment 17

[ovidiu boca[:Ovidiu]]

Ok Stan, thanks for your update, I will close this issue as Resolved Incomplete, please feel free to reopen it when you consider, also you can comment on this ticket even if it's close and we'll see the comments.

Comment 18

[:Gijs (he/him)]

FWIW, it's possible (though I can't guarantee it because I don't know what's in it...) that if you have a 'real' stack from gdb that's symbolicated, we could act on the crash report - so that might be worth a shot if you'd like to keep using the custom build.

Comment 19

[u532768]

Not having much luck with the gdb debug builds.  For some reason it seems to strip symbols on install, even though I have debug turned on in .mozconfig.  But there is some good news - when the browser tabs crash, the dialogs work properly now, and restart the tab.  That makes nightly mostly usable.

Comment 20

[u532768]

Might have got a break today.  Was trying to run the latest nightly from the command line, and crashed on start.  The error message was

 [Child 31779] ###!!! ABORT: Aborting on channel error.: file /mnt/to_archive/accum/src/mozilla-central/ipc/glue/MessageChannel.cpp, line 2020
[Child 31779] ###!!! ABORT: Aborting on channel error.: file /mnt/to_archive/accum/src/mozilla-central/ipc/glue/MessageChannel.cpp, line 2020

So, it looks like the crash today is caused by something happening in ipc/glue/MessageChannel.cpp

It would start in safe-mode, but eventually crashed with the tab-error.  And then, the tab wouldn't restart :-(.

Comment 21

[ovidiu boca[:Ovidiu]]

I can't reproduce it on Linux 14.04 with FF Nightly 48.0a1, I think the right component for this is Startup and Profile System.

Comment 22

[u532768]

Today's nightly, 20160330, started with all add-ons enabled.  A tab crashed once, but recovered.  The browser crashed when a couple of add-ons failed.  I turned off e10s, and the crash from the add-ons still occurred.  So I disabled download helper and self-destructing cookies, and it has been running without a problem for over an hour.  It appears that the problem was e10s and the two add-ons.

I notice that google is leaving a cookie on my system now that self-destructing cookies is turned off.  Can you recommend a cookie manager that is compatible with nightly?  Of all the trackers on the web, google is the most insidious.  It's understandable, since that's how they make their money, but I would rather be off their radar.  I know, dream on.  :-)

This is the self-destructing error message, if it matters:
console.error: self-destructing-cookies: 
  Message: [Exception... "Not enough arguments [nsICookieManager2.remove]"  nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)"  location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-9xfbwuwnvpx4wwsfbwmcm4jj69e-at-jetpack/self-destructing-cookies/lib/main.js :: handleExpired :: line 608"  data: no]
  Stack:
    handleExpired@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-9xfbwuwnvpx4wwsfbwmcm4jj69e-at-jetpack/self-destructing-cookies/lib/main.js:608:5
exports.CookieTracker.prototype.scheduleExpiration/this.expirationHandles[key]<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-9xfbwuwnvpx4wwsfbwmcm4jj69e-at-jetpack/self-destructing-cookies/lib/cookietracker.js:253:85
notify@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/timers.js:40:9

The download helper error messages have scrolled off the console, so I can't post them.  If it's important, let me know, I'll re-enable the addon, and try to duplicate the error.

Real progress!

Comment 23

[Adrian Florinescu [:aflorinescu]]

48.0a1 20160328030215 User Agent Mozilla/5.0 (X11; Linux i686; rv:48.0) Gecko/20100101 Firefox/48.0 - Ubuntu 14.04 x32

Easily to reproduce the error, adding the two addons: Download Helper and SelfDestructing Cookies: see console error below. E10s on/off made no difference, so my assumption would be that this is not necesarily an E10s issue specifically.

Also, checking the list of E10s addons (https://www.arewee10syet.com/) found the folowing bugs related: Bug 1043081 and Bug 1130859.
Couldn't find anything related to Download Helper.

Selfdestructing cookies addon:
Console.error: self-destructing-cookies: 
  Message: [Exception... "Not enough arguments [nsICookieManager2.remove]"  nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)"  location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-9xfbwuwnvpx4wwsfbwmcm4jj69e-at-jetpack/self-destructing-cookies/lib/main.js :: handleExpired :: line 608"  data: no]
  Stack:
    handleExpired@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-9xfbwuwnvpx4wwsfbwmcm4jj69e-at-jetpack/self-destructing-cookies/lib/main.js:608:5
exports.CookieTracker.prototype.scheduleExpiration/this.expirationHandles[key]<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-9xfbwuwnvpx4wwsfbwmcm4jj69e-at-jetpack/self-destructing-cookies/lib/cookietracker.js:253:85
notify@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/timers.js:40:9

Helper Addon:

console.error: downloadhelper: 
Object
    - message = Not enough arguments [nsICookieManager2.remove]
    - fileName = undefined
    - lineNumber = 32
    - stack = @undefined:32:NaN|Set@resource://b9db16a4-6edc-47ec-a1f4-b86292ed211d/downloadhelper/lib/safemode.js:32:3|Check@resource://b9db16a4-6edc-47ec-a1f4-b86292ed211d/downloadhelper/lib/safemode.js:56:2|@resource://b9db16a4-6edc-47ec-a1f4-b86292ed211d/downloadhelper/lib/safemode.js:59:1|CuddlefishLoader/options<.load@resource://gre/modules/commonjs/sdk/loader/cuddlefish.js:79:18|@resource://b9db16a4-6edc-47ec-a1f4-b86292ed211d/downloadhelper/lib/main.js:28:18|CuddlefishLoader/options<.load@resource://gre/modules/commonjs/sdk/loader/cuddlefish.js:79:18|run@resource://gre/modules/commonjs/sdk/addon/runner.js:147:19|startup/</<@resource://gre/modules/commonjs/sdk/addon/runner.js:87:9|Handler.prototype.process@resource://gre/modules/Promise-backend.js:937:23|this.PromiseWalker.walkerLoop@resource://gre/modules/Promise-backend.js:816:7|Promise*this.PromiseWalker.scheduleWalkerLoop@resource://gre/modules/Promise-backend.js:747:11|this.PromiseWalker.schedulePromise@resource://gre/modules/Promise-backend.js:779:7|this.PromiseWalker.completePromise@resource://gre/modules/Promise-backend.js:714:7|readURI/<@resource://gre/modules/commonjs/sdk/net/url.js:50:9|NetUtil_asyncFetch/<.onStopRequest@resource://gre/modules/NetUtil.jsm:128:17|openModalWindow@resource://gre/components/nsPrompter.js:360:5|ModalPrompter.prototype.openPrompt@resource://gre/components/nsPrompter.js:550:9|ModalPrompter.prototype.confirmEx@resource://gre/components/nsPrompter.js:694:9|Prompter.prototype.confirmEx@resource://gre/components/nsPrompter.js:79:16|DefaultBrowserCheck.prompt@resource://app/components/nsBrowserGlue.js:2937:16|BG__onWindowsRestored/<@resource://app/components/nsBrowserGlue.js:1243:11|
    - toString = () => toString


In conclusion dupeme to Bug 1043081 ? Gijs, what do you think?

Comment 24

[u532768]

A browser crash, without e10s and without the two add-ons that were crashing.

$ /usr/local/bin/firefox
1459439782390	addons.update-checker	WARN	Update manifest for [e-mail] did not contain an updates property
1459439782401	addons.update-checker	WARN	Update manifest for [e-mail] did not contain an updates property
1459439782410	addons.update-checker	WARN	Update manifest for {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
*************************
A coding exception was thrown and uncaught in a Task.

Full message: TypeError: versionInfo.data is undefined
Full stack: this.checkVersions/<@resource://gre/modules/services-common/kinto-updater.js:48:14
TaskImpl_run@resource://gre/modules/Task.jsm:319:40
promise callback*TaskImpl_handleResultValue@resource://gre/modules/Task.jsm:395:7
TaskImpl_run@resource://gre/modules/Task.jsm:327:13
promise callback*TaskImpl_handleResultValue@resource://gre/modules/Task.jsm:395:7
TaskImpl_run@resource://gre/modules/Task.jsm:327:13
TaskImpl@resource://gre/modules/Task.jsm:280:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:254:14
Task_spawn@resource://gre/modules/Task.jsm:168:12
this.checkVersions@resource://gre/modules/services-common/kinto-updater.js:24:10
Blocklist.prototype.notify@resource://gre/components/nsBlocklistService.js:636:7
TM_notify/<@resource://gre/components/nsUpdateTimerManager.js:201:11
TM_notify@resource://gre/components/nsUpdateTimerManager.js:249:7

*************************
ExceptionHandler::GenerateDump cloned child 23289
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Comment 25

[u532768]

Had another crash, but it was only the last three lines above.

$ /usr/local/bin/firefox
ExceptionHandler::GenerateDump cloned child 23479
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

When I restarted nightly, it recovered exactly where it had crashed.  Indeed, I am writing this from that restart.

Comment 26

[:Gijs (he/him)]

(In reply to Adrian Florinescu [:AdrianSV] from comment #23)
> 48.0a1 20160328030215 User Agent Mozilla/5.0 (X11; Linux i686; rv:48.0)
> Gecko/20100101 Firefox/48.0 - Ubuntu 14.04 x32
> 
> Easily to reproduce the error, adding the two addons: Download Helper and
> SelfDestructing Cookies: see console error below. E10s on/off made no
> difference, so my assumption would be that this is not necesarily an E10s
> issue specifically.

I think this is just a change to the cookie manager API for which the selfdestructing cookies add-on needs updating.

What's much more important is: were you able to reproduce the crash? That's what this was originally about...

Comment 27

[Adrian Florinescu [:aflorinescu]]

(In reply to :Gijs Kruitbosch from comment #26)
> What's much more important is: were you able to reproduce the crash? That's
> what this was originally about...
No, it didn't crash - e10s on/off.

Comment 28

[:Gijs (he/him)]

stan, just for my sanity, am I correct in saying you're seeing these crashes on your self-compiled Nightly but not on a stock Nightly? Even if you run your regular profile with the add-ons ? Or have you not tried with your regular profile yet?

Can you reproduce the same problem on your self-compiled Nightly on a clean profile with just those 2 add-ons installed to which you've narrowed this down?

Comment 29

[u532768]

> seeing these crashes on your self-compiled Nightly but not on a stock Nightly

Yes, that is the case.  That is why the bugzilla was originally closed.  I seem to be a corner case with my custom compile options and add-ons.  I ran the stock nightly using mozregression, so I don't think it used any of my local preferences or add-ons.  I've never installed the stock nightly, so I'm not sure how to go about running with my regular profile.  But, I could compile nightly with its default options as my .mozconfig, and install and run it the way I'm doing with the custom compiles.  That would pick up my local preferences and add-ons.

> just those 2 add-ons installed to which you've narrowed this down?

Well, I'm still getting the above crashes without those two add-ons, and with e10s turned off on my custom compile.  Again, I could compile with the default nightly options, and turn on only the two problematic add-ons, and toggle e10s.

I hate to waste so much of your time on such an obscure bug.  I'm happy enough running nightly now that it only occasionally crashes.  And when it does crash, it recovers on restart, and seems to have no problem completing the operation that crashed it.  Which is usually switching tabs, or refreshing a tab.  Definitely workable.

Comment 30

[u532768]

OK, I compiled today's nightly with this in my .mozconfig

. $topsrcdir/browser/config/mozconfig

ac_add_options --enable-application=browser
ac_add_options --prefix="/usr/local"

I think this would get me the default compile options that stock nightly compiles with.

When I tried to run it with no e10s, and without the two failing add-ons, it crashed with the same crashes as above while opening a link in a tab.  And it took several tries to restart, but eventually it restarted and recovered the tabs that were open when it crashed.

$ /usr/local/bin/firefox
ExceptionHandler::GenerateDump cloned child 25277
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

So, I think the answer to your questions is that I am seeing the same problem with a stock nightly compile, as I do with my custom compile.

Comment 31

[:Gijs (he/him)]

(In reply to stan from comment #29)
> > seeing these crashes on your self-compiled Nightly but not on a stock Nightly
> 
> Yes, that is the case.  That is why the bugzilla was originally closed.  I
> seem to be a corner case with my custom compile options and add-ons.  I ran
> the stock nightly using mozregression, so I don't think it used any of my
> local preferences or add-ons.  I've never installed the stock nightly, so
> I'm not sure how to go about running with my regular profile.  But, I could
> compile nightly with its default options as my .mozconfig, and install and
> run it the way I'm doing with the custom compiles.  That would pick up my
> local preferences and add-ons.

Yes, but when I said stock nightly, I meant go to https://nightly.mozilla.org/, download the 64-bit linux archive, extract the files, and run those. They will run with your normal profile.

However, if your custom compile is failing even without the add-ons, that sure sounds like something dodgy is up with the thing that's being compiled or the thing that's doing the compiling.

Are you using source archives from mozilla.org to compile? Or a mercurial copy? Or something provided by your distro? Because based on your earlier comments about gcc6 and gcc4.9 (comment 9), this sounds like a compiler issue that should be raised with gcc. You could also try compiling with clang on your newer version of Fedora to further confirm this theory.

Comment 32

[u532768]

> stock nightly, I meant go to https://nightly.mozilla.org/, download the 64-bit linux archive, extract > the files, and run those

I haven't done this.

> a mercurial copy?

This.

> sounds like a compiler issue that should be raised with gcc

I did this, and they suggested the workaround (the compile options) that got nightly to compile with gcc6, and that the optimization in gcc6 is very different than in earlier versions, and that nightly code was probably not compatible with the changes in gcc6 that brought it up to the c15? standard, which gcc6 adheres to.

Note that nightly compiles and runs without problem, with e10s enabled and all add-ons active, when I compile with gcc 4.9.  If the stock nightly binaries are compiled with a gcc before gcc6, running them would not provide any new information.  

And, if I compile nightly without *any* optimization, -O0, using gcc6, nightly runs fine with e10s and all add-ons enabled, though it does run slowly (sometimes very slowly).

I agree this is some sort of incompatibility between gcc6 optimization and nightly code.  It seems to just be me experiencing this, so there must be something else contributing, since the gcc6 compiler and nightly code should be stock.

I think that over time, it will all work out, as other errors in gcc6 and nightly are fixed, and they slowly converge.

In just the short time this ticket has been open, I've seen huge progress here in compiling and running nightly.  So I'm optimistic.

Comment 33

[u532768]

I don't think it would be relevant, but I am running the 4.6 kernel test candidates.

Comment 34

[:Gijs (he/him)]

(In reply to stan from comment #32)
> > stock nightly, I meant go to https://nightly.mozilla.org/, download the 64-bit linux archive, extract > the files, and run those
> 
> I haven't done this.
> 
> > a mercurial copy?
> 
> This.
> 
> > sounds like a compiler issue that should be raised with gcc
> 
> I did this, and they suggested the workaround (the compile options) that got
> nightly to compile with gcc6, and that the optimization in gcc6 is very
> different than in earlier versions, and that nightly code was probably not
> compatible with the changes in gcc6 that brought it up to the c15? standard,
> which gcc6 adheres to.

When quickly scanning https://gcc.gnu.org/gcc-6/porting_to.html , it seems like you're already disabling the two optimizations that they added that could explain this behaviour (though that doc says you want -flifetime-dse=1 not -fno-lifetime-dse -- I don't know if that's just outdated or if I'm missing something). It'd be worth knowing what else there is that could be explaining this. Either way I'm not an expert on our compiler situation so I can't really help much more... Mike, do you know if we're tracking issues with gcc6 somewhere specific?

Comment 35

[u532768]

> though that doc says you want -flifetime-dse=1 not -fno-lifetime-dse 

I'll try this when compiling today's nightly.  Maybe it was operator error all along.

Comment 36

[Martin Stránský [:stransky] (ni? me)]

I believe this is a dupe of Bug 1245783, just run JS test and you'll see what happens.

Comment 37

[u532768]

I think I agree with Martin, after reading https://bugzilla.mozilla.org/show_bug.cgi?id=1245783

Comment 38

[ovidiu boca[:Ovidiu]]

Based on comment 37, this bug will be marked as duplicate of bug 1245783.

Comment 39

[Mike Hommey [:glandium]]

(In reply to :Gijs Kruitbosch from comment #34)
> Mike, do you know if we're tracking issues with gcc6 somewhere specific?

We don't have a tracking bug, no.