119476 - hangs in XFillPolygon when using X shared memory transport

Status: RESOLVED DUPLICATE of bug 118846

(SeaMonkey :: General, defect)

Description

[Calum Mackay]

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.

Comment 1

[Calum Mackay]

Attachment: full stack trace example

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

Comment 2

[Calum Mackay]

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

Comment 3

[Calum Mackay]

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.

Comment 4

[Calum Mackay]

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.

Comment 5

[Larry]

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.

Comment 6

[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.

Comment 7

[Larry]

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.

Comment 8

[Daniel Nilsson]

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 ?

Comment 9

[Calum Mackay]

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

Comment 10

[Larry]

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.

Comment 11

[Calum Mackay]

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

Comment 12

[Larry]

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.

Comment 13

[timeless]

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