Since bugfix for 941424, xpcshell built with gcc 4.8.2 is broken in packaging process

RESOLVED FIXED in Firefox 28

Status

()

defect
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: fredbezies, Assigned: Ehsan)

Tracking

Trunk
mozilla28
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox28 fixed)

Details

(Whiteboard: [qa-])

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

6 years ago
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

6 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

6 years ago
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.
Reporter

Comment 3

6 years ago
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.
Reporter

Comment 5

6 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

6 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.
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

6 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

6 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

6 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

6 years ago
Reverting bugfix for bug #941424 fixes this one. A tweak is needed with gcc 4.8.2.
Blocks: 941424
Assignee

Comment 11

6 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

6 years ago
In which component ? Well I try. But I'm thinking this bug is driving me crazy :(
Assignee

Comment 13

6 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

6 years ago
In which GCC component on GCC bugtracker ? If you have an hint, et will be great. Thanks.

Comment 15

6 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

6 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

6 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

6 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

6 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

6 years ago
Will try this patch this afternoon and report. And for gcc ? Well, I'll try after verifying build ;)
Reporter

Comment 21

6 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

6 years ago
Posted patch Patch (v1)Splinter Review
Try this one?
Attachment #8339552 - Attachment is obsolete: true
Attachment #8339552 - Flags: feedback?(fredbezies)
Attachment #8340012 - Flags: feedback?(fredbezies)
Reporter

Comment 23

6 years ago
Applied OK. Building right now. Will report asap to see if this bug is fixed or not.
Reporter

Comment 24

6 years ago
Patch is OK. Packaging works again. Hardest part now : Report bug onto gcc bugzilla :(
Assignee

Updated

6 years ago
Assignee: nobody → ehsan
Assignee

Updated

6 years ago
Attachment #8340012 - Flags: feedback?(fredbezies)
Assignee

Comment 26

6 years ago
I have $5 which says this is a dupe of bug 943839.
Depends on: 943839
Duplicate of this bug: 944247
Assignee

Comment 28

6 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!
Assignee

Updated

6 years ago
No longer depends on: 943839

Comment 29

6 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.
Attachment #8340012 - Flags: review?(kvijayan) → review+
Couldn't we detect the compiler in the mozbuild file and make this change conditional?
Assignee

Comment 32

6 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.
https://hg.mozilla.org/mozilla-central/rev/48a03977660e
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Assignee

Updated

6 years ago
Duplicate of this bug: 943463
Whiteboard: [qa-]
Reporter

Comment 35

5 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.