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)

Product:
Core
Component:
JavaScript Engine
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla28
Tracking Flags:
Tracking Status
firefox28 --- fixed

People

(Reporter: fredbezies, Assigned: ehsan.akhgari)

References

Details

(Whiteboard: [qa-])

Attachments

(1 file, 1 obsolete file)

Patch (v1)
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.
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
My last homemade "working" build for packaging process is based on this revision : http://hg.mozilla.org/mozilla-central/rev/dbf94e314cde
"Error while running startup cache precompilation" means xpcshell either crashed or failed.
So which commit breaks xpcshell behavior was introduced on 22 and 23 november 2013 ?!
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.
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.
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.
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.
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.
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.
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
Reverting bugfix for bug #941424 fixes this one. A tweak is needed with gcc 4.8.2.
Blocks: 941424
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.
In which component ? Well I try. But I'm thinking this bug is driving me crazy :(
Moving the bug to the right component. Please include a link to the gcc bug here too. Thanks!
Component: Build Config → JavaScript Engine
In which GCC component on GCC bugtracker ? If you have an hint, et will be great. Thanks.
(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)
(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/>.
(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?
> 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
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.
Will try this patch this afternoon and report. And for gcc ? Well, I'll try after verifying build ;)
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 ? ;)
Attached patch Patch (v1) — — Splinter Review
Try this one?
Attachment #8339552 - Attachment is obsolete: true
Attachment #8339552 - Flags: feedback?(fredbezies)
Attachment #8340012 - Flags: feedback?(fredbezies)
Applied OK. Building right now. Will report asap to see if this bug is fixed or not.
Patch is OK. Packaging works again. Hardest part now : Report bug onto gcc bugzilla :(
Assignee: nobody → ehsan
Attachment #8340012 - Flags: feedback?(fredbezies)
I have $5 which says this is a dupe of bug 943839.
Depends on: 943839
(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!
No longer depends on: 943839
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.
Attachment #8340012 - Flags: review?(kvijayan) → review+
Couldn't we detect the compiler in the mozbuild file and make this change conditional?
(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.
https://hg.mozilla.org/mozilla-central/rev/48a03977660e
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
status-firefox28: --- → fixed
Whiteboard: [qa-]
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.

Attachment

General

Creator:
Created:
Updated:
Size: