Closed
Bug 942421
Opened 11 years ago
Closed 11 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•11 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•11 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•11 years ago
|
||
"Error while running startup cache precompilation" means xpcshell either crashed or failed.
Reporter | ||
Comment 3•11 years ago
|
||
So which commit breaks xpcshell behavior was introduced on 22 and 23 november 2013 ?!
Comment 4•11 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•11 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•11 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•11 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•11 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•11 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•11 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•11 years ago
|
||
Reverting bugfix for bug #941424 fixes this one. A tweak is needed with gcc 4.8.2.
Assignee | ||
Comment 11•11 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•11 years ago
|
||
In which component ? Well I try. But I'm thinking this bug is driving me crazy :(
Assignee | ||
Comment 13•11 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•11 years ago
|
||
In which GCC component on GCC bugtracker ? If you have an hint, et will be great. Thanks.
Comment 15•11 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•11 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•11 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•11 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•11 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•11 years ago
|
||
Will try this patch this afternoon and report. And for gcc ? Well, I'll try after verifying build ;)
Reporter | ||
Comment 21•11 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•11 years ago
|
||
Try this one?
Attachment #8339552 -
Attachment is obsolete: true
Attachment #8339552 -
Flags: feedback?(fredbezies)
Attachment #8340012 -
Flags: feedback?(fredbezies)
Reporter | ||
Comment 23•11 years ago
|
||
Applied OK. Building right now. Will report asap to see if this bug is fixed or not.
Reporter | ||
Comment 24•11 years ago
|
||
Patch is OK. Packaging works again. Hardest part now : Report bug onto gcc bugzilla :(
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → ehsan
Assignee | ||
Comment 25•11 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•11 years ago
|
Attachment #8340012 -
Flags: feedback?(fredbezies)
Assignee | ||
Comment 26•11 years ago
|
||
I have $5 which says this is a dupe of bug 943839.
Depends on: 943839
Assignee | ||
Comment 28•11 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•11 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•11 years ago
|
Attachment #8340012 -
Flags: review?(kvijayan) → review+
Assignee | ||
Comment 30•11 years ago
|
||
Comment 31•11 years ago
|
||
Couldn't we detect the compiler in the mozbuild file and make this change conditional?
Assignee | ||
Comment 32•11 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•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
status-firefox28:
--- → fixed
Whiteboard: [qa-]
Reporter | ||
Comment 35•11 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
•