:-) 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.
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
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
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
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.
*** Bug 129567 has been marked as a duplicate of this bug. ***
I'm seeing the same thing on Solaris 8 sparc platform. Suggest Platform -> all ?
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.
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?
*** Bug 130375 has been marked as a duplicate of this bug. ***
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.....
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?
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.
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.
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. ***
Duping with 118846, as suggested. *** This bug has been marked as a duplicate of 118846 ***