[SeaMonkey 2.1, Windows] Shared/Hourly builds don't start anymore: packaging issue

VERIFIED FIXED in seamonkey2.1a1

Status

SeaMonkey
Build Config
--
critical
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: sgautherie, Assigned: sgautherie)

Tracking

({crash, regression})

Trunk
seamonkey2.1a1
x86
Windows 2000
crash, regression
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Fixed by blocking bugs...])

(Assignee)

Description

8 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20090925 SeaMonkey/2.1a1pre] (nightly) (W2Ksp4)

Works fine.

***

/pub/seamonkey/nightly/2009/09/2009-09-25-01-comm-central-trunk

Error dialog during startup:
{
JavaScript Application
Error launching browser window:no XBL binding for browser
}

It can also crash with some parameters: I sent a few crash reports.

***

/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1253914288 (26 00:05)
/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1253955519 (26 12:03)
/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1253998624 (26 23:59)

Start to load then process just dies: no error, no nothing :-(
(Assignee)

Comment 1

8 years ago
(In reply to comment #0)
> Error dialog during startup:
> {
> JavaScript Application
> Error launching browser window:no XBL binding for browser
> }

Same with:
/pub/seamonkey/nightly/2009/09/2009-09-27-00-comm-central-trunk
(Assignee)

Updated

8 years ago
Summary: SeaMonkey 2.1 don't load (at all) anymore → SeaMonkey 2.1 don't load (at all) anymore: "Error launching browser window:no XBL binding for browser"
(Assignee)

Comment 2

8 years ago
(In reply to comment #0)
> /pub/seamonkey/nightly/2009/09/2009-09-25-01-comm-central-trunk

/pub/seamonkey/nightly/2009/09/2009-09-26-00-comm-central-trunk !

***

Regression timeframe:
nightlies: (17h25)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=def6be3d8b6b&tochange=e109f9a3b6ee
tinderboxes: (11h08)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=def6be3d8b6b&tochange=1aaedcad1634
local: (4h32, but failure not yet reproduced)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=614e3c4ba3c1&tochange=1aaedcad1634
(Assignee)

Comment 3

8 years ago
(In reply to comment #2)
> local: (4h32, but failure not yet reproduced)
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=614e3c4ba3c1&tochange=1aaedcad1634

local: (4mn, 2 changesets)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ef7c0074486&tochange=1aaedcad1634
Hum, quite unlikely.
Would it be a packaging issue?
(Assignee)

Comment 4

8 years ago
(In reply to comment #3)

> change=614e3c4ba3c1
> change=3ef7c0074486
> Would it be a packaging issue?

Indeed: run from dist/bin, fail from dist/seamonkey.
(Assignee)

Comment 5

8 years ago
Then my first guess was right: bug 514665.

And it even seems it was expected :-/
{
Comment #13 From  Phil Ringnalda (:philor)   2009-09-27 13:18:28 PDT

Both of suite's manifests need more, yeah, but I intentionally only fixed
suite's issues that were fallout from this bug, so only Windows.
}
Blocks: 470184, 514665
Component: General → Build Config
QA Contact: general → build-config
(Assignee)

Comment 6

8 years ago
Oh, I didn't pay attention but the c-c patch there just landed a moment ago ;->

Phil, Mark, what would be the additional things to do here?
(In reply to comment #6)
> Oh, I didn't pay attention but the c-c patch there just landed a moment ago ;->
> 
> Phil, Mark, what would be the additional things to do here?

Assuming this bustage was caused by that patch - then in theory this bug should be fixed. So nothing more to do.

At some stage looking at the package-compare output it looks like SeaMonkey's packages file needs some TLC for trunk at least, although considering they are built with tests it may take a bit to unpick what is test code and what isn't.
Oh, I didn't fix packaging of shared builds, because I can't make it stick in my head that you actually ship static nightlies and shared hourlies. Maybe if you rebranded them to be named Footgun it would be easier to remember that that's what they are?

So, since your tinderbox package-compare is pretty much useless, what someone (who is not me) needs to do is update, clobber their objdir, build --enable-shared, --disable-tests, make installer, make package-compare and find the things like tkitcmps.dll -> toolkitcomps.dll that aren't being packaged, add them to packages, and add the old things to removed-files.in ifdeffed so that you cover all the paths:

static 1.9.1 -> static mozilla-central
static 1.9.1 -> shared mozilla-central
static 1.9.1 -> shared 1.9.1
shared 1.9.1 -> static 1.9.1
shared 1.9.1 -> shared mozilla-central
shared 1.9.1 -> static mozilla-central

which you can then test by building all four installers, shared and static for both 1.9.1 and mozilla-central, install all four, then install them again and install the others over the top (because that's an easier way of testing removed-files.in than building updates), and diff -r the clean install and the over the top to be sure they wind up the same: install C:\shared-mozilla-central\, install a static 1.9.1 in C:\static-191-to-shared-mc\, install a shared mozilla-central on top, diff -r C:\static-191-to-shared-mc\ C:\shared-mozilla-central\, repeat with the other five.

Comment 9

8 years ago
We don't really care about shared builds in removed-files.in, it would only affect people who run the installer on hourlies to install over an old hourly, and those people are able to clobber their application directory once in a while.
Anyone on nightlies or releases after the point where we introduced static builds (2.0 alphas are at least to a part shared), whether he uses updater or installer, runs on static builds, and removed-files.in only needs to care about nightlies or releases.

Comment 10

8 years ago
I'm unsure of the relevance, if any, but as well as Seamonkey 2.1a1pre not loading for me, Shredder 3.1a1pre is also not loading. The crash reports are, to my untrained eye, very similar.

[url=http://crash-stats.mozilla.com/report/index/d6e6288f-9a8a-4be6-b936-a1b7f2090928]SM 2.1a1pre Crash Report[/url]
[url=http://crash-stats.mozilla.com/report/index/7cbfafc3-7a4e-4a7a-ac5d-cf28e2090928]Shredder crash Report[/url]

Comment 11

8 years ago
Sorry about that

Crash reports
SM 2.1a1pre
http://crash-stats.mozilla.com/report/index/d6e6288f-9a8a-4be6-b936-a1b7f2090928

Shredder 3.1a1pre
http://crash-stats.mozilla.com/report/index/7cbfafc3-7a4e-4a7a-ac5d-cf28e2090928

Comment 12

8 years ago
cannot reproduce with SM/20090928012538-trunk/WinXP

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.3a1pre) Gecko/20090928 SeaMonkey/2.1a1pre
(Assignee)

Comment 13

8 years ago
As expected:

(In reply to comment #8)
> I didn't fix packaging of shared builds, because I can't make it stick in
> my head that you actually ship static nightlies and shared hourlies.

/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32/1254139741 (28 14:53)
"Hourly" still dies silently.

(In reply to comment #12)
> cannot reproduce with SM/20090928012538-trunk/WinXP

/pub/seamonkey/nightly/2009/09/2009-09-28-01-comm-central-trunk
I confirm nightly is fixed :-)
Severity: blocker → critical
Keywords: crash
Summary: SeaMonkey 2.1 don't load (at all) anymore: "Error launching browser window:no XBL binding for browser" → [SeaMonkey 2.1, Windows] Shared/Hourly builds don't start anymore: packaging issue
(Assignee)

Comment 14

8 years ago
[] (comm-central-trunk-win32/1256246281) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/8d79c4a770ea
 +http://hg.mozilla.org/comm-central/rev/558474146a03)

"Hourly" still dies silently.
(Assignee)

Comment 15

8 years ago
[] (comm-central-trunk-win32/1256776662) (W2Ksp4)

Bug still there. (after first packaging clean-ups, much more to come...)
(Assignee)

Comment 16

8 years ago
[] (comm-central-trunk-win32/1257988947) (W2Ksp4)

Bug still there. (after 2 more packaging clean-ups, much more to come...)

Comment 17

8 years ago
The fun things is that we're routinely running package-compare on our normal build cycles but nobody seems to analyze the logs.

Here we go:

WINNT 5.2 comm-central-trunk build:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 10:42:13 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 10:42:13 -0800
-bin/components/appshell.dll
-bin/components/cmdlines.dll
+bin/components/commandlines.dll
-bin/components/gkparser.dll
+bin/components/htmlpars.dll
+bin/components/jsctypes.dll
+bin/components/msgAsyncPrompter.js
+bin/components/nsappshell.dll
-bin/components/perms.dll
+bin/components/permissions.dll
+bin/components/spellchecker.dll
-bin/components/spellchk.dll
-bin/components/strgcmps.dll
+bin/components/storagecomps.dll
-bin/components/tkautoc.dll
-bin/components/tkitcmps.dll
+bin/components/tkautocomplete.dll
+bin/components/toolkitcomps.dll
+bin/components/windowsproxy.dll
-bin/components/xpautoc.dll
+bin/components/xpautocomplete.dll
+bin/dependentlibs.list
+bin/extensions/inspector@mozilla.org/components/components.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list
-bin/jsj3250.dll

Linux comm-central-trunk build:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 10:02:49.000000000 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 10:02:49.000000000 -0800
+bin/components/libjsctypes.so
+bin/components/msgAsyncPrompter.js
+bin/dependentlibs.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list
+bin/extensions/inspector@mozilla.org/components/components.list
-bin/libjsj.so

WINNT 5.2 comm-central-trunk nightly:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 02:36:50 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 02:36:50 -0800
@@ -1,7 +1,8 @@
-bin/components/jar50.dll
+bin/components/msgAsyncPrompter.js
+bin/dependentlibs.list
+bin/extensions/inspector@mozilla.org/components/components.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list

Linux comm-central-trunk nightly:
--- ../../mozilla/dist/pack-list.txt	2009-12-11 01:49:59.000000000 -0800
+++ ../../mozilla/dist/bin-list.txt	2009-12-11 01:49:59.000000000 -0800
-bin/components/libjar50.so
+bin/components/msgAsyncPrompter.js
+bin/dependentlibs.list
+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list
+bin/extensions/inspector@mozilla.org/components/components.list


I cleaned out all things that I know are no concern. I'm pretty sure we need all the *.list files to make the stuff listed in them load at all.
(Assignee)

Updated

8 years ago
No longer blocks: 514665
Depends on: 514665
(Assignee)

Updated

8 years ago
Depends on: 528806
(Assignee)

Updated

8 years ago
Depends on: 534410
(Assignee)

Comment 18

8 years ago
(In reply to comment #17)
> +bin/components/msgAsyncPrompter.js

I filed bug 534528.
(Assignee)

Comment 19

8 years ago
There are remaining packaging issues to fix,
but, after (previous bugs/fixes and) bug 534410, this bug is mainly fixed: the tinderbox-builds start again :-)
Assignee: nobody → sgautherie.bz
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Whiteboard: [Fixed by blocking bugs...]
Target Milestone: --- → seamonkey2.1a1
(Assignee)

Comment 20

8 years ago
V.Fixed, by testing a few "hourlies" locally.
Status: RESOLVED → VERIFIED

Comment 21

8 years ago
(In reply to comment #19)
> There are remaining packaging issues to fix

Could you file bugs for those? I mainly wonder about the *.list files in my analysis and the removal of the jsj/jar50 libraries - and then the addition of the jsctypes binary component on the shared builds.
(Assignee)

Comment 22

8 years ago
(In reply to comment #21)
> Could you file bugs for those?

That's what I've been doing for some time now ... but I file bugs when I have figured out what each case is only!
(Assignee)

Comment 23

8 years ago
(In reply to comment #17)
> -bin/jsj3250.dll
> -bin/libjsj.so

I attached a patch to bug 521624.
(Assignee)

Comment 24

8 years ago
(In reply to comment #17)
> -bin/components/jar50.dll
> -bin/components/libjar50.so

I filed bug 534726.
(Assignee)

Comment 25

8 years ago
(In reply to comment #17)
> +bin/components/windowsproxy.dll

I filed bug 534917.
(Assignee)

Comment 26

8 years ago
(In reply to comment #17)
> +bin/components/jsctypes.dll
> +bin/components/libjsctypes.so

I filed bug 535231.
(Assignee)

Comment 27

8 years ago
(In reply to comment #17)
> +bin/extensions/inspector@mozilla.org/components/components.list
> +bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/components/components.list
> +bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/components/components.list

I filed bug 535320.
(Assignee)

Comment 28

8 years ago
(In reply to comment #17)

> The fun things is that we're routinely running package-compare on our normal
> build cycles but nobody seems to analyze the logs.

Sure, I would have expected it to warn/fail when there is something that needs attention :-/

> +bin/dependentlibs.list

I filed bug 535342.

> I'm pretty sure we need
> all the *.list files to make the stuff listed in them load at all.

No, see bug 526764 (related to comment 37).

***

NB: That's all for this list of files. I prefer when you fill separate bugs...

Comment 29

8 years ago
Thanks for working through the list, I'll try to get to the reviews as fast as I can.
You need to log in before you can comment on or make changes to this bug.