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.