Closed
Bug 942421
Opened 10 years ago
Closed 9 years ago
Since bugfix for 941424, xpcshell built with gcc 4.8.2 is broken in packaging process
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
Tracking | Status | |
---|---|---|
firefox28 | --- | fixed |
People
(Reporter: fredbezies, Assigned: ehsan.akhgari)
References
Details
(Whiteboard: [qa-])
Attachments
(1 file, 1 obsolete file)
1.42 KB,
patch
|
djvj
:
review+
|
Details | Diff | Splinter Review |
Really recent regression. After a successful mozilla firefox trunk building process, I went to objdir repository to package it all. After I typed make package, process was stopped while packaging resources, with this error message : resource://gre/modules/SettingsDB.jsm Traceback (most recent call last): File "/home/fred/logs/fox/src/toolkit/mozapps/installer/packager.py", line 375, in <module> main() File "/home/fred/logs/fox/src/toolkit/mozapps/installer/packager.py", line 367, in main args.source, gre_path, base) File "/home/fred/logs/fox/src/toolkit/mozapps/installer/packager.py", line 148, in precompile_cache errors.fatal('Error while running startup cache precompilation') File "/home/fred/logs/fox/src/python/mozbuild/mozpack/errors.py", line 101, in fatal self._handle(self.FATAL, msg) File "/home/fred/logs/fox/src/python/mozbuild/mozpack/errors.py", line 96, in _handle raise ErrorMessage(msg) mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation /home/fred/logs/fox/src/toolkit/mozapps/installer/packager.mk:645: recipe for target 'stage-package' failed make[3]: *** [stage-package] Error 1 /home/fred/logs/fox/src/toolkit/mozapps/installer/packager.mk:674: recipe for target 'make-package' failed make[2]: *** [make-package] Error 2 Even if I'm using archlinux and python3, PYTHON is linked to python2 [fred@fredo-arch src]$ export | grep python declare -x PYTHON="python2" It worked yesterday, so this a really recent regression. /home/fred/logs/fox/src/config/rules.mk:610: recipe for target 'default' failed make[1]: *** [default] Error 2 /home/fred/logs/fox/src/browser/build.mk:9: recipe for target 'package' failed make: *** [package] Error 2 Trunk source code is up-to-date.
Reporter | ||
Updated•9 years ago
|
Summary: Make package process crashes with message Error while running startup cache precompilation → Since 22 november 2013, make package is broken in packager.py, line 375
Reporter | ||
Comment 1•9 years ago
|
||
My last homemade "working" build for packaging process is based on this revision : http://hg.mozilla.org/mozilla-central/rev/dbf94e314cde
Comment 2•9 years ago
|
||
"Error while running startup cache precompilation" means xpcshell either crashed or failed.
Reporter | ||
Comment 3•9 years ago
|
||
So which commit breaks xpcshell behavior was introduced on 22 and 23 november 2013 ?!
Comment 4•9 years ago
|
||
Considering this is run on build slaves, and none of them failed, and neither does it fail locally for me on both windows and linux, this is something you'll have to figure yourself.
Reporter | ||
Comment 5•9 years ago
|
||
Well, as I don't have time to do this, I think I will ask to let this bug closed. I let you choose the right closing option. And I'll stay with ftp.mozilla.org prebuilt version now. Thanks for your answer, anyway.
Comment 6•9 years ago
|
||
Well, I see on a linux build almost the same problem, but the packager fails a little later. What is confusing is that I see this packaging error only with gcc-4.8.2 builds while clang-3.3 builds are properly packed. With the gcc-4.8.2 builds I figured out that it failed since the js script engine is built in unified mode https://hg.mozilla.org/mozilla-central/rev/3b9e118ded0f When I move 'jsarray.cpp', and 'jsatom.cpp', from UNIFIED_SOURCES to SOURCES in the js/src/moz.build file packaging works again also in the gcc-4.8.2 build.
Comment 7•9 years ago
|
||
What glandium means is that something in your local build configuration that is different from the official Mozilla build configuration causes xpcshell to crash during the packaging stage. This might be a bug in our code or in your toolchain, but we don't have the resources to diagnose it for you.
Reporter | ||
Comment 8•9 years ago
|
||
Here are all the infos I could give you to "solve" this bug. Toolchain bug ? gcc was last updated on november 11. 10 days before bug appears. [fred@fredo-arch-laptop ~]$ pacman -Qi gcc Name : gcc Version : 4.8.2-4 Description : The GNU Compiler Collection - C and C++ frontends Architecture : x86_64 URL : http://gcc.gnu.org Licenses : GPL LGPL FDL custom Groups : base-devel Provides : None Depends On : gcc-libs=4.8.2-4 binutils>=2.23 libmpc cloog Optional Deps : None Required By : libtool Optional For : None Conflicts With : None Replaces : None Installed Size : 74313.00 KiB Packager : Allan McRae <allan@archlinux.org> Build Date : Fri Nov 8 13:05:36 2013 Install Date : Sat Nov 9 22:07:38 2013 Install Reason : Explicitly installed Install Script : Yes Validated By : Signature Build options ? --enable-application=browser --enable-optimize --disable-debug --disable-tests --disable-debug-symbols --disable-crashreporter --with-ccache --disable-installer --disable-warnings-as-errors In comment #6, there is an answer. I don't have time to test right now, but as I told you, my last working build was made with revision http://hg.mozilla.org/mozilla-central/rev/dbf94e314cde so a day or two before the """culprit""" was added. And as in comment #6, my gcc is also a 4.8.2 one. I'm not a coder, but it looks like this patch for JS is not completely working with Gcc 4.8.2. Just a guess from me. Don't know if it is the right answer. If you need more infos on my toolchain (which seemed to be unchanged between 20 november and today), just ask me.
Reporter | ||
Comment 9•9 years ago
|
||
I will try to build again (with a fresh new source code). Also I will try removing commit for Bug #941424 I will see if reverting commit fix this issue with gcc 4.8.2 or not. Reporting ASAP.
Reporter | ||
Updated•9 years ago
|
Summary: Since 22 november 2013, make package is broken in packager.py, line 375 → Since bugfix for 941424, xpcshell built with gcc 4.8.2 is broken in packaging process
Reporter | ||
Comment 10•9 years ago
|
||
Reverting bugfix for bug #941424 fixes this one. A tweak is needed with gcc 4.8.2.
Assignee | ||
Comment 11•9 years ago
|
||
You're probably hitting a bug in gcc, please do report it to them! If someone wants to write a patch based on comment 6, I think we should take it while the gcc bug is fixed.
Reporter | ||
Comment 12•9 years ago
|
||
In which component ? Well I try. But I'm thinking this bug is driving me crazy :(
Assignee | ||
Comment 13•9 years ago
|
||
Moving the bug to the right component. Please include a link to the gcc bug here too. Thanks!
Component: Build Config → JavaScript Engine
Reporter | ||
Comment 14•9 years ago
|
||
In which GCC component on GCC bugtracker ? If you have an hint, et will be great. Thanks.
Comment 15•9 years ago
|
||
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #11) > If someone wants to write a patch based on comment 6, I think we should take > it while the gcc bug is fixed. Here is the patch I use (comments may be overhauled for check-in later). Just to mention this after moving every cpp of the js/src directory around between UNIFIED_SOURCES and SOURCES the two jsatom.cpp _and_ jsarray.cpp together remained any of these two alone remaining in UNIFIED_SOURCES did still crash.
Attachment #8339552 -
Flags: feedback?(fredbezies)
Assignee | ||
Comment 16•9 years ago
|
||
(In reply to comment #14) > In which GCC component on GCC bugtracker ? If you have an hint, et will be > great. Thanks. Oh, sorry I misunderstood you. But unfortunately I'm not familiar with how the gcc project works. That being said, please take a look at <http://gcc.gnu.org/bugs/>.
Assignee | ||
Comment 17•9 years ago
|
||
(In reply to Walter Meinl from comment #15) > Created attachment 8339552 [details] [diff] [review] > dont_build_jsatom_jsarray_unified.patch > > (In reply to :Ehsan Akhgari (needinfo? me!) from comment #11) > > > If someone wants to write a patch based on comment 6, I think we should take > > it while the gcc bug is fixed. > Here is the patch I use (comments may be overhauled for check-in later). > Just to mention this after moving every cpp of the js/src directory around > between UNIFIED_SOURCES and SOURCES the two jsatom.cpp _and_ jsarray.cpp > together remained any of these two alone remaining in UNIFIED_SOURCES did > still crash. Thanks for the patch, Walter! Do you have access to the try server? If yes, can you please post the patch there for a try run?
Comment 18•9 years ago
|
||
> Thanks for the patch, Walter! Do you have access to the try server? If
> yes, can you please post the patch there for a try run?
unfortunately not
Assignee | ||
Comment 19•9 years ago
|
||
OK, no problem. Once this patch is verified to fix the problem, please let me know and I will push it to the try server for you.
Reporter | ||
Comment 20•9 years ago
|
||
Will try this patch this afternoon and report. And for gcc ? Well, I'll try after verifying build ;)
Reporter | ||
Comment 21•9 years ago
|
||
Patch cannot be applied : [fred@fredo-arch src]$ patch -p1 < dont_build_jsatom_jsarray_unified.patch patching file js/src/moz.build Hunk #1 succeeded at 119 (offset -1 lines). Hunk #2 FAILED at 189. 1 out of 2 hunks FAILED -- saving rejects to file js/src/moz.build.rej Well, what about an up-to-date patch ? ;)
Assignee | ||
Comment 22•9 years ago
|
||
Try this one?
Attachment #8339552 -
Attachment is obsolete: true
Attachment #8339552 -
Flags: feedback?(fredbezies)
Attachment #8340012 -
Flags: feedback?(fredbezies)
Reporter | ||
Comment 23•9 years ago
|
||
Applied OK. Building right now. Will report asap to see if this bug is fixed or not.
Reporter | ||
Comment 24•9 years ago
|
||
Patch is OK. Packaging works again. Hardest part now : Report bug onto gcc bugzilla :(
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → ehsan
Assignee | ||
Comment 25•9 years ago
|
||
Comment on attachment 8340012 [details] [diff] [review] Patch (v1) https://tbpl.mozilla.org/?tree=Try&rev=b967da652736
Attachment #8340012 -
Flags: review?(kvijayan)
Assignee | ||
Updated•9 years ago
|
Attachment #8340012 -
Flags: feedback?(fredbezies)
Assignee | ||
Comment 26•9 years ago
|
||
I have $5 which says this is a dupe of bug 943839.
Depends on: 943839
Assignee | ||
Comment 28•9 years ago
|
||
(In reply to comment #26) > I have $5 which says this is a dupe of bug 943839. And it seems like I have now lost that $5!
Comment 29•9 years ago
|
||
Just a few more information: gcc-4.73 and clang-3.3 are ok, gcc-4.8.1 and gcc-4.8.2 fail As I mentioned already in comment #6 my gcc-4.8 builds fail a bit further downstream. But they do fail reproducibly always right after the last element in resource://gre ("resource://gre/modules/PluralForm.jsm") when xpcshell is invoked the second time to precompile the elements in resource://app (first element is "resource://app/components/devtools-clhandler.js"). Else I tried to package with -j1 but without improvement.
Updated•9 years ago
|
Attachment #8340012 -
Flags: review?(kvijayan) → review+
Assignee | ||
Comment 30•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/48a03977660e
Comment 31•9 years ago
|
||
Couldn't we detect the compiler in the mozbuild file and make this change conditional?
Assignee | ||
Comment 32•9 years ago
|
||
(In reply to comment #31) > Couldn't we detect the compiler in the mozbuild file and make this change > conditional? That is a very bad idea, since it would mean that people with different compiler versions will get different unification groupings.
Comment 33•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/48a03977660e
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
status-firefox28:
--- → fixed
Whiteboard: [qa-]
Reporter | ||
Comment 35•9 years ago
|
||
Will have to be reopened ? Both firefox and thunderbird package are broken now, but with gcc 4.9.0. See bug 1002002 :(
You need to log in
before you can comment on or make changes to this bug.
Description
•