Closed Bug 44342 Opened 24 years ago Closed 24 years ago

Builds hangs on startup

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: asa, Assigned: warrensomebody)

References

Details

(Keywords: regression, smoketest, Whiteboard: [dogfood+]) 

build 063009 mozilla bits (I think alek said commercial too)

The first time I tried to start up mozilla it froze on the splash screen after
it seemed to register a bunch of components.  I escaped to macsbug and exited to
shell.  I rebooted the machine and started mozilla again.  this time it started
and I was able to load the smoketest page.  I closed and attempted to start the
profile manager.  It locked up again on the splash screen and I could not escape
through macsbug so I rebooted.  Then I was able to launch the profile manager
and create a new profile.  THe new profile did not have any default bookmarks
(possibly related)  I closed and restarted the profile and it did have bookmarks
the second time.Now I seem to lock up every three or fourth time I try to launch
mozilla.
this is a completely clean install.  new profile.  do not have an existing
profile to test.  adding smoketest keyword
Keywords: smoketest
How about not using the installer. Does that yield equivalent results?
this occurs with 2000-06-30-09-M17 Mac commercial bits also.  marking [dogfood+]
Whiteboard: [dogfood+]
macsbug seems o give similar output each time

 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  1F381D64  
  0EDDE100    PPC  1F36C8A8  main+00130
  0EDDE0A0    PPC  1F36BAB0  main1(int, char**, nsISupports*)+00650
  0EDDDDE0    PPC  1EA9D88C  nsProfile::StartupWithArgs(nsICmdLineService*)+00064
  0EDDDD70    PPC  1EA9DD5C  nsProfile::LoadDefaultProfileDir(nsCString&)+00438
  0EDDDB60    PPC  1F2900A8  nsAppShellService::Run()+00018
  0EDDDB20    PPC  1EB248B4  nsAppShell::Run()+00038
  0EDDDAD0    PPC  1EB24FB0  nsMacMessagePump::DoMessagePump()+0003C
  0EDDDA80    PPC  1EB255B8  nsMacMessagePump::DispatchEvent(int, EventRecord*)+
00174
  0EDDDA30    PPC  1EB3AD2C  Repeater::DoRepeaters(const EventRecord&)+00030
  0EDDD9F0    PPC  1EB02E88  nsMacNSPREventQueueHandler::RepeatAction(const 
EventRecord&)+000
0C
  0EDDD9B0    PPC  1EB02F84  nsMacNSPREventQueueHandler::ProcessPLEventQueue()+
00094
 Closing log
sometimes it locks a little higher up at nsMacMessagePump::DispatchEvent

trying with the not installer build now.

happens on Installer AND regular sea.bin builds.  both show strange behavior
failing to load default bookmarks either to the menu or to the sidebar.  in
subsiquent successful launches the bookmarks are there.
sdagley is verifying that backing out harishd's checkins around ContentSink
fixes the problems for him. If this is the case, we'll back out, open the tree
and respin.
More testing reveals I'm seeing the hang on launch with and without harish's 

change so that's not the culprit.  No other likely suspects in sight.


simpler summary.
Summary: Mac mozilla bits lock freeze on " Starting up... " splash msg → Mac hangs on startup
Reducing blocker severity to critical.  leaf and I have decided that this will
NOT keep the tree closed today, but we should consider this a "sooper" dogfood
bug.
Severity: blocker → critical
fine by me. I'm actaully able to get moz up and running but it's not much good
on most of the other smoketests. It seems to lock up (somewhat consistently, but
not 100%) when opening mail or composer from the tasks menu or trying to open
prefs. All the lockups look about the same in macsbug.  
I have been seeing this very often in win32 builds.  Mozilla actually starts 
one out of four times for me lately...most of the time it just hangs on 
something in the console and I have to shut it down and try again.  Am not 
going to change OS/Platform til someone can confirm that this is XP (or win32 
also, at least).
Summary: Mac hangs on startup → Builds hangs on startup
confirming on win32 (zip), marking all.
OS: Mac System 9.0 → All
This is still happening.  tested with 070510 mozilla build on Mac os9.  Is
anyone seeing this in Linux?
happened once on Linux with an optimized cvs build from 0704.
updating platform to ALL.
Hardware: Macintosh → All
Keywords: regression
This is still happening frequently on Mac Mozilla build 070608
Still around in win32 70608 as well, and as annoying as ever.  Four out of five 
times I attempt to load the browser, it hangs on Webshell = +2 in the console.

The next item that appears in the console in a successful load is:

-->loadDS(): ds=[xpconnect wrapped nsIRDFDataSource], loaded=true, returning! <-
-

I notice this is a fairly new occurrence.  Related, perhaps?
Keywords: dogfood
On the latest commercial mac build (2000-07-06-08-M17) after i crash once it 
hangs every single time after that and have to reinstall the build. Is this 
related?
I'm seeing this also on Mac in the last 6 days. Either it stops after "Webshell 
= +2" or after the loadDS() line. If it gets past the loadDS line it starts up 
normally. I have found no reliable work-around, and i can only launch about 1 
out 10 times :-(. This is seriously blocking my development work. I have tried 
the following work-arounds, they all help, but not reliably (it still stops 
sometimes): switch to desktop after the splash screen appears, and then open 
random files in another program; step through the startup from the debugger; 
click (ferociously) on the splashscreen and the console. Seems like a race 
condition and/or a problem with events.

Somethign new!. I have found that 
deleting  mozregistry.dat 

on Win95 platforms seems to fix the problem!!!!!

obviously its getting corrupted??

I don't see a whole lot of traction here.  If we don't get any soon, we should 
probably hold the tree for this.
Blake:  Are you seeing this on Win9x or WinNT?  I saw it intermittently on 
Win98 (always before the loadDS line, I think).  Now that I think about it, I 
may have stopped seeing it after deleting my profile.  But I still have the old 
one...
*** Bug 44409 has been marked as a duplicate of this bug. ***
I submitted this very same bug as 44409 and was wondering why it was getting 
ignored :)
SPAM: Adding self to CC list
I observed the following twice using a debug build from the weekend:  When I 
hung here on a Win98 debug build (with my profile #2, which I moved to a 
different directory so I wouldn't use it a few days ago):

Obtained name of Personal Toolbar from bookmarks string bundle.
Obtained name of Personal Toolbar from fallback hard-coded string.
Start reading in bookmarks.html
Finished reading in bookmarks.html  (440000 microseconds)
Enabling Quirk StyleSheet
Note: verifyreflow is disabled
Note: styleverifytree is disabled
Note: frameverifytree is disabled
Enabling Quirk StyleSheet
CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://global/locale/intl.css' faile
d.  Error code: 16389

-> SinkObserver:onError: [xpconnect wrapped nsIRDFXMLSink], status=2147500037, e
rrMsg=null, state=8
WEBSHELL+ = 3
Adding url about:blank to SH
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet


I broke into the debugger and took the following stack trace:

nsAppShell::Run(nsAppShell * const 0x014ddcd0) line 123   [ at "} while 
(keepGoing != 0);" ]
nsAppShellService::Run(nsAppShellService * const 0x014d8370) line 387
main1(int 1, char * * 0x00c831f0, nsISupports * 0x00000000) line 914 + 32 bytes
main(int 1, char * * 0x00c831f0) line 1100 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! bff8b560()
KERNEL32! bff8b412()
KERNEL32! bff89dd5()

In earlier builds I hung after the DidLoadStyle error, I think, but I'm not 
sure.
David: I see it on WinME, which is basically the equivalent of Win98.  I can 
try on win2k if you want...
Somebody should try backing out these changes, and see what happens. warren made
some changes (r=waterson) late thursday night.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=warren%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=06%2F30%2F2000+00%3A00%3A00&maxdate=07%2F02%2F2000+00%3A00%3A00&cvsroot=%2Fcvsroot

cvs update -j1.81 -j1.80 mozilla/netwerk/base/src/nsFileTransport.cpp
cvs update -j1.42 -j1.41 mozilla/netwerk/base/src/nsFileTransport.h
cvs update -j1.13 -j1.12 mozilla/netwerk/test/TestFileTransport.cpp


asa - this is assigned to you.  Are you the right owner?
*** Bug 44616 has been marked as a duplicate of this bug. ***
*** Bug 44616 has been marked as a duplicate of this bug. ***
this has been killing me all day.
I'm trying backing out warren's stuff now, see what I come up with.
ok, so backing out warren's checkins seems to allow me to start

The problem I was seeing, just for reference, was that on NT, on mozilla -mail,
it would hang on startup after showing "Enabling Quirk Stylesheet", and it would
hang about 2/3 of the time.

I've now started about 10 times without seeing this problem.
re-upgrading to blocker. This is blocking me from getting my work done, since I
work on mail, and mozilla -mail only works less than half the time.

If this is a "super" dogfood bug, why is nobody working on it? Asa, is this
yours? Who does this go to?
Severity: critical → blocker
reassigning to warren since backing his stuff out makes this work, and asa is
not responding.
Assignee: asa → warren
Asa's at lunch, but it's not his...he's not an engineer.  If backing out 
warren's changes fixes it, then I recommend that warren get it..
Priority: P1 → P3
ezh@infonet.ee please don't throw out someone else's changes.  If you get a 
collision, go back and do yours again.
Priority: P3 → P1
Here are stack traces on all threads:

KERNEL32! bff99b32()
_PR_WaitCondVar(PRThread * 0x00d6feb0, PRCondVar * 0x00d769a0, PRLock * 
0x00d76a50, unsigned int 4294967295) line 185 + 23 bytes
PR_Wait(PRMonitor * 0x00d76b00, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x00d6e3b0) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x00d6e400) line 685 + 27 
bytes
nsThread::Main(void * 0x00d6e3b0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x00d6feb0) line 399 + 13 bytes
_threadstartex(void * 0x00d6a0d0) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


PR_Wait(PRMonitor * 0x00d76b00, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x02641830) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x02641880) line 685 + 27 
bytes
nsThread::Main(void * 0x02641830) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x026416c0) line 399 + 13 bytes
_threadstartex(void * 0x02641510) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


PR_Wait(PRMonitor * 0x00d76b00, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x0264bad0) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x0264b880) line 685 + 27 
bytes
nsThread::Main(void * 0x0264bad0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x0264b460) line 399 + 13 bytes
_threadstartex(void * 0x0264b2b0) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()

KERNEL32! bff99b32()
_PR_WaitCondVar(PRThread * 0x0264ec70, PRCondVar * 0x00d769a0, PRLock * 
0x00d76a50, unsigned int 4294967295) line 185 + 23 bytes
PR_Wait(PRMonitor * 0x00d76b00, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x0264ede0) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x0264d3c0) line 685 + 27 
bytes
nsThread::Main(void * 0x0264ede0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x0264ec70) line 399 + 13 bytes
_threadstartex(void * 0x0264eac0) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


MSAFD! 7b411b52()
MSAFD! 7b412d23()
WS2_32! 7600884a()
WSOCK32! 75fa1734()
_PR_MD_PR_POLL(PRPollDesc * 0x00d755e0, int 1, unsigned int 2610055) line 224 + 
35 bytes
PR_Poll(PRPollDesc * 0x00d755e0, int 1, unsigned int 2610055) line 115 + 17 
bytes
nsSocketTransportService::Run(nsSocketTransportService * const 0x00d75da4) line 
385 + 24 bytes
nsThread::Main(void * 0x00d75350) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x00d751e0) line 399 + 13 bytes
_threadstartex(void * 0x00d75030) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


KERNEL32! bff7a280()
KERNEL32! bff92cec()


KERNEL32! bff99b32()


nsAppShell::Run(nsAppShell * const 0x014ddcd0) line 123
nsAppShellService::Run(nsAppShellService * const 0x014d8370) line 387
main1(int 1, char * * 0x00c831f0, nsISupports * 0x00000000) line 914 + 32 bytes
main(int 1, char * * 0x00c831f0) line 1100 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! bff8b560()
KERNEL32! bff8b412()
KERNEL32! bff89dd5()

I think this means either the threads are all idle or some are deadlocked.
It means all threads are idle. 

Sounds like some event failed, and we're just silently sitting in the main loop 
waiting for nothing to happen.
pchen and i have been seeing this problem for almost a month now, and it seems 
intermittant. sometimes it won't start, sometimes it will.

it is probably a timing bug that is tweaked by warren's speedups. i don't think 
this should hold the tree closed, but it really should be investigated and fixed 
asap.

I check nightly builds every day, and started seeing this about the start of the 
4th July weekend on win32 (win2k).  I'm now at the point where I can't start 
mozilla at all.  Just fyi...
It's gotten to the point on windows where you can't start mail on almost regular 
basis. This affects the entire mail team's productivity. That is why I feel it 
has become a blocker.
Interesting. I see this most often on Win2000 as well.
This is no doubt due to some event getting an error, and that error getting 
ignored somewhere along the way. I've seen this behavior before during startup. 
My changes to the file transport to speed it up (and fix the js deadlock) must 
have aggravated the condition since it was intermittent/timing-related.

To: timeless@bemail.org

I just added myself to cc list... I didn't changed anything... Don't know why 
priority changed.

Sorry.
So, who is working on this, and nothing but this? If i get an answer, i might
open the tree today.
It's intermittent. I just tried my build today on Linux, and "mozilla -mail" 
works 10 out of 10 times for me. I don't think we should hold the tree closed 
for this
Just a fyi.  Bug marked dup of this is in starting Messenger on the Mac.
on my linux build this morning, I've had 4 successful starts, and 5 failures
running mozilla -mail


For the record, what I was seeing on Win98 was a totally separate problem 
related to localization changes (I made the mistake of testing GB localization). 
 However, I have seen this on Mac.  I've also seen similar problems on Win98 
before warren's changes, but not after.
After a load fails to load the bookmarks (you see the spinny just go and go 
forever), all subsequent attempts to start fail here on Win2k. It doesn't matter 
what copy of Mozilla I use either. I mean I have several differing copies in 
different directories and they all fail to start after any one of them fails 
to load bookmarks - even after blowing away the Users50 and mozregistry.dat. 
Rebooting clears it up, but Mozilla is *not* listed in task manager.
sounds like a different bug - no windows ever appear in this bug.
I think I'm being misunderstood. It is after Mozilla loads successfully (which 
it does occasionally - like after a reboot) *AND* doesn't load the bookmarks 
that all subsequent attempts to launch Mozilla fail. The -mail switch is not 
necessary to duplicate this bug. I have been seeing it since last Friday at 
least.
i dont know if this is related, but sometimes i can get mozilla to start, but 
then cant get composer to come up, or cannot get a new mail message window to 
come up.  This has been happening to me for several days.  I've only been on the 
mac lately, dunno about other platforms.

jfrancis: i saw this on win32 yesterday. composer just wouldn't come up (taskbar 
button or picked from menu) and no errors or asserts to the console.

mike and jfrancis, I'm seeing the same thing on Mac, I often cannot launch
composer or mail from Navigator.,  This started happening last Friday at the
same time that I started freezing on startup.  
What dbaron and I were seeing last night on the mac was that it would start to 
come up (the profile manager would launch ok), but after the console message 
about loading "IE Favorites" nothing happened -- no window would come up, no 
toolbar, etc. The app seemed to be sitting in the event loop with nothing to do, 
and no windows. I suspect that some event was failing, and the error code was 
getting ignored. 

I haven't investigated this on Linux, but if you're getting a window, it's 
probably a different problem.
so just to clarify: this is happening on ALL THREE PLATFORMS - EXACTLY the same
bug, same messages on the console, and so forth.
Pavlov and mcafee are also seeing it fail on Linux.
Other people have reported it on Win32.

This is NOT a mac problem.
Mac (2000-07-07-13 M13)
In today's Mac respin, I download the mac.sea.bin file, click on the Netscape
icon, the netscape window comes up briefly and then a blank window and then
hang. It makes the Mac build completely un-useable. 
I've been getting blank windows for the last week on Mac OS9.  Once it happens 
(intially while doing almost anything in any component) upon subsequent relaunch, 
goes straight to blank window. No message.  

Relaunch produces a window the size of the profile selection window, and you can 
close it, but it brings up a full screen blank window. Close that and you are 
left with nothing, not even file menu bar.  Force quit exits 

Trash registry, trash prefs, profiles.  Relaunch - still blank.  Have to 
reinstall completely.  This is happening with current builds, 

I have been unable to reproduce this on Linux or Windows.  It's hard to debug
threading issues on Mac, and threading issues may be involved.  On Mac, I found
that it hung (on waterson's Mac) while loading sidebarOverlay.js, but if I added
a few hundred lines of comments to the end of that file, it hung later.
Symptoms seem to vary by machine -- the blank windows may be the same bug as
hanging before any window shows up.
alecf:  I just talked to pavlov and he said that what he saw this morning was a 
crash, not a hang (and he only saw it once).  If you really are seeing this bug 
on Linux, it would be very helpful to get stack traces on all threads to see if 
it is a deadlock or other easily visible threading problem.
I just managed to reproduce this on Win98.  Here are stack traces on all 
threads:

MSAFD! 7b411b52()
MSAFD! 7b412d23()
WS2_32! 7600884a()
WSOCK32! 75fa1734()
_PR_MD_PR_POLL(PRPollDesc * 0x014dc3f0, int 1, unsigned int 2610055) line 224 + 
35 bytes
PR_Poll(PRPollDesc * 0x014dc3f0, int 1, unsigned int 2610055) line 115 + 17 
bytes
nsSocketTransportService::Run(nsSocketTransportService * const 0x014dc5b4) line 
385 + 24 bytes
nsThread::Main(void * 0x014d3fd0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x00d6beb0) line 399 + 13 bytes
_threadstartex(void * 0x00d6bd00) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


KERNEL32! bff99b32()


KERNEL32! bff99b32()
_PR_WaitCondVar(PRThread * 0x01524410, PRCondVar * 0x00d6b870, PRLock * 
0x00d6b920, unsigned int 4294967295) line 185 + 23 bytes
PR_Wait(PRMonitor * 0x00d6b9d0, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x01524580) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x015245d0) line 685 + 27 
bytes
nsThread::Main(void * 0x01524580) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x01524410) line 399 + 13 bytes
_threadstartex(void * 0x01524260) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


nsAppShell::Run(nsAppShell * const 0x014ddcd0) line 123
nsAppShellService::Run(nsAppShellService * const 0x014d8370) line 387
main1(int 1, char * * 0x00c831f0, nsISupports * 0x00000000) line 914 + 32 bytes
main(int 1, char * * 0x00c831f0) line 1100 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! bff8b560()
KERNEL32! bff8b412()
KERNEL32! bff89dd5()


KERNEL32! bff99b32()
_PR_WaitCondVar(PRThread * 0x023b7350, PRCondVar * 0x00d6b870, PRLock * 
0x00d6b920, unsigned int 4294967295) line 185 + 23 bytes
PR_Wait(PRMonitor * 0x00d6b9d0, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x023b74c0) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x023b7b10) line 685 + 27 
bytes
nsThread::Main(void * 0x023b74c0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x023b7350) line 399 + 13 bytes
_threadstartex(void * 0x023b71a0) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


KERNEL32! bff99b32()
_PR_WaitCondVar(PRThread * 0x023a56e0, PRCondVar * 0x00d6b870, PRLock * 
0x00d6b920, unsigned int 4294967295) line 185 + 23 bytes
PR_Wait(PRMonitor * 0x00d6b9d0, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x023a5850) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x023a5da0) line 685 + 27 
bytes
nsThread::Main(void * 0x023a5850) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x023a56e0) line 399 + 13 bytes
_threadstartex(void * 0x023a5530) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()


KERNEL32! bff99b32()
_PR_WaitCondVar(PRThread * 0x023a1160, PRCondVar * 0x00d6b870, PRLock * 
0x00d6b920, unsigned int 4294967295) line 185 + 23 bytes
PR_Wait(PRMonitor * 0x00d6b9d0, unsigned int 4294967295) line 155 + 29 bytes
nsAutoMonitor::Wait(unsigned int 4294967295) line 197 + 17 bytes
nsThreadPool::GetRequest(nsIThread * 0x023a12d0) line 458 + 10 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x023a1320) line 685 + 27 
bytes
nsThread::Main(void * 0x023a12d0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x023a1160) line 399 + 13 bytes
_threadstartex(void * 0x023a2f80) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()
For the record, what I saw in the console was this:

WEBSHELL+ = 1
plugins at: C:\PROGRAM FILES\NETSCAPE\COMMUNICATOR\PROGRAM\Plugins
plugins at: C:\MOZILLA\DEBUG\MOZILLA\DIST\WIN32_D.OBJ\BIN\plugins
Note: verifyreflow is disabled
Note: styleverifytree is disabled
Note: frameverifytree is disabled
has multiple monitor apis is 1
Move window by 456,356.5
start with profile: David
ProfileManager : StartApprunner
profileName passed in: DavidProfileName : David
ProfileDir  : C:\MOZILLA\Users50\default
WEBSHELL- = 0
WEBSHELL+ = 1
Initialized app shell component {18c2f989-b09f-11d2-bcde-00805f0e1353}, rv=0x000
00000
CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///C|/MOZILLA/Users50/default/c
hrome/user.css' failed.  Error code: 18
WEBSHELL+ = 2
Obtained name of Personal Toolbar from bookmarks string bundle.
Start reading in bookmarks.html
Finished reading in bookmarks.html  (270000 microseconds)
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet


This is roughly the same place I was hanging on the Mac (right after reading 
bookmarks).
Wait a sec... those look just like the old ones I gave... Oh well.  Perhaps 
there's more to see in the debugger.
You can get a really long output from the console in my duplicate bug 44409
I think this is the bug that I am seeing on all my builds.
(BSD/OS 4.2 beta 1, in case anyone cares.  Same thing for BSD/OS 4.1)

It crashes for me every time, all the time.  Here's what
a stack trace looks like for me.

Thanks.

-Kurt

(gdb) where
#0  0x297a74a8 in RDFServiceImpl::GetDataSource (this=0x81bce40, aURI=0x8046c5c
"rdf:bookmarks", 
    aDataSource=0x8046de0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/rdf/base/src/nsRDFService.cpp:1062
#1  0x2981a1d7 in nsXULDocument::CheckTemplateBuilder (aElement=0x8600080)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/rdf/content/src/nsXULDocument.cpp:5980
#2  0x29811c07 in nsXULDocument::ResumeWalk (this=0x81e1400)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/rdf/content/src/nsXULDocument.cpp:5219
#3  0x29815397 in nsXULDocument::OnStreamComplete (this=0x81e1400,
aLoader=0x84b22c0, context=0x0, 
    aStatus=0, stringLen=1284, 
    string=0x84f0000 "\n/**\n * Keyword dropdown actions.  [Netscape Commercial
Specific]\n **/\nfunction executeKeyword( aKeyword )\n  {\n    switch( aKeyword
)\n      {\n        case \"quote\":\n          gURLBar.focus();\n         "...)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/rdf/content/src/nsXULDocument.cpp:5613
#4  0x288cb971 in nsStreamLoader::OnStopRequest (this=0x84b22c0,
channel=0x85fd800, ctxt=0x0, 
    status=0, errorMsg=0x0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/netwerk/base/src/nsStreamLoader.cpp:120
#5  0x28949bdc in nsResChannel::EndRequest (this=0x85fd800, aStatus=0, aMsg=0x0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/netwerk/protocol/res/src/nsResChannel.cpp:704
#6  0x28949b74 in nsResChannel::OnStopRequest (this=0x85fd800,
transportChannel=0x85fd900, 
    context=0x0, aStatus=0, aMsg=0x0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/netwerk/protocol/res/src/nsResChannel.cpp:697
#7  0x28938c0e in nsFileChannel::OnStopRequest (this=0x85fd900,
transportChannel=0x8626e00, 
    context=0x0, aStatus=0, aMsg=0x0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/netwerk/protocol/file/src/nsFileChannel.cpp:628
#8  0x288a66fa in nsOnStopRequestEvent::HandleEvent (this=0x8576ec0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp:301
#9  0x288a5a37 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x84edf80)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp:97
#10 0x28132b0b in PL_HandleEvent (self=0x84edf80)
    at /scratch/homes/staff/lidl/moz_tip/mozilla/xpcom/threads/plevent.c:587
#11 0x281329ff in PL_ProcessPendingEvents (self=0x82527c0)
    at /scratch/homes/staff/lidl/moz_tip/mozilla/xpcom/threads/plevent.c:528
#12 0x281348cb in nsEventQueueImpl::ProcessPendingEvents (this=0x8252780)
---Type <return> to continue, or q <return> to quit---
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/xpcom/threads/nsEventQueue.cpp:356
#13 0x28e07d59 in event_processor_callback (data=0x8252780, source=5,
condition=GDK_INPUT_READ)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/widget/src/gtk/nsAppShell.cpp:158
#14 0x28e079d6 in our_gdk_io_invoke (source=0x836fe00, condition=G_IO_IN,
data=0x836fdf0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/widget/src/gtk/nsAppShell.cpp:58
#15 0x283c3020 in g_io_unix_dispatch (source_data=0x83a6f00,
current_time=0x80477d0, 
    user_data=0x836fdf0) at giounix.c:135
#16 0x283c4909 in g_main_dispatch (current_time=0x80477d0) at gmain.c:656
#17 0x283c4f13 in g_main_iterate (block=1, dispatch=1) at gmain.c:874
#18 0x283c50ac in g_main_run (loop=0x836fe30) at gmain.c:932
#19 0x282ebe97 in gtk_main () at gtkmain.c:476
#20 0x28e08c72 in nsAppShell::Run (this=0x82dd5c0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/widget/src/gtk/nsAppShell.cpp:334
#21 0x29b7602b in nsAppShellService::Run (this=0x8252740)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/xpfe/appshell/src/nsAppShellService.cpp:386
#22 0x805233f in main1 (argc=1, argv=0x8047a5c, nativeApp=0x0)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/xpfe/bootstrap/nsAppRunner.cpp:913
#23 0x80529a7 in main (argc=1, argv=0x8047a5c)
    at
/scratch/homes/staff/lidl/moz_tip/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1099
#24 0x804ba7e in __start ()

dbaron's console output above looks similar to
what I was seeing on linux.  I only see the problem
once in a while.

lidl@pix.net: this is hang, not a crash. I think your problem is unrelated.

As for me, I'm still seeing this on linux. I've noticed that it NEVER starts
when I run a build from gdb inside of XEmacs. I don't know if timing is
different there or what, but I now cannot debug builds inside of xemacs... I see
the exact same output as dbaron pasted above.

I've also started (as of yesterday) seeing an occasional failure bringing up
mail or complex dialog boxes just from the browser using the Mail button on the
taskbar... the console seems to indicate that the window should be starting, but
it never appears on the screen, the onload handler never fires, etc etc...

I have seen this hang in xemacs/gdb also, but I
was able to run sometimes in xemacs/gdb.  I'm using
rh6.0 and gdb-4.17.0.11-6.
Updating to Mac only OS.
Hardware: All → Macintosh
This is *NOT* mac specific, it's just more manifest under macOS.
Hardware: Macintosh → All
Checked in what I think is a fix: Added back a lock to mutually exclude cancel, 
suspend and resume on the file transport. Never fully concluded that this was the 
problem, but judging from my experience on mac, I think it is. With the fix, I 
can't reproduce it now.

btw, the checkin was r=waterson

fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I'd say warren has nailed it as I've just gone through 10 launch cycles without a 
hang.

thanks warren! All of those seeing the bug really appreciate the fix on this one
My appologies for inducing this bug in the first place. I didn't (and still 
don't exactly) see how my change caused a problem, but it obviously did. Sorry 
for holding you all up. I think the latest version of these file transport 
changes still have most of the performance benefits, as well as the 
synchronization fix.
I can verify this on mozilla win32 and Mac installer bits 071108 on NT, 98 OS9.
44616 verified with mac sea.bin bits because mail doesnt appear on teh tasks
list on installer build today.

I was able to launch a clean install mac mozilla 45 times without a freeze and
open a mail-news window from browser 45 times successfully.  I also tested
opening composer window from browser and that also worked without fail.

All we need is confirmation on Linux (and maybe more commercial confirmation)
and we can Verify this bug
Blocks: 45336
No longer see any hanging or crashing on start-up on all platforms using the 
commercial builds 2000-07-13-08-M17, but i noticed there were not any default 
bookmarks and then when you restart they return. (related?)
No that is an unrelated bug that has existed for a while now. It is bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=44397 if you want to take a look at 
it.
Ok well then, i am goin to verify this fix.
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.