88205 - build will not start on Solaris 8 04/01

Status: VERIFIED INVALID

(SeaMonkey :: Build Config, defect, P3)

Description

[Matt Behrens]

Build ID (best I can determine): 20010627

Installed an Ultra10 with Solaris 8 4/01 and a default install of the Software
Companion CD to get lib{gtk,gdk,gmodule,glib}; set LD_LIBRARY_PATH to
/opt/sfw/lib, rm -rf'd ~/.mozilla, executed run-mozilla.sh.

Output:
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:./plugins:/opt/sfw/lib
     LIBRARY_PATH=.:./components
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=

Hangs there indefinitely.  An 815-byte appreg file is created in ~/.mozilla
which I will attach in a moment.

Reproducible: Always

Comment 1

[Matt Behrens]

Attachment: appreg file, sole occupant of ~/.mozilla at time of hang

Comment 2

[Brandon Hume]

I'm using 2001062722 on Sol8+MU3+patches on an SS20 at this moment.

If you truss -f mozilla, where does it hang then?

Comment 3

[Matt Behrens]

The following is looping:

7136:   poll(0xFBF41B98, 1, 35000)                      = 0
7136:   poll(0x00235CB8, 3, -1)         (sleeping...)
7136:   signotifywait()                 (sleeping...)
7136:   poll(0xFBF41B98, 1, 35000)      (sleeping...)
7136:   door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
7136:   lwp_sema_wait(0xFBF21E30)       (sleeping...)
7136:   lwp_cond_wait(0xFEAF55C8, 0xFEAF55D8, 0xFBF03C48) (sleeping...)

lwp_cond_wait hangs for what looks like about 30s each time.

Comment 4

[Doron Rosenberg (IBM)]

cc: gisburn, who is a sun weenie

Comment 5

[Roland Mainz]

weenie ? grrr...

----

A stack trace from /usr/proc/bin/pstack <pid-of-mozilla-bin> would be better for
analysis.

Try 
% /usr/proc/bin/pstack $(pgrep mozilla-bin | head -1)
and post the output (assuming there is only one "mozilla-bin" process on that
machine), please...

First guess... I see door API... mmhhh... DNS ? Does DNS work on that box ?
Does
% getent ipnodes puck.informatik.med.uni-giessen.de
% getent hosts puck.informatik.med.uni-giessen.de
work ("ipnodes" is new in S8 - contains both IPv4/IPv6 addresses, "hosts" is
IPv4-only) ?

Comment 6

[Matt Behrens]

Both getent commands work.

pstack output:
7310:   ./mozilla-bin
-----------------  lwp# 1 / thread# 1  --------------------
 feb994bc poll     (235630, 3, ffffffff)
 feadb2ec poll     (ffffffff, 3, 0, 1d6948, 4d4, aa0) + 34
 fee66440 g_main_iterate (1, 1, 4d4, aa0, 4d4, aa0) + 4d8
 fee66824 g_main_iteration (1, 0, fea265ac, 1d9378, ff3e2628, fca39648) + 30
 fd522b34 DispatchNativeEvent__10nsAppShelliPv (c1f30000, 0, 0, fd522b20,
fd53fec0, 0) + 14
 fca42c5c ShowModal__11nsXULWindow (1ecc80, 1f7204, ffbeee88, fca40148,
ff3e2628, fccd4827) + 2b0
 fca4bd34 ShowModal__16nsWebShellWindow (1ecc80, fca4bd30, 1ecc80, fca42578, 1,
0) + 4
 fca415a8 ShowAsModal__18nsContentTreeOwner (1f71f8, fca41594, 1f7204, fca3f31c,
fcfc1528, 0) + 14
 fccdd910
OpenWindowJS__15nsWindowWatcherP12nsIDOMWindowPCcN22iUiPlPP12nsIDOMWindow
(ff2058a0, 0, 1d9260, f8000406, fcc24870, 1) + e1c
 fccdcac8
OpenWindow__15nsWindowWatcherP12nsIDOMWindowPCcN22P11nsISupportsPP12nsIDOMWindow
(0, 0, 1d9260, fcc249c0, fcc24870, 1d92a8) + 68
 fcc18be4 LoadDefaultProfileDir__9nsProfileR9nsCStringi (0, ffbef240, 1,
ffbef240, 129e0c, ff186b88) + 454
 fcc1834c StartupWithArgs__9nsProfileP17nsICmdLineServicei (1d5c98, 155bc0, 1,
1d5c98, fcc182bc, ff0000) + 90
 00015bd0 ???????? (0, 0, 129df8, fca49f14, ffbef228, ffbef2a8)
 00016d6c ???????? (0, ff2058a0, 0, 5, 100d4, 0)
 00017888 main     (0, ffbef55c, ffbef564, 2d340, 0, 0) + 15c
 00013684 _start   (0, 0, 0, 0, 0, 0) + 5c
-----------------  lwp# 2 / thread# 2  --------------------
 feb9ac80 signotifywait ()
 feace92c _dynamiclwps (feaee000, 5c, 0, 0, 0, 0) + 1c
 fead1c84 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 3 / thread# 4  --------------------
 feb994bc poll     (fbf41b98, 1, 88b8)
 feadb2ec poll     (1e68e0, 1, 3567e0, aaaaaaaa, 0, 0) + 34
 fdf50440 Run__24nsSocketTransportService (132c38, 80470007, 132c3c, feaf1cc0,
4, 157e5d) + 54
 ff194d70 Main__8nsThreadPv (159a18, ff194d48, feaee000, 4, 14c7c0, 0) + 28
 ff0d384c ???????? (14c7c0, fea65d18, 1, feafae04, 0, 2)
 feadbb98 _thread_start (14c7c0, 0, 0, 0, 0, 0) + 40
-----------------  lwp# 4  --------------------------------
 feb98844 door     (0, 0, 0, 0, fc995d18, 4)
 feaca44c _lwp_start (0, 0, 0, 0, 0, 0) + 18
-----------------  lwp# 5 / thread# 5  --------------------
 feb9b2b0 lwp_sema_wait (fbf21e30)
 feac97f0 _park    (fbf21e30, feaee000, 0, fbf21d78, 25020, 0) + 114
 feac94cc _swtch   (fbf21d78, 0, feaee000, 5, ff3e2628, ff0b68d1) + 400
 feac8004 cond_wait (4356, 148bb8, feaee000, 14d248, fbf21d78, fdf22e7a) + e4
 feac7f00 pthread_cond_wait (14d248, 148bb8, 1, fe9c154c, ff3e2628, fdf2430f) +
8
 ff0cee38 PR_WaitCondVar (14d240, ffffffff, 148bb8, febb800c, febbe890, 1dee48)
+ 64
 fdf68b2c DequeuePendingQ__12nsDNSService (148b88, 16b090, 0, 8, 0, 0) + 30
 fdf6867c Run__12nsDNSService (148b50, fdf68658, 148b54, feaf1cc0, 4, 157e7d) +
24
 ff194d70 Main__8nsThreadPv (16b090, ff194d48, feaee000, 4, 148c78, 0) + 28
 ff0d384c ???????? (148c78, fc0c3d18, 1, feafae04, 0, 2)
 feadbb98 _thread_start (148c78, 0, 0, 0, 0, 0) + 40
-----------------  lwp# 6  --------------------------------
 feb9b264 lwp_cond_wait (feaf55c8, feaf55d8, fbf03c48)
 feb92c88 _lwp_cond_timedwait (0, 3b3b4d89, fbf03cb0, feaf55c8, feaf55d8, 0) +
98
 feac8e24 _age     (feaeedc0, feaeedc4, feaee000, 3, feaee000, 1) + 94
 feaca44c _lwp_start (fbf03d78, 0, 4000, fe80fc34, 0, 0) + 18
 fead1c84 thr_yield (0, 0, 0, 0, 0, 0) + 8c
--------------------------  thread# 3  --------------------
 feacd8e4 _reap_wait (feaf2a30, 209f8, 0, feaee000, 0, 0) + 38
 feacd63c _reaper  (feaeee58, feaf4798, feaf2a30, feaeee30, 1, fe400000) + 38
 feadbb98 _thread_start (0, 0, 0, 0, 0, 0) + 40

Comment 7

[Roland Mainz]

Looks like it's stuck in GDK/GTK+-hell... CC:'ing the guru for such issues -
blizzard... :-)

Comment 8

[Asa Dotzler [:asa]]

->build config

Comment 9

[Matt Behrens]

Incidentally, to the Solaris guys who don't see this problem --

Where are you getting your glib/gtk+ from?  It may be that the Sun-distributed
versions aren't configured in a Mozilla-compatible way.  I'm more than happy to
try a few different packages.

Comment 10

[Roland Mainz]

> Where are you getting your glib/gtk+ from?

Uhm... I build it myself and created a package for my machines... :-)

> It may be that the Sun-distributed versions aren't configured in a
> Mozilla-compatible way. 

The only thing which can be "broken" by configure/compiler stuff is using the 
"wrong" compiler - GDK/GTK+ libraries build with gcc 2.x cannot be used to
compile a Mozilla using Sun Workshop - but GDK/GTK+ libraries build with Sun
Workshop can be used for building Mozilla with both gcc and Sun Workshop. That's
a gcc bug... - but AFAIK this issue is not related to this one...

> I'm more than happy to try a few different packages.

Try http://www.sunfreeware.com/ - deinstall the Sun packages and try the
packages from that page...

Comment 11

[Matt Behrens]

With the sunfreeware copies of glib/gtk+, I get a very slightly different loop
in truss:

8683:   poll(0xFBEF1B98, 1, 35000)                      = 0
8683:   poll(0x001CB378, 3, -1)         (sleeping...)
8683:   signotifywait()                 (sleeping...)
8683:   poll(0xFBEF1B98, 1, 35000)      (sleeping...)
8683:   lwp_cond_wait(0xFEAF55C8, 0xFEAF55D8, 0xFC045BF0) (sleeping...)
8683:   lwp_sema_wait(0xFBED1E30)       (sleeping...)
8683:   door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)

pstack output looks the same though.

Comment 12

[Roland Mainz]

BAD.

Next step would be to compare the set of recommended patches with the set of
patches applied to your system - see
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/xos-8&nav=pub-patches
(maybe the Xsun-patch is sufficient...maybe not...).

Matt - do you need help with this ?

Comment 13

[Matt Behrens]

I am currently on MU4; X11 patch is at 108652-25.  I have a multihead layout
with an ffb (Creator3D) in the center and a gfxp (PGX32) on either side.  I am
not using Xinerama because, well, it just plain doesn't work with mixed cards,
and even when it did work it caused all sorts of weirdness with most apps I
wanted to run.  I did try Moz in single-head mode on the ffb, "just in case";
same results.

I might as well put the recommended set on this box anyway, I've just been
putting it off... so I don't destroy any valuable diagnostic info in the
process, is it sufficient to showrev -p now, apply the recommended set, showrev
-p again, then diff?  Or do we want to drill down a little bit finer than that?

Comment 14

[cls]

I'm not fully convinced that applying the "recommmended" updates will fix this
problem.  But I may be just unfairly upset about my updating results in bug
80812. :-P  Matt, have you tried compiling glib & gtk on your machine?  I'm
wondering if the CD and the sunfreeware.com libs are built with -xarch=v9 or
some flag that would make them incompatible with the format used to build
mozilla (whatever gcc 2.95.2 uses).

Comment 15

[Matt Behrens]

Yeah, I tried default compiles as well as --with-threads=posix (just for fun)
;-) on glib.

Comment 16

[Roland Mainz]

cls:
-xarch=v9 would generate 64bit sparcv9 binaries - 32bit Mozilla won't even
_load_ with such a library... :-)
-xarch=v8 or -xarch=v8a should work; v8a only works on UltraSPARC-I/II, v8b only
on UltraSPARC-III... /usr/bin/file usually tells the type of library... I doubt
that it is something else than v7/v8/v8a... :-))

Comment 17

[Matt Behrens]

Recommended patch set didn't help either.  (I needed 'em anyway...)

Changing summary since this bug probably has nothing to do with the software
companion libs.

Comment 18

[Roland Mainz]

Two options left:
- Recompile glib/GDK/GTK+ libraries on your box. May work or not...
OR
- Join the GDK/GTK+-"free" club... :-))  ... compile the Zilla with "./configure
--enable-toolkit=xlib; gmake" - this does not require/use the GDK/GTK+
libraries...

Comment 19

[Roland Mainz]

Matt Behrens:
Please try
http://puck.informatik.med.uni-giessen.de/download/mozilla-sparc-sun-solaris2.7-0.9.2-xlib.tar.gz
(be sure to avoid the profile migration stuff via deleting/renaming ~/.netscape)
...

Comment 20

[Matt Behrens]

Yeah, I was working on compiling that up myself, but got distracted :-)

nsDeviceContextXlib::Init(dpy=15a428  screen=10fc78  visual=152398  depth=24)
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  1 (X_CreateWindow)
  Serial number of failed request:  17
  Current serial number in output stream:  18

I have 108652-35, 108773-08, and 10843[45]-01 installed.

Comment 21

[Roland Mainz]

Wanna post the output of xdpyinfo and the type of usede framebuffer, please ?

Comment 22

[Matt Behrens]

Attachment: xdpyinfo output

Comment 23

[Matt Behrens]

xdpyinfo attached because, well, it's rather long :-)

I have a three-head setup with two gfxps (PGX32) and an ffb (Creator3D).  The
ffb is in the center.  I have tried going to a single-head setup (deleting the
-dev flags from the Xsun line), using just the ffb, and I have exactly the same
problems (I tried that with the original companion libs setup, and also with the
xlib build.)

Comment 24

[Roland Mainz]

Gnnn. Nice. And I have no clue why it fails. It works here with Solaris 7/8...
Is there any way to force that only visuals of the same depth are available ?

Comment 25

[Matt Behrens]

There's all sorts of config options... :-)  Unfortunately I don't understand
most of them...

On the ffb I have

# ffbconfig -propt

--- OpenWindows Configuration for /dev/fbs/ffb0 ---
OWconfig: machine
Video Mode: 1280x1024x67
Default Visual: Non-Linear Normal Visual
Visual Ordering: Linear Visuals are last
                 Overlay Visuals are last
OpenGL Visual Expansion: enabled
Server Overlay Visuals: enabled
Extended Overlay: enabled
Underlay WIDs: 64 (not configurable)
Overlay WIDs: 4 (not configurable)
Gamma Correction Value: 2.220000
Gamma Correction Table: Available

The gfxps are significantly less configurable:

# GFXconfig -propt -dev all

--- OpenWindows Configuration for /dev/fbs/gfxp0 ---
OWconfig: system
Video Mode: VESA1280x1024x75
Depth: 24


--- OpenWindows Configuration for /dev/fbs/gfxp1 ---
OWconfig: system
Video Mode: VESA1280x1024x75
Depth: 24

Comment 26

[cls]

Matt, can you try the fix suggested in this news post?

news://news.mozilla.org:119/[e-mail]

Comment 27

[Matt Behrens]

Okay, that's just plain crazy -- 0.9.3 (2.8, GTK) works now.  I only applied
10843[45]; I previously had revs -01 of both.  I didn't apply the first patch in
the posting because I already had a later rev applied.

I really don't get what 10843[45] have to do with this; I thought it was an
issue with X...

Comment 28

[cls]

OS patches required.  Marking invalid (not a Mozilla bug).

Comment 29

[Roland Mainz]

Shouldn't we update the release notes to include this information ?

Comment 30

[cls]

Probably.

Comment 31

[Jon Granrose]

verified.