I tried the 01/20/1999 nightly build for Linux on my Dual Processor i686 system. It crashes will the following traceback and error messages: XXX: return /tmp for fe_GetConfigDir XXX: return /tmp for fe_GetConfigDir XXX: return /tmp for fe_GetConfigDir XXX: return /tmp for fe_GetConfigDir XXX: return /tmp for fe_GetConfigDir Program received signal SIGSEGV, Segmentation fault. 0x4094400d in _PR_InitCPUs () (gdb) where #0 0x4094400d in _PR_InitCPUs () #1 0x40947114 in _PR_NativeRunThread () Could this be my version of jdk (jdk117_v1a) with hardware threads? Or perhaps that I'm running linux-2.2.0-pre1? Rick Niles.

What does the jdk have to do with the Mozilla browser? I believe that the Mozilla browser still doesn't have Java support. Are you using the user-level threads or native threads (pthreads) version of NSPR?

JDK has nothing to do with Mozilla, except that it also supports both user and native level threads...disregard...I was confused. I'm using which ever version of NSPR that's in the nightly builds it's labeled libnspr21.so. It still doesn't work under 2.2.0-pre9. Can I set what type of threads I'm using with an option or env var?

OK I'm really an idiot. It really helps to RTFM. I had an old version of libgtk and I didn't have libnspr installed at all. Sorry to waste your time. I'll have another bug report soon though since now I have a failed assertion in the GTK code once the window comes up. Again, sorry...(Perhaps you should state these requirements in a README that comes in the tarball with the mozilla nightly binaries.)

No problem! I am going to mark this bug as INVALID and close it then.

Hmm...I may have concluded too soon that it was my fault. The nightly binary ships with a threads lib so I didn't really need to install it and it never got far enough to use GTK. The user-threads crashes just like this: #0 0x40935fad in _PR_CPU_Idle (_cpu=0x8082000) at prucpu.c:266 #1 0x409390b4 in _PR_UserRunThread () at pruthr.c:471 Native threads goes a little farther with this crash: #0 0x40bf5902 in chunk_free (ar_ptr=0x40c4a420, p=0x81c5c28) at malloc.c:2948 #1 0x40bf57c1 in __libc_free (mem=0x81c5c30) at malloc.c:2872 #2 0x400279dd in __builtin_delete () #3 0x404a1f77 in nsFrame::~nsFrame () #4 0x404bf758 in nsSplittableFrame::~nsSplittableFrame () #5 0x404a0af7 in nsContainerFrame::~nsContainerFrame () #6 0x404aa9dc in nsHTMLContainerFrame::~nsHTMLContainerFrame () #7 0x404becf4 in nsScrollFrame::~nsScrollFrame () #8 0x404a23cd in nsFrame::DeleteFrame () #9 0x404a0bd2 in nsContainerFrame::DeleteFrame () #10 0x404a4cbb in nsFrameList::DeleteFrames () #11 0x404a0bc5 in nsContainerFrame::DeleteFrame () #12 0x404bb65c in PresShell::~PresShell () #13 0x404bb456 in PresShell::Release () #14 0x409646f0 in DocumentViewerImpl::~DocumentViewerImpl () #15 0x4096445b in DocumentViewerImpl::Release () #16 0x4096c702 in nsWebShell::Embed () #17 0x40967ffb in nsDocumentBindInfo::OnStartBinding () #18 0x408c59c7 in NET_NGLayoutConverter () #19 0x408f06c2 in NET_StreamBuilder () #20 0x408990fb in NET_CacheConverter () #21 0x408f06c2 in NET_StreamBuilder () #22 0x408a8911 in NET_ChunkedDecoderStream () #23 0x408f062f in NET_StreamBuilder () #24 0x406ef618 in NET_getInternetKeyword () #25 0x406f0601 in NET_getInternetKeyword () #26 0x408e7f62 in NET_ProcessNet () #27 0x408ef8bd in NET_PollSockets () #28 0x408bcb54 in nsNetlibService::NetPollSocketsCallback () #29 0x4064debd in TimerImpl::FireTimeout () #30 0x4064e366 in nsTimerExpired () #31 0x40177a08 in g_main_set_poll_func () #32 0x40176ede in g_get_current_time () #33 0x4017730d in g_get_current_time () #34 0x40177471 in g_main_run () #35 0x401150de in gtk_main () #36 0x400c5dbd in nsAppShell::Run () #37 0x8054786 in nsNativeViewerApp::Run () #38 0x80549da in main () It still seems that user-threads at least are broken with dual processors.

Setting all current Open Critical and Major to M3

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Current build are working well, Please mark resolved.

tried this on redhat 5.2 kernel 2.0.34 recompiled for SMP support on my dual p200MMX system. (will also try on NT4.0 Multiprocessor on same box after i reboot, and i'll update this only if seamonkey doesn't work there.) verified on build 99030808 (08.Mar.1999)

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.