26418 - cannot run a second time on mac

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Joe Francis]

using todays sweetlou bits on mac: run mozilla.  quit.  launch it again.  Get no 
windows or menu bar (but doesn't crash).  

I read some mail on my first run, in case that matters.

Comment 1

[Daniel (Leaf) Nunes]

Reassigning to Steve, since he dealt with something similar a couple of days
ago.

Comment 2

[Andreas Otte]

This is what I'm getting on linux:

Start with no component.reg. All is fine. Quit, start again, mozilla hangs with
this messages in the console:

WEBSHELL+ = 2
Note: styleverifytree is disabled
Note: frameverifytree is disabled
Note: verifyreflow is disabled
assuming d&d is off for Navigator
nsCollationUnix::Initialize mLocale = de_DE
nsCollationUnix::Initialize mCharset = ISO-8859-1
Obtained name of Personal Toolbar from bookmarks string bundle.
Start reading in bookmarks.html
Finished reading in bookmarks.html  (708587 microseconds)
nsCollationUnix::Initialize mLocale = de_DE
nsCollationUnix::Initialize mCharset = ISO-8859-1

When breaking there I get this backtrace:

#0  0x40332b6e in __sigsuspend (set=0xbf5ffb9c)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x4026d38f in pthread_cond_wait (cond=0x80b0ecc, mutex=0x80b0ee4)
    at restart.h:49
#2  0x4024dda8 in PR_WaitCondVar (cvar=0x80b0ec8, timeout=4294967295)
    at ptsynch.c:360
#3  0x4024e6c7 in PR_Wait (mon=0x80b0ee0, timeout=4294967295) at ptsynch.c:545
#4  0x401a310e in nsThreadPool::GetRequest (this=0x80b0e50) at nsThread.cpp:396
#5  0x401a3eb1 in nsThreadPoolRunnable::Run (this=0x8077e68)
    at nsThread.cpp:591
#6  0x401a1e85 in nsThread::Main (arg=0x80b0f48) at nsThread.cpp:83
#7  0x40257a7b in _pt_root (arg=0x80b0f60) at ptthread.c:157
#8  0x4026e18a in pthread_start_thread (arg=0xbf5ffe78) at manager.c:214

I have to remove component.reg again to be able to start again.

Comment 3

[Steve Dagley]

sfraser has checked in a fix for a bug which would cause the profile manager 
cleanup routine run at shutdown to delete the chrome directory.  Might something 
similiar be happening on Linux? 

Comment 4

[Suresh Duddi (gone)]

Can you dump the component registry out using the binary regExport (atleast that
is what it is called on win and unix).I suspect something about paths that are
stored for components in the component registry.

Doug fixed a few problems here caused by the nsIFile switch over.

Comment 5

[Simon Fraser [no longer active]]

Joe sez that his chrome directory disappeared, which explains the failure to run 
a second time. I just checked in a fix for that. Any registry-related issues here 
are a separate deal.

Comment 6

[Simon Fraser [no longer active]]

Fixed

Comment 7

[rubydoo123]

setting milestone, this needs to be verified

Comment 8

[John Unruh]

Verified fixed.