594571 - Autoupdate to 2.0.7 seems to be broken (crash on startup)

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, defect)

Description

[Bruno 'Aqualon' Escherl]

http://crash-stats.mozilla.com/products/SeaMonkey/versions/2.0.7

Lot's of crash reports on startup after autoupdate :-/

Comment 1

[Robert Kaiser]

I have temporarily pulled updates for 2.0.6 -> 2.0.7 - and I might have an idea what could be done to fix it.

Comment 2

[Robert Kaiser]

I don't have confirmation right now if that helps, but as bug 530447 suggests frankenbuilds of some sort and plays with compreg.dat maybe needing removal, I re-checked our removal of it on update and it turns out that the fool who did the bug 562047 patch (i.e. me) was confused as to the location of those files and didn't realize they live in components/ and not directly in the app dir.

Comment 3

[Robert Kaiser]

Attachment: comm-1.9.1 patch

I sincerely hope we get feedback that killing those files helps. If so, we'll do a firedill for this as fast as we can and go 2.0.8 even though the actual code won't change.

Comment 4

[Robert Kaiser]

Attachment: comm-central patch

Here's the same patch for c-c (context is slightly different)

Comment 5

[Robert Kaiser]

Pushes of the compreg/xpti patch:
http://hg.mozilla.org/comm-central/rev/e4fba053742f
http://hg.mozilla.org/releases/comm-1.9.1/rev/4702557ae9b2
http://hg.mozilla.org/releases/comm-1.9.1/rev/a1b25b5742ca

I'll wait for reports from people on if deleting the compreg.dat file helps them before I start a firedrill.

Comment 6

[Bruno 'Aqualon' Escherl]

So far one report from David E. Ross on http://groups.google.com/group/mozilla.support.seamonkey/msg/0b1b55e6e0d6bd42 that deleting compreg.dat helped.

Comment 7

[Bruno 'Aqualon' Escherl]

See also bug 594699.

Comment 8

[[e-mail]]

(In reply to comment #3)
> I sincerely hope we get feedback that killing those files helps. If so, we'll
> do a firedill for this as fast as we can and go 2.0.8 even though the actual
> code won't change.
I guess 2.0.6 -> 2.0.8 won't be an incremental update...

Comment 9

[Robert Kaiser]

(In reply to comment #8)
> I guess 2.0.6 -> 2.0.8 won't be an incremental update...

Unfortunately no.

Comment 11

[Uli Link (:ul-mcamafia)]

(In reply to comment #9)
> (In reply to comment #8)
> > I guess 2.0.6 -> 2.0.8 won't be an incremental update...
> 
> Unfortunately no.

And a 2.0.7 Build2 isn't a clean solution, but those who hasn't got the automatic update by now will get a working incremental update and those who have updated without problems aren't affect either... Just a thought (and staying in sync with Thunderbird 3.0 version numbers).

Comment 12

[Robert Kaiser]

(In reply to comment #11)
> And a 2.0.7 Build2 isn't a clean solution

You name it. Version numbers are cheap, matching TB was nice but a coincidence in the end, and I'd rather tell users to "install 2.0.8" than to "install the newer variant of 2.0.7" - apart from that's it's not trivial to exchange files on the mirror system and still ensure it matches what we think it does.

The message to users must be clear in the way that 2.0.8 solves the problem - even if that means that anyone shipping things more cleanly (e.g. Linux distros, where this file won't be written into the app dir in the first place) will have to either stay at 2.0.7 or ship a basically null-update to 2.0.8 just for the number - code-wise and security-wise, it will not matter.

Comment 13

[Robert Kaiser]

bug 594837 is tracking the oilspill release, bug 594699 the other thing behind this crash, so let's mark this one fixed.