Closed Bug 106148 Opened 23 years ago Closed 23 years ago

mork dll loaded on startup from nsGlobalHistory::AddPage

Categories

(Core Graveyard :: History: Global, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED WONTFIX
mozilla0.9.8

People

(Reporter: dp, Assigned: dp)

References

Details

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
Blocks: 7251
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.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Mork gets loaded after the mainwindow becomes visible. Delaying it further is
not worth the effort.
Status: ASSIGNED → RESOLVED
Closed: 23 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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.