Closed Bug 118846 Opened 23 years ago Closed 22 years ago

mozilla hangs after installation of patch 108652-47 for Solaris 8

Categories

(SeaMonkey :: Build Config, defect, P4)

Product:
SeaMonkey
Component:
Build Config
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: klaus.braun, Assigned: netscape)

References

Details

(Keywords: hang, qawanted)

Attachments

(1 file)

Patch to run-mozilla.sh to increase Shared Memory Transport size (Soalris)
300 bytes, patch
netscape
: review+
jesup
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.8 sun4u)
BuildID:    2001122204

After updating Solaris 8 with patch 108652-47 (X11 6.4.1: Xsun patch)
on a SUN Blade 1000, mozilla 0.9.6 and mozilla 0.9.7 are starting, 
but after some mouse clicks (two or three) they hang.


Reproducible: Always
Steps to Reproduce:
1. Use Solaris 8 with patch 108652-47 on a SUN Blade 1000
2. Start mozilla 0.9.7
3. Click some links

Actual Results:  The browser window dosn't respond to any mouse click if I try
to
follow a link

Expected Results:  mozilla should show the expected page
Keywords: qawanted
QA Contact: sairuh → nobody
Summary: mozilla hangs after installation of patch 108652-47 for Solaris 8 → mozilla hangs after installation of patch 108652-47 for Solaris 8
Keywords: hang
Related to bug 111555, which is also about Sun Blades?
Bug 118846 is *not* related to bug 111555. Mozilla doesn't crash
because of relocation errors, it hangs because of something goes
wrong with the Xserver
->layout
Assignee: trudelle → attinasi
Component: XP Apps → Layout
QA Contact: nobody → petersen
Hmm. What makes trudelle think this is layout?  Is there a stack trace pointing
to layout? Some info would be cool.  I don't have a Solaris machine anyway...

Back to Browser General so we can get some traige on this.  It is unlikely to be
layout, and I already have 250+ untriaged bugs.
Assignee: attinasi → asa
Component: Layout → Browser-General
QA Contact: petersen → doronr
My tests about this problem show the following:

The binary I got from www.mozilla.org is compiled
against libgtk-1.2.so.0. In my version of this library
I disabled shared memory support (--disable-shm) because 
of some restrictions in Solaris 8. After compiling 
libgtk-1.2.so.0 with shared memory support emabled, 
mozilla works. 

So, are there any recommendations for using mozilla
on a Solaris 8 platform concerning shared memory
configuration etc.?

Sorry for lost time

Klaus

adding some build people.  Who builds the solaris binary?
Maybe we need to change something on our end.
->build
Assignee: asa → seawood
Status: UNCONFIRMED → NEW
Component: Browser-General → Build Config
Ever confirmed: true
QA Contact: doronr → granrose
The milestone builds for sparc solaris are contributed.  Our nightly builds have
been non-existant for over a month due to bug 106009.  

Klaus, what's the full URL to the build that you downloaded?

Cc'ing some solaris people.  I don't remember the full story on the shm issue. 
 Would it make a difference if Mozilla was compiled against a xshm enabled gtk
and then run against a non-xshm gtk?

Reporter:
1. What does
-- snip --
% showrev -p | fgrep 108652-
-- snip --
say on your box ?
2. Does backing-out the Xsun patch 108652-47 help (man patchrm) ?
3. Which version of GDK/GTK+ libraries do you use (you must have at least 1.2.8
of glib/GTK+ (that's the same I am using) or you are in trouble (use gtk-config
--version; glib-config --version # to query the versions)...) ?
Priority: -- → P4
Target Milestone: --- → Future
I see a similar problem using mozilla 0.9.8 and  solaris 8 **x86**, with patch
108653-29 installed.
THis is the x86-equivalent patch to the Xsun jumbo 108652 patch

Just to answer Roland. Backing out 108652-47 (or -46) to -40 does cause the
problem to go away. This bug seems suspiciously like 124377.
1. What does
-- snip --
% showrev -p | fgrep 108652-
say on your box ?

--->
Patch: 108652-23 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWxwfnt,
SUNWxwice, SUNWxwplt, SUNWxwicx, SUNWxwplx, SUNWxwinc, SUNWxwman, SUNWxwpmn,
SUNWxwslb
Patch: 108652-40 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWxwfnt,
SUNWxwice, SUNWxwplt, SUNWxwicx, SUNWxwplx, SUNWxwdxm, SUNWxwinc, SUNWxwman,
SUNWxwpmn, SUNWxwslb
Patch: 108652-47 Obsoletes: 110499-03 Requires:  Incompatibles:  Packages:
SUNWxwfnt, SUNWxwice, SUNWxwplt, SUNWxwicx, SUNWxwplx, SUNWxwdxm, SUNWxwinc,
SUNWxwman, SUNWxwpmn, SUNWxwslb
Patch: 108919-05 Obsoletes:  Requires: 108652-19 Incompatibles:  Packages: SUNWdtdte
Patch: 109354-05 Obsoletes:  Requires: 108652-19 Incompatibles:  Packages:
SUNWdtdte, SUNWdtwm
Patch: 108921-08 Obsoletes:  Requires: 108652-19 Incompatibles:  Packages: SUNWdtwm


2. Does backing-out the Xsun patch 108652-47 help (man patchrm) ?

-> yes, but only on test-systems.
after some testing we apply the rec. patches without save-function or only save
the actual cluster-update.
the other admins don't want to backout this patch and will apply it on future
updates. so noone with a solaris-system and the newer rec.patches installed can
use mozilla at our institute.


3. Which version of GDK/GTK+ libraries do you use (you must have at least 1.2.8
of glib/GTK+ (that's the same I am using) or you are in trouble (use gtk-config
--version; glib-config --version # to query the versions)...) ?

-> 1.2.10, with shared memory support enabled. we make a new compilation of
glib/gtk for testing, same problem!



any further ideas?
carsten
... and same problem with 0.9.9

Does it help when mozilla gets forced to use only one CPU (see pbind(1M) manual
page) ?
I've been seeing this same failure. I've tried an xlib build (0.9.9), as
recommended in bug #124377, and that works buch better.

I also note that the last GTK build that worked for me was a CVS build on
Feb 4.

showrev -p | fgrep 108652-
Patch: 108652-15 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWxwfnt,
SUNWxwplt, SUNWxwinc, SUNWxwman, SUNWxwpmn, SUNWxwslb
Patch: 108652-37 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWxwfnt,
SUNWxwice, SUNWxwplt, SUNWxwdxm, SUNWxwinc, SUNWxwman, SUNWxwpmn, SUNWxwslb
Patch: 108652-46 Obsoletes: 110499-03 Requires:  Incompatibles:  Packages:
SUNWxwfnt, SUNWxwice, SUNWxwplt, SUNWxwdxm, SUNWxwfa, SUNWxwinc, SUNWxwman,
SUNWxwpmn, SUNWxwslb
Patch: 108921-13 Obsoletes:  Requires: 108652-19 Incompatibles:  Packages: SUNWdtwm

solved this problem here by setting the environment variable XSUNTRANSPORT to
shmem and XSUNSMESIZE to 512. I don't think it's a mozilla bug - you can make
other applications hang by setting a small XSUNSMESIZE (the default is 64, e.g.
acroread hangs at startup with 32).

At least I hope that fixed it - the crashes weren't that frequent here, so I
need more time for confirmation.

thanks!

i changed 'run-mozilla.sh':
--->
## Solaris Xserver(Xsun) tuning - use shared memory transport if available
if [ "$XSUNTRANSPORT" = "" ]
then 
        XSUNTRANSPORT="shmem" 
        # XSUNSMESIZE="64"
        XSUNSMESIZE="1024"
        export XSUNTRANSPORT XSUNSMESIZE
fi
<----


please change the size to at least 512k in the 1.0 solaris-release.


what is an optimum size for mozilla with 24bit-display?
it is said, that sizes up to 8192k could make sense.

<A
HREF="http://groups.google.de/groups?q=XSUNSMESIZE&hl=de&ie=ISO-8859-1&oe=ISO-8859-1&selm=35D7B8D1.83588DF5%40pattosoft.com.au&rnum=1>google:
XSUNSMESIZE...</A>


cu, carsten
1. Are you really sure that setting XSUNSMESIZE to "1024" does not disabled it
(silenty) due the size restriction of shared memory segements ?
2. Did anyone contact Sun yet and asked for a fix for this issue ?
*** Bug 139505 has been marked as a duplicate of this bug. ***
I also was having problems w/ random hangs after clicking on links, and w/
acrobat and realplayer8 hanging under mozilla.

setting 
         XSUNSMESIZE="8192"
has fixed the problem for me, too.

I'm on solaris 8 (sparc),and  108652-47 is installed.
i've foudn a page that will cause mozilla (Mozilla/5.0 (X11; U; SunOS sun4u;
en-US; rv:1.0rc1) to hang every time when XSUNSMESIZE="64"

http://www.angelfire.com/mi3/eaglegym/eagleteam.html

this page contains 25 or so very large images that are resized down with
height=xxx width=xxx tags. pick an image and do 'view image' on it. instant hang.

setting XSUNSMESIZE="8192" prevents the hang

I'm new to the mozilla project...what do we need to do to ensure this is fixed
before 1.0 goes final?

-j
i can't understand why this setting not fixed yet!
you can reproduce this bug definitively.

many people think, mozilla is still unstable and 'simple' don't use it after the
first hang.

question: what xmemsize should we prefer?
we don't have any problems with 1024 till yet (link above not tested)


thanks,
carsten
> i can't understand why this setting not fixed yet!

> I don't think it's a mozilla bug - you can make
> other applications hang by setting a small XSUNSMESIZE (the default is 64, e.g.
> acroread hangs at startup with 32).

That's one reason why it's not fixed. It doesn't appear to even be a mozilla
bug. And the problem is not universal.

> i can't understand why this setting not fixed yet!
> question: what xmemsize should we prefer?

There's another reason. Can't agree upon the proper fix (ie xmemsize).

To reiterate Roland's question, has anyone filed a bug with Sun about this? 

Are we going to cause some other performance issues by bumping up the xmemsize
so high? Or as Roland asked, is it being silently turned off?

Before we go and make a change, someone should a) make sure that there are no
side-effects from such a change, b) provide a patch for the exact change to be
made and c) explain exactly what the change does & is supposed to fix. 
> There's another reason. Can't agree upon the proper fix (ie xmemsize).
> Are we going to cause some other performance issues by bumping up the xmemsize
> so high? Or as Roland asked, is it being silently turned off?
From the Solaris Handbook for Sun Frame Buffers:
http://www.sun.com/products-n-solutions/hardware/docs/pdf/806-6054-10.pdf
Performance Notes, p.50: "...Different request buffer sizes can be specified.
However, 512 is a good compromise between the transport speed and the system
memory resources consumed".(It is mentioned on 24-bit visuals it might be
necessary to increase this size, for instance x11perf will not run with a too
small size... interesting stuff, though I don't think that's the same reason why
mozilla crashes).
But IMHO it would be best just to remove those settings from run-mozilla.sh and
let the user/sysadmin tweak the system.
(Or doesn't it work without it? I think it's just marginally slower without
shm?). Or, if that's not an option, I'd suggest the sun recommended value (512),
that should be enough for the time being (in fact, I've set it to 128 for
several weeks and never experienced a single hang).

I completely agree however that this bug, mozilla's fault or not, has to
disappear in mozilla 1.0.

> Before we go and make a change, someone should a) make sure that there are no
> side-effects from such a change,
(assuming the XSUNSMESIZE is increased to 512) there shouldn't be any (negative)
side effects, since this is the recommended value - it should even provide some
(probably very small) speed improvements. The only downside is it will probably
use half a MB of ram, and it might potentially hide a bug which is very apparent
otherwise (because of the constant crashes). But this bug is just too severe to
let it stay this way.

> b) provide a patch for the exact change to be made
change XSUNSMESIZE in run-mozilla.sh to "512"

> and c) explain exactly what the change does & is supposed to fix. 
makes mozilla usable on affected systems :-)


btw has anybody tried the newest sun patches (even if it's fixed, that wouldn't
change my opinion I said above, however)?


I forgot to mention the max shared memory segment size by default is 1MB on
Solaris (which is far too low for a lot of things today on multi-GB
machines...), so XSUNSMESIZE=512 should work, but 8192 would not (not sure what
happens, might be switched off or just use a smaller value). (Of course that
limit can be changed, in /system/etc set shmsys:shminfo_shmmax=2147483648, but
obviously mozilla can't. You can see the current limit with /usr/sbin/sysdef -i.)
Sorry for writing another time, but to fortify the importance of this bug, there
are already a lot of dupes of that bug out (some of them are already mentioned
in the comments) - all assigned to different people :-)
118846 (this one here)
128495 (http://bugzilla.mozilla.org/show_bug.cgi?id=128495)
126310 (http://bugzilla.mozilla.org/show_bug.cgi?id=126310)
124377 (http://bugzilla.mozilla.org/show_bug.cgi?id=124377)
117679 (http://bugzilla.mozilla.org/show_bug.cgi?id=117679)
(of course I have only mentioned those not already duped together, and I'm very
confident these are really dupes).

Sun has some entries in sunsolve about this as well. One specifically mentions
mozilla:

http://sunsolve.Sun.COM/private-cgi/retrieve.pl?type=0&doc=bug%2Fxserver%2Fclient_libs%2F4520338
says:

Disable the Xsun shared memory transport by:
Setting DISPLAY to something equivalent to ":0.0" but with different semantics.
 "localhost:0.0" or "hostname:0.0" avoids the problem.

-or- 

Set XSUNSMESIZE to a larger value, such as 128 (in the mozilla case, this
requires setting XSUNTRANSPORT=shmem in the environment as well, since
run-mozilla.sh will reset XSUNSMESIZE to 64 if XSUNTRANSPORT is not set)



just a note to say that I have tried patch version -51 with mozilla 0.9.9 and it
still has the same problem. And the change to the SHM size still works around
the problem. I have not tried 1.0rc1 with the patch and withouth the SHM size
change.   But don't hold your breath.
Would it be possible for someone to tag this with the mozilla1.0 keyword please?
Ok. Please excuse the rant, but I'm really underwhelmed by things here.

This bug has been open since January. This bug causes mozilla on solaris to hard
hang, very reliably. This bug could be fixed by changing 2 or 3 characters in
the run-mozilla.sh script.

This bug caused me to abandon earlier betas multiple times, until I took the
time to search for the problem. I'm sure it's put other potential users off as well.

What is the problem with getting this fixed before 1.0 ships? 

Doing ANYTHING at this point will be better than doing nothing. Lets either turn
 SHM off or increase it to what Sun suggests as a minimum.

Someone who can make this happen, please step forward....

-j
i think the size should be two steps over the size mozilla crashes.
to test i open at least about 30 pages (as background tabs) of
heise.de/newsticker and spiegel.de - news :)

we use 1024 at 24bit with no hangs anymore.
i will make tests with 128 & 512 next days.

is this shmmax sun installation-standard? ->
/etc/system:
set shmsys:shminfo_shmmax = 8388608
This is a tested fix for this bug. I've been running for 2+ weeks w/o any
hangs.
repeating what was said previously for clarity:

from http://www.sun.com/products-n-solutions/hardware/docs/pdf/806-6054-10.pdf

Direct Xlib
Direct Xlib is not supported on the Creator accelerator. The X shared memory
transport feature (new in Solaris 2.5) should be used instead. To enable shared
memory transport, set the following environment variables in the client
environment:
Note – The last line specifies a client request buffer size of 512 kilobytes.
Different
request buffer sizes can be specified. However, 512 is a good compromise between
the transport speed and the system memory resources consumed.
Applications that rely on XPutImage and Direct Xlib for fast pixel transfer into
the frame buffer should instead use the MITSHM extension function XShmPutImage
on the Creator accelerator. This function provides the fastest transfer of
pixels into the
frame buffer when the client is on the same machine as the X server.

If you are using XShmPutImage to a 24-bit visual, you may need to increase the
amount of allocated shared memory beyond the default amount. See “The X11perf
Benchmark” on page 51” for details.

setenv DISPLAY :0
setenv XSUNTRANSPORT shmem
setenv XSUNSMESIZE 512

based on this, i will be submitting a patch to change XSUNSMESIZE to 512
Comment on attachment 83275 [details] [diff] [review]
Patch to run-mozilla.sh to increase Shared Memory Transport size (Soalris)

r=cls
Attachment #83275 - Flags: review+
Patch has been checked into the trunk.
Blocks: 138348
Keywords: mozilla1.0
Whiteboard: [fixed on trunk]
Target Milestone: Future → mozilla1.0
I am currently building a Solaris 7_8_9 RC2 distribution and after that is built
we should test to see if this patch " is a must have " for 1.0 .

dcran
*** Bug 117679 has been marked as a duplicate of this bug. ***
*** Bug 128495 has been marked as a duplicate of this bug. ***
*** Bug 130571 has been marked as a duplicate of this bug. ***
Comment on attachment 83275 [details] [diff] [review]
Patch to run-mozilla.sh to increase Shared Memory Transport size (Soalris)

a=rjesup@wgate.com
Attachment #83275 - Flags: approval+
The patch has been checked into the moz1.0.0 branch
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Keywords: fixed1.0.0
Whiteboard: [fixed on trunk]
My guess is that the patch to this bug caused bug 144623 which crashes all Flash
pages for me on Sparc builds on the trunk and branch.
I just installed the Flash plugin and reduced shared memory back to 64 with:

XSUNSMESIZE="64"

and it still crashes for me with:

mila{jwasilko}141: ./run-mozilla.sh 
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  131 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Serial number of failed request:  67
  Current serial number in output stream:  67

So I don't think the patch for bug 118846 has anything to do with this. Looks
like the flash plugin is busted.
Oops, ignore my last comment. The bug shows up in RC2, but this patch is
post-RC2. Might be related though.
*** Bug 123871 has been marked as a duplicate of this bug. ***
*** Bug 119476 has been marked as a duplicate of this bug. ***
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: