If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED DUPLICATE of bug 118846

Status

SeaMonkey
General
--
critical
RESOLVED DUPLICATE of bug 118846
16 years ago
13 years ago

People

(Reporter: AKI74, Assigned: asa)

Tracking

Trunk
x86
Solaris

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
:-)
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

16 years ago
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
(Reporter)

Comment 2

16 years ago
Created attachment 72454 [details]
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
(Reporter)

Comment 3

16 years ago
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
(Reporter)

Comment 4

16 years ago
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

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

Comment 6

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

Comment 7

16 years ago
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

16 years ago
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

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

Comment 10

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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.
*** Bug 138096 has been marked as a duplicate of this bug. ***

Comment 16

16 years ago
Duping with 118846, as suggested.

*** This bug has been marked as a duplicate of 118846 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.