From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.7) Gecko/20011221 BuildID: 2001122204 We are seeing regular hangs with 0.9.7 on Solaris 9 BETA on SPARC. In this stack traces we've looked at, there is always a thread stuck in read() or poll() from XFillPolygon() as called by the GTK routine gdk_draw_polygon(). Two examples: ----------------- lwp# 1 / thread# 1 -------------------- feb9b098 _poll (ffffffff, febbd1bc, 0, febbd1bc, ffbfc628, ffffffff) + 8 fea0e7bc select (7, ffbfc628, 0, 0, 0, ffbfc6b1) + 6c fed1b73c _XWaitForReadable (0, ffbfc628, 20, 0, 4000, 0) + e0 fed1b56c _XRead (47e20, ffbfc7d4, 20, feb9530c, 0, 0) + e8 fed1c49c _XReply (47e20, ffbfc7d4, ffffffff, 0, 8, 1) + 110 fed4fddc _XSmeAllocateHeapBuffer (47e20, fe6d0000, 4010, 400, 0, 0) + b4 fed1daf8 _XSend (47e20, 164a618, 10, fed9a000, 0, 0) + 1a4 fed3debc XFillPolygon (47e20, 916529, 17c74b0, 164a618, 4, 0) + 1b4 ff067734 gdk_draw_polygon (1b191b8, 1661260, 1, 164a618, 4, 1ff654c) + f8 ----------------- lwp# 1 / thread# 1 -------------------- feb9c5a8 _read (9, ffbfb08c, 20, 0, 0, 0) + c fed1b5a4 _XRead (45a90, ffbfb08c, 20, feb95624, 0, 0) + 110 fed1c4ac _XReply (45a90, ffbfb08c, ffffffff, 0, 0, 0) + 110 fed4fe78 _XSmeAllocateHeapBuffer (45a90, fe6e0000, 40d8, 550, 115, 554) + b4 fed1db8c _XSend (45a90, 1736fe0, 114, fed9a000, 0, 0) + 1a4 fed3df54 XFillPolygon (45a90, a87ae0, 13d7828, 1736fe0, 45, 0) + 1b4 feec7158 gdk_draw_polygon (15904a0, 128e630, 1, 1736fe0, 45, 41e00000) + 5c I can give further trace detail on demand, and could produce a core dump if needed. I can't see any sign of this problem in the GTK archives, or on Google. We haven't tried a more recent build since the Solaris sparc nightlies only started again a day or so ago, and currently have IMAP brokenness (fixed in trunk though). Problem seemed new in 0.9.7, but I can't swear to this. I've tried both the gtk 1.2 0.5.1 that shipped with ns60, and also the current 0.9.1. Reproducible: Sometimes Steps to Reproduce: cannot reproduce on demand.

I've attached an example of a full stack trace.

another excerpted example, this time in write(): feb9d4d0 _write (6, ffbfc62f, 1, 400f, 2b2100, 1) + c fed4fd9c _XSmeAllocateHeapBuffer (47e20, fe720000, 40d0, 550, 115, 554) + 74 fed1daf8 _XSend (47e20, af5ef8, 114, fed9a000, ff, 99) + 1a4 fed3debc XFillPolygon (47e20, f814db, 984cb0, af5ef8, 45, 0) + 1b4 feec7158 gdk_draw_polygon (d8fe08, 6c6ce0, 1, af5ef8, 45, 41e00000) + 5c

There's a strong possibility that this is an issue with Solaris' X shared memory transport. The bug is: 4621046 client/server livelock with shared memory transport and a possible workaround is to use the loopback interface instead of the shm transport: replace ":x.y" with "localhost:x.y" in the DISPLAY env var. We've not investigated this fully yet.

The workaround seems to have had a beneficial effect on this hang. I will update this bug again when the Solaris bug report has been fully investigated.

We've been experiencing this problem in Solaris 8/SPARC as well (Xsun 6.4.1), started using it in 0.9.9 thru 1.0rc1. Looking at Sun's bug information, they know that it's in 5.8 too (it depends on your Xsun & runtime patch levels). Sun advises that one workaround is to increase XSUNSMESIZE (another would be to unset XSUNTRANSPORT or null it). (I haven't yet tried the XSUNSMESIZE=128 possibility.) Requests -- (a) Can we get an advisory (for Solaris users) added into Mozilla's release notes ("Known Problems")? It would mention the issue and the workarounds; (b) Can we get this section in "run-mozilla.sh" modified: ## Solaris Xserver(Xsun) tuning - use shared memory transport if available if [ "$XSUNTRANSPORT" = "" ] then XSUNTRANSPORT="shmem" XSUNSMESIZE="64" export XSUNTRANSPORT XSUNSMESIZE fi (* perhaps increase the segment size to 128, and leave the user's XSUNSMESIZE as is in case they predefined it but didn't define XSUNTRANSPORT ... *) Thanks; Larry.

I'm running with XSUNSMESIZE="128" (hand-patched this in run-mozilla.sh) and so far, it seems to be working without deadlock ... will keep using it for days and see whether it seems to be a worthwhile workaround. (I also submitted comments to Sun to make sure that they address the issue in Solaris 8 as well, since it's still there;) Larry C.

Just wanted to mention that I have two people here (myself and one other) who've been running with XSUNSMESIZE="128" in run-mozilla.sh for about 3 days now, and it's been really solid so far (I haven't seen it deadlock once). Larry.

I'm experiencing the same problems on Solaris8/SPARC with the latest patches from SUN as of 5/13. It's reproducable every time, just do Debug->Verification->JavaScript. This is running on an Ultra10 with ffb graphics (Creator) with the Xserver set to default depth of 24 bits. If XSUNSMESIZE="128" is a fix that works (Larry, still no endless loops between Xsun and mozilla ?) maybe that should be the default ?

We've been running with XSUNSMESIZE=128 for many weeks now and not seen a single hang (where we were seeing hangs daily).

I asked Sun to update their bug report so that it acknowledges that the problem is still there in Solaris 8 ... they took my input but I haven't seen the information coming out in the bug reports (under contract). Larry.

Just to confirm: Larry is noted on Solaris bug 4621046 as still suffering under Solaris 8.

I noticed that in 1.0rc3, the section in run-mozilla.sh has been updated, it now reads -- if [ "$XSUNTRANSPORT" = "" ] then XSUNTRANSPORT="shmem" XSUNSMESIZE="512" ^^^_______ instead of 64 export XSUNTRANSPORT XSUNSMESIZE fi which means that a workaround is now provided in Mozilla. (Yay!) Larry C.

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