233863 - Recommended patches for Mozilla on Solaris need updating

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Mick Kelleher]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.6) Gecko/20040209 Firefox/0.8

I've noticed a problem when a compiled Mozilla 1.6 on Solaris can crash on
Solaris machines even if they have the recommended Solaris patches in
'Installation Instructions for Mozilla Ports' page at
http://www.mozilla.org/releases/mozilla1.6/installation-ports.html
I am compiling Mozilla on Solaris 8 with the latest recommended patch cluster
and the following addtional patches...
108434-14  108435-14  108773-18  109147-27  111697-04  111721-04

The machines the build crashes have at least the minimum patch revisions on the
Mozilla web page but they don't seem to be enough. I have a suspicion that patch
111721-04 (Solaris 8) and 111722-04 (Solaris 9) for Math Library could be the
culprit as they include support for new data types for which Solaris machines
without that patch would'nt be able to support.

I can't exactly say which patch is definitly causing the problem as when Mozilla
started to crash for me i had it fully deployed in my department, and i updated
the patch revisions for Solaris 8 and 9 to their latest versions and sent them
out to all machines to stop people screaming at me

I think the web page detailing the Solaris recommended patches will have to be
updated and possibly the list of patches in the patch checker in Bug ID: 230598
which has just been checked into the 1.7 branch.

This problem came up in the discussion for Bug ID: 230598 and Roland Mainz
([e-mail]) asked if he could be assigned this bug as he is the
person who did the list of recommended patches for Solaris and will look into
this patch problem.

Reproducible: Always
Steps to Reproduce:
1. Compile Mozilla on Solaris machine with latest C++, linker and math libraries.
2. Try running Mozilla on a Solaris machine without those patches.
3.

Actual Results:  
Mozilla began to crash frequently

Expected Results:  
Mozilla should'nt crash

Comment 1

[Roland Mainz]

Taking myself...

Comment 2

[Roland Mainz]

Attachment: Step 1 - update the patch checker (patch for 2004-03-24-trunk)

The patch updates the patch lists in the patch checker per user feedback and
own investigations, adds support for Solaris/x86 and fixes a nit caused by the
changes in the "pluggable shell script framework" API.

Comment 3

[Mike Kaply [:mkaply]]

Comment on attachment 144627 [details] [diff] [review]
Step 1 - update the patch checker (patch for 2004-03-24-trunk)

a=mkaply

Comment 4

[Mike Kaply [:mkaply]]

Patch checked in.

Comment 5

[Mick Kelleher]

Hi Roland,

I've tested those patches you have recommended on Solaris 8 & 9 for SPARC (i
hav'nt had a Solaris 7 system for a long time) and Solaris 9 for X86. The
patches you have recommended work with fine with Mozilla, Firefox, and Thunderbird.
I've have asked my users to check as many of their applications as possible to
see if the combinations of patches cause any unforseen problems with other
applications.
Thanks for the effort you have put in testing the combinations of patches, it
must have been an awful job testing that many patches.

Mick.

Comment 6

[Roland Mainz]

Reopening... step 2 is to update the WWW docs...

Comment 7

[Mats Larsson]

Will you find to update the WWW docs the time before 1.7 is released? Looks a
lot more professional if they're in sync with the patch checker.

Comment 8

[Chris P. Ross]

I'd like to complain about one thing.  For SPARC/Solaris8, this patch requires
109704-03 (or later).  My system only has 109704-02, so I get a complaint. 
However, patch 109704 is not freely available from Sun.  Their web server lists
it as only available to people with Sun Support contracts.
I don't think we should warn people about problems they can't necessarily solve.

Comment 9

[Roland Mainz]

Chris P. Ross wrote:
> I'd like to complain about one thing.  For SPARC/Solaris8, this patch requires
> 109704-03 (or later).  My system only has 109704-02, so I get a complaint. 
> However, patch 109704 is not freely available from Sun.  Their web server 
> lists it as only available to people with Sun Support contracts.
> I don't think we should warn people about problems they can't necessarily 
> solve.

Erm... http://sunsolve6.sun.com/search/document.do?assetkey=109704 is available
for the public. Which problem do you have with that ?!

Comment 10

[Chris P. Ross]

That is available to me, I agree.  But, without that URL, it wasn't.  If I go to
www.sun.com, click "downloads" then click "patches & updates" then click
"solaris[..]", then "Patch portal".  I then enter "109704" (or "109704-03") into
the patch number text-box, and click search, I get a page reporting that it's
only available to people with contracts.
What did you do to get to that URL in the first place?

Comment 11

[Ken Takusagawa]

The CVS log for revision 1.3 of moz_patch_checker.dtksh refers
to bug 233683 instead of this one; i.e. two digits were flipped.

Comment 12

[Ken Takusagawa]

I'd like to complain about:

"113902-03" [6_title]="SunOS 5.9: Asian UTF-8 iconv modules enhancement
"114276-02" [7_title]="SunOS 5.9: Extended Arabic support in UTF-8"
"114641-02" [8_title]="SunOS 5.9: Japanese iconv for UTF-8 patch"

These seem to be patches to packages containing the Asian iconv
modules for UTF-8, and Arabic fonts, none of which we use.

The patch checker shouldn't ask for patches for language
support when the underlying language support is not present or used.

Comment 13

[Roland Mainz]

[e-mail]  wrote:
> The patch checker shouldn't ask for patches for language
> support when the underlying language support is not present or used.

The script really can't predict any future behaviour of the users. Really, we
don't have a way to read tea leaves from within dtksh.

The intention behind the patch checker was to avoid that people (which means:
the "average" user in the _world_, not only within the US. This includes
customers within the EU, Japan, Middle-East etc.) start filing bogus bugs
because they hit (already fixed, incl. patches available) OS bugs (that goal has
been reached, the number of bogus bug reports has dropped significantly :) ...
we had enougth trouble with that in the past.

If you don't want the patch checker then either hit simply "Continue" or take a
look at
http://lxr.mozilla.org/mozilla/source/xpfe/bootstrap/init.d/S02solaris_patchchecker.sh#19
- there is a way to turn this OFF via a "secret" way.

Comment 14

[Roland Mainz]

Ken Takusagawa wrote:
> The CVS log for revision 1.3 of moz_patch_checker.dtksh refers
> to bug 233683 instead of this one; i.e. two digits were flipped

Ouch... sorry... ;-(

Comment 15

[Greg Onufer]

(In reply to comment #13)
> The script really can't predict any future behaviour of the users. Really, we
> don't have a way to read tea leaves from within dtksh.

Sure, but if the packages aren't installed then the patches shouldn't be
checked.  You can't patchadd a patch for which none of the packages are installed.

Ken, is that what you are concerned about?

Comment 16

[Roland Mainz]

Greg Onufer wrote:
> (In reply to comment #13)
> > The script really can't predict any future behaviour of the users. Really, 
> > we
> > > don't have a way to read tea leaves from within dtksh.
>
> Sure, but if the packages aren't installed then the patches shouldn't be
> checked.  You can't patchadd a patch for which none of the packages are 
> installed.

Erm, how do you think should this be solved ? The names of the packages to be
patched are variable between the single patch _revisions_ - it would mean that I
have to track all revisions of a patch and the packages patched by the specific
patch revision. That will be a nightmare.

Comment 17

[Ken Takusagawa]

(In reply to comment #15)
> You can't patchadd a patch for which none of the packages are installed.
> 
> Ken, is that what you are concerned about?

Yes.

Comment 18

[Andrew Sutherland [:asuth] (he/him)]

moz_patch_checker.dtksh has been removed on the trunk by bug 380786.  Since this bug was reopened (from FIXED) for reasons of the www docs not being in sync, and the www docs are now moot, I am restoring the state to FIXED.

(The script still exists on the Mozilla 1.8 branch, but unless someone brings (new) resources to bear on a 1.8-only issue, there is no point in keeping this bug or its friends open.  If you have resources to bring to bear, it is probably more appropriate to re-open one of the other bugs related to the script, or to log an entirely new one.)