Subject: Re: mozilla-latest on -current/i386
To: Bryan P <u7@terran.org>
From: Gary Duzan <gary@duzan.org>
List: current-users
Date: 04/25/2003 06:44:05
   I reported the same symptoms under Mozilla 1.3 recently. It
looks like it was caused by some changes to ld_elf.so which have
since been backed out. Things are working for me again after a cvs
update last night and quick userland rebuild/install.

					Gary Duzan


In Message <Pine.NEB.4.44.0304242224140.14394-100000@jupiter.terran> ,
   Bryan P <u7@terran.org> wrote:

=>Hello,
=>
=>I am now running 1.6R-i386 from CVS sources dated to about 48 hours ago,
=>and have all threads apps (mostly X stuff) using native threads.  I noticed
=>that xmms starts up way faster and seems to work moderately well (it wedged
=>on me once while the system was under high load).
=>
=>I had previously been running mozilla native from CVS sources also about 48
=>hours old, with no problems.  Once I upgraded to the latest NetBSD code,
=>mozilla broke.  It appeared to be due to conflicts between GNU pth and
=>native pthreads.  So, I rebuilt all the dependency libraries from pkgsrc
=>(which is how I got to all native pthreads), removed pth, and
=>reconfigured/rebuilt mozilla - I did not update the mozilla sources.  Now
=>mozilla core dumps on startup before ever drawing anything to the display.
=>Here is the tail of the ktrace:
=>
=>   860 mozilla-bin NAMI  "/usr/home/bryan/etc/src/mozilla/dist/bin/libxpcom.so"
=>   860 mozilla-bin RET   open 7
=>   860 mozilla-bin CALL  __fstat13(0x7,0xbfbff18c)
=>   860 mozilla-bin RET   __fstat13 0
=>   860 mozilla-bin CALL  mmap(0,0x1000,0x1,0x1,0x7,0,0)
=>   860 mozilla-bin RET   mmap 1213018112/0x484d3000
=>   860 mozilla-bin CALL  munmap(0x484d3000,0x1000)
=>   860 mozilla-bin RET   munmap 0
=>   860 mozilla-bin CALL  mmap(0,0x105000,0x5,0x2,0x7,0,0)
=>   860 mozilla-bin RET   mmap 1213018112/0x484d3000
=>   860 mozilla-bin CALL  mmap(0x485c8000,0x10000,0x3,0x12,0x7,0,0xf5000)
=>   860 mozilla-bin RET   mmap 1214021632/0x485c8000
=>   860 mozilla-bin CALL  mmap(0x485d8000,0,0x3,0x1012,0xffffffff,0,0)
=>   860 mozilla-bin RET   mmap 1214087168/0x485d8000
=>   860 mozilla-bin CALL  close(0x7)
=>   860 mozilla-bin RET   close 0
=>   860 mozilla-bin CALL  __sysctl(0x4808c008,0x2,0xbfbff3fc,0xbfbff3f8,0,0)
=>   860 mozilla-bin RET   __sysctl 0
=>   860 mozilla-bin PSIG  SIGSEGV SIG_DFL
=>   860 mozilla-bin NAMI  "mozilla-bin.core"
=>
=>The backtrace looks like this:
=>
=>   #5231 0x8075394 in NS_GetMemoryManager ()
=>   #5232 0x8074935 in GlueStartupMemory ()
=>   #5233 0x807518c in XPCOMGlueStartup ()
=>   #5234 0x80754d0 in GRE_Startup ()
=>   #5235 0x8058a06 in main ()
=>   #5236 0x8054254 in ___start ()
=>
=>I'll have to reconfigure and rebuild with debugging enabled.  In the
=>mean-time, if there is anyone out there who knows if these bleeding-edge
=>sources can be stitched together before they heal a bit more, I'd love to
=>hear. :-)
=>
=>-bp
=>--
=># Software Engineer
=>
=>