Stack for mork dll load. Looks like onStart is causing global history to get updated and that causes mork to get loaded. (gdb) bt #0 nsDll::BreakAfterLoad (this=0x8065ba8, nsprPath=0x8867378 "/home/dp/moz/mozilla/dist/bin/components/libmork.so") at xcDll.cpp:535 #1 0x4018e972 in nsDll::Load (this=0x8065ba8) at xcDll.cpp:360 #2 0x401879ec in nsNativeComponentLoader::GetFactory (this=0x80627f8, aCID=@0x807cde0, aLocation=0x807ce18 "rel:libmork.so", aType=0x8062858 "application/x-mozilla-native", _retval=0xbffff1a0) at nsNativeComponentLoader.cpp:124 #3 0x401ddc59 in nsFactoryEntry::GetFactory (this=0x807cde0, aFactory=0xbffff1a0, mgr=0x8061d80) at nsComponentManager.h:332 #4 0x40182599 in nsComponentManagerImpl::FindFactory (this=0x8061d80, aClass=@0x425fb2b0, aFactory=0xbffff1a0) at nsComponentManager.cpp:1324 #5 0x40182819 in nsComponentManagerImpl::CreateInstance (this=0x8061d80, aClass=@0x425fb2b0, aDelegate=0x0, aIID=@0x42600840, aResult=0xbffff230) at nsComponentManager.cpp:1477 #6 0x40186066 in nsComponentManager::CreateInstance (aClass=@0x425fb2b0, aDelegate=0x0, aIID=@0x42600840, aResult=0xbffff230) at nsComponentManager.cpp:3016 #7 0x425bc33e in nsGlobalHistory::OpenDB (this=0x8760a18) at nsGlobalHistory.cpp:2144 #8 0x425b64e8 in nsGlobalHistory::AddPage (this=0x8760a18, aURL=0x87ca0d8 "http://www.mozilla.org/start") at nsGlobalHistory.cpp:554 #9 0x4166972a in nsDocShell::AddToGlobalHistory (this=0x869bfc8, aURI=0x8830560) at nsDocShell.cpp:5814 #10 0x4165fec1 in nsDocShell::OnStateChange (this=0x869bfc8, aProgress=0x869c7ec, aRequest=0x88305b8, aStateFlags=196610, aStatus=0) at nsDocShell.cpp:3701 #11 0x40edc5fb in nsDocLoaderImpl::FireOnStateChange (this=0x869c7d8, aProgress=0x869c7ec, aRequest=0x88305b8, aStateFlags=196610, aStatus=0) at nsDocLoader.cpp:1109 #12 0x40edd09a in nsDocLoaderImpl::OnRedirect (this=0x869c7d8, aOldChannel=0x88305b8, aNewChannel=0x8834d40) at nsDocLoader.cpp:1296 #13 0x40a5db95 in nsHttpChannel::ProcessRedirection (this=0x88305b8, redirectType=302) at nsHttpChannel.cpp:1222 #14 0x40a5b279 in nsHttpChannel::ProcessResponse (this=0x88305b8) at nsHttpChannel.cpp:510 #15 0x40a61e62 in nsHttpChannel::OnStartRequest (this=0x88305b8, request=0x8842da4, ctxt=0x0) at nsHttpChannel.cpp:2276 #16 0x40a7de82 in nsOnStartRequestEvent::HandleEvent (this=0x887d988) at nsRequestObserverProxy.cpp:125 #17 0x40a18b3f in nsARequestObserverEvent::HandlePLEvent (plev=0x887d988) at nsRequestObserverProxy.cpp:79 #18 0x4018f9b6 in PL_HandleEvent (self=0x887d988) at plevent.c:590 #19 0x4018f86b in PL_ProcessPendingEvents (self=0x809afa8) at plevent.c:520 #20 0x40190d1a in nsEventQueueImpl::ProcessPendingEvents (this=0x805e1b0) at nsEventQueue.cpp:389 #21 0x40f32b4c in ?? () from /home/dp/moz/mozilla/dist/bin/components/libwidget_gtk.so #22 0x40f32843 in ?? () from /home/dp/moz/mozilla/dist/bin/components/libwidget_gtk.so #23 0x4040b01e in ?? () from /usr/lib/libglib-1.2.so.0 #24 0x4040c7f3 in ?? () from /usr/lib/libglib-1.2.so.0 #25 0x4040cdd9 in ?? () from /usr/lib/libglib-1.2.so.0 #26 0x4040cf8c in ?? () from /usr/lib/libglib-1.2.so.0 #27 0x40321803 in ?? () from /usr/lib/libgtk-1.2.so.0 #28 0x40f33155 in ?? () from /home/dp/moz/mozilla/dist/bin/components/libwidget_gtk.so #29 0x4084fea9 in ?? () from /home/dp/moz/mozilla/dist/bin/components/libnsappshell.so #30 0x0805474b in main1 (argc=1, argv=0xbffffa7c, nativeApp=0x0) at nsAppRunner.cpp:1286 #31 0x080553a7 in main (argc=1, argv=0xbffffa7c) at nsAppRunner.cpp:1608 #32 0x40557177 in ?? () from /lib/i686/libc.so.6
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.7
Yes, to add the page loaded on startup to history. How do you intend to fix this?
seems pretty invalid to me - history uses mork, and onStart puts the start page in the history.
I was exploring if there was any way for delaying this. Ideas welcome. This is what struck me: - What if History held an in memory list of visited pages and flushed it to db only when a certain limit is reached or at shutdown - What if we add a page to history after the page is loaded
Of course, whether we even try to fix it or not will depend on the cost. I will add timing analysis from an optimized build of the cost of loading mork and reading in the db.
I agree that there's probably some room for improvement here if timings show it's worth it; users don't change their start page frequently. Of course, global history clears by default every 9 days. I think ultimately the least hackiest solution is to force the window to show first and then do all work related to loading the page, as IE very obviously does. jag once had a patch to do this and it made things noticeably speedier, but he backed it out due to apparent timing issues. I still think that warrants investigation.
my current homepage is http://www.rpfuller.com/odp/random.cgi well, if you can call it a homepage. i get a random page each time i run mozilla or open a new window. [so much for static homepages] the idea of delaying history writes until after page load (or idle) seems good to me.
I don't think this is worth attacking, frankly. Mork is used to store history, and as soon as you load the first page, then you're going to start doing link coloring. link coloring is going to drag in global history (how else you gonna know which links to color) and that will load mork. On an off note, I've specifically delayed the load of mork if you're loading about:blank - we just don't add that to history, which means mork doesn't have to load. This is a win only if this is your homepage of course...
a better idea might be to try to compact mork more often, so that the reading of history.dat is smaller. Maybe we want to do this every time the user has been idle for more than a few minutes or something? Not sure. One way of attacking this, which is really way too much complexity if you ask me, is to asynchronously read in history when AddPage() gets called... but you'll have to finish loading history synchronously as soon as the first link wants to be colored.
Mork gets loaded after the mainwindow becomes visible. Delaying it further is not worth the effort.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
mass-verifying WontFix bugs which haven't changed since 2001-12-31. use the search string "BoletusEdulis" if you want to filter out this msg.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.