128495 - Solaris 8_x86 6/01 + Recommended_patches (01/03/2002) causes hangup of Mozilla0.9.8

Status: RESOLVED DUPLICATE of bug 118846

(SeaMonkey :: General, defect)

Description

[AKI74]

:-)
Solaris 8_x86 6/01, Mozilla 0.9.8 (build 01/03/2002 and earlier)
Before applying any patches to OS worked fine.
After installing Recommended_patches 01/03/2002 Mozilla usualy causes 100%
utilization and hangs up during transferring webpages.

Comment 1

[Roland Mainz]

Reporter:
Can you provide some stack snapshots of "mozilla", please (attach them as file,
please (e.g. click on
http://bugzilla.mozilla.org/attachment.cgi?bugid=128495&action=enter)) ?

Example:
# Get PID (Process ID of running Zilla)
% pgrep mozilla-bin
19339
# Get five stack trace samples from the running process
% i=0 ; while [ $i -lt 5 ] ; do i=$(($i + 1)) ; /bin/echo "#### snapshot $i
##\n\n" ; /usr/proc/bin/pstack 19339 ; sleep 1 ; done

Comment 2

[AKI74]

Attachment: stack snapshots of "mozilla"

five stack trace samples from the running process

%i=0 ; while [ $i -lt 5 ] ; do i=$(($i + 1)) ; /bin/echo "#### snapshot $i
##\n\n"\ ; /usr/proc/bin/pstack `pgrep mozilla-bin` ; sleep 1 ; done

Comment 3

[AKI74]

I'm not sure but I observed that bug several times when running mozilla in the
full-screen mode or switching to that mode. In a smaller window it seemed to
work better.
Marek Kozlowski

Comment 4

[AKI74]

Oups! Comment #3 should be as follows:

I'm not sure but I observed that bug several times when running mozilla in the
full-screen WINDOW or switching to that WINDOW. In a smaller window it seemed to
work better.

I ment: full-screen window not full-screen mode.

Comment 5

[Dave Booth]

*** Bug 129567 has been marked as a duplicate of this bug. ***

Comment 6

[Dave Booth]

I'm seeing the same thing on Solaris 8 sparc platform. 
Suggest Platform -> all ?

Comment 7

[Dave Booth]

This looks like it could be the shmem issues in bug 126310 and bug 130375

I just applied the same workaround and 0.9.9 just became usable.

Comment 8

[Paul Boven]

I created bug 130375 but should mark it duplicate of this one, I guess. There
are more bugs like this, maybe they should all be marked dupe and bug 68570
reopened?

Comment 9

[Paul Boven]

*** Bug 130375 has been marked as a duplicate of this bug. ***

Comment 10

[Dave Booth]

bug 68570 probably shouldnt be reopened (IMHO) - At the time it was open adding 
the shmem transport option was worth doing. This and the cohort of similar bug 
reports that have resulted from the bustage of this post-OS-patch should 
probably be rolled into a single bug report for tracking purposes but I confess 
to wondering whether this is a bug in the lizard or a bug in the Sun patch.....

Comment 11

[Paul Boven]

This bug seems a shared library problem.
There are two libgtk+ on my system: one in /opt/sfw/lib (from the Sun Freeware
CD) and one in /usr/sfw/lib (from the Netscape 6.2.1(beta) pkg from Sun). (Why
do we have two different libgtk? diff says they are different).
By making /usr/sfw/lib come before the /opt/sfw/lib one in your LD_LIBRARY_PATH,
the shmem problem goes away. So you can run Mozilla without the workarounds, and
who knows, it might even use shared-memory transport.
And now for the bad news: when launching realplayer from mozilla after changing
your LD_LIBRARY_PATH, it goes into a loop (lwp_mutex and lwp_sema stuff). And
guess what, setting XSUNTRANSPORT to noshmem again makes Realplayer work again.
So some progress.. but not quite there yet. (Flash works)

By the way, these findings are all on Sparc, could someone perhaps change this
bug to all platforms instead of only intel so others can find it too?

Comment 12

[Donnie Cranford]

I never use realplayer for solaris, (honestly I never use realplayer), so I cant
actually replicate the problem. But it is nice to hear that the shared lib
problem is what is causing this mess, which was my original thoughts as well.

Comment 13

[Dave Booth]

wasnt just realplayer for me, was unpredictable freezes doing all sorts of 
things, but the same workaround fixed it. I dont have suns netscape beta on 
this box so I cant test with that libgtk but can confirm it doesnt work with 
the one in /opt/sfw/lib, nor with the one included with the latest ximian gnome 
for solaris.

Comment 14

[Paul Boven]

Workarounds to work around the workarounds:
Using the /usr/sfw/lib GTK and build 2002032110 I very very rarely still run
into the X-looping bug.
After reading bug 118846 I've set XSUNSMESIZE="1024" which makes things more
stable, and now the RealPlayer plugin works again, too.
Hypothesis: if the one GTK is shmem-enabled, the other not, might cause us to
run out of the SHMEM-area much earlier. This seems the nicest workaround so far,
but see also the concerns at the end of bug 118846.
This bug and that should probably be duped together.

Comment 15

[Matthias Versen [:Matti]]

*** Bug 138096 has been marked as a duplicate of this bug. ***

Comment 16

[Jim Crumley]

Duping with 118846, as suggested.

*** This bug has been marked as a duplicate of 118846 ***