113287 - corrupted history.dat causes crash on startup

Status: VERIFIED FIXED

(Core Graveyard :: History: Global, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ever since the mork rewrite landing, starting with a corrupted history.dat has
caused a crash on startup.  (I'm pretty sure this was the mork landing -- I see
this roughly every other day or so.)  My history.dat gets corrupted often due to
bug 31575.  It used to be that we wiped out the old history but were able to
start successfully.  Now we crash.  Since it's pretty easy to get this
corruption of history.dat, I think this is a reasonably serious crash.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: example corrupted history.dat

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

stack trace of crash (crashing in malloc usually means the heap is corrupt):

#0  chunk_alloc (ar_ptr=0x409c5f00, nb=264) at malloc.c:2886
#1  0x4091c13a in __libc_malloc (bytes=256) at malloc.c:2714
#2  0x401eea42 in malloc (size=256)
    at /builds/trunk/mozilla/xpcom/base/nsTraceMalloc.c:1353
#3  0x409f3f4d in __builtin_new (sz=256) from /usr/lib/libstdc++-libc6.2-2.so.3
#4  0x4374db10 in orkinHeap::Alloc (this=0x86e5438, mev=0x86e5474, inSize=256, 
    outBlock=0xbfffea3c) at /builds/trunk/mozilla/db/mork/src/orkinHeap.cpp:91
#5  0x43759d4d in morkMap::clear_alloc (this=0x86c6410, ev=0x86e5448, 
    inSize=256) at /builds/trunk/mozilla/db/mork/src/morkMap.cpp:335
#6  0x43759f00 in morkMap::new_changes (this=0x86c6410, ev=0x86e5448, 
    inSlots=256) at /builds/trunk/mozilla/db/mork/src/morkMap.cpp:391
#7  0x4375a05c in morkMap::new_arrays (this=0x86c6410, ev=0x86e5448, 
    old=0xbfffeae0, inSlots=256)
    at /builds/trunk/mozilla/db/mork/src/morkMap.cpp:433
#8  0x43759a42 in morkMap::InitMap (this=0x86c6410, ev=0x86e5448, inSlots=256)
    at /builds/trunk/mozilla/db/mork/src/morkMap.cpp:250
#9  0x43759917 in morkMap::morkMap (this=0x86c6410, ev=0x86e5448, 
    inUsage=@0x43787dc2, ioHeap=0x0, inKeySize=4, inValSize=4, inSlots=256, 
    ioSlotHeap=0x86e5438, inHoldChanges=1 '\001')
    at /builds/trunk/mozilla/db/mork/src/morkMap.cpp:214
#10 0x43759197 in morkIntMap::morkIntMap (this=0x86c6410, ev=0x86e5448, 
    inUsage=@0x43787dc2, inValSize=4, ioHeap=0x0, ioSlotHeap=0x86e5438, 
    inHoldChanges=1 '\001')
---Type <return> to continue, or q <return> to quit---
    at /builds/trunk/mozilla/db/mork/src/morkIntMap.cpp:91
#11 0x4375c5ba in morkNodeMap::morkNodeMap (this=0x86c6410, ev=0x86e5448, 
    inUsage=@0x43787dc2, ioHeap=0x0, ioSlotHeap=0x86e5438)
    at /builds/trunk/mozilla/db/mork/src/morkNodeMap.cpp:94
#12 0x437663ee in morkRowSpaceMap::morkRowSpaceMap (this=0x86c6410, 
    ev=0x86e5448, inUsage=@0x43787dc2, ioHeap=0x0, ioSlotHeap=0x86e5438)
    at /builds/trunk/mozilla/db/mork/src/morkRowSpace.cpp:660
#13 0x4376730e in morkStore::morkStore (this=0x86c63b8, ev=0x86e5448, 
    inUsage=@0x43787dc0, ioNodeHeap=0x86e5438, inFactory=0x86e5368, 
    ioPortHeap=0x86e5438)
    at /builds/trunk/mozilla/db/mork/src/morkStore.cpp:226
#14 0x437565a7 in morkFactory::CreateNewFileStore (this=0x86e5368, 
    mev=0x86e5474, ioHeap=0x86e5438, ioFile=0x86e5544, 
    inOpenPolicy=0xbfffec90, acqStore=0x85f8364)
    at /builds/trunk/mozilla/db/mork/src/morkFactory.cpp:635
#15 0x42f72194 in nsGlobalHistory::OpenNewFile (this=0x85f8300, 
    factory=0x86e5394, 
    filePath=0x86e54e0 "/u/dbaron/.mozilla/Mozilla/dgljx50g.slt/history.dat")
    at
/builds/trunk/mozilla/xpfe/components/history/src/nsGlobalHistory.cpp:2322
#16 0x42f71bac in nsGlobalHistory::OpenDB (this=0x85f8300)
    at
/builds/trunk/mozilla/xpfe/components/history/src/nsGlobalHistory.cpp:2234
---Type <return> to continue, or q <return> to quit---
#17 0x42f6accc in nsGlobalHistory::AddPage (this=0x85f8300, 
    aURL=0x86b4e80 "http://www.people.fas.harvard.edu/~dbaron/")
    at
/builds/trunk/mozilla/xpfe/components/history/src/nsGlobalHistory.cpp:577#18
0x4166e5c2 in nsDocShell::AddToGlobalHistory (this=0x85d7568, 
    aURI=0x869a8a0) at /builds/trunk/mozilla/docshell/base/nsDocShell.cpp:5534
#19 0x4166a3bc in nsDocShell::OnNewURI (this=0x85d7568, aURI=0x869a8a0, 
    aChannel=0x869a9c8, aLoadType=1)
    at /builds/trunk/mozilla/docshell/base/nsDocShell.cpp:4799
#20 0x4166b280 in nsDocShell::OnLoadingSite (this=0x85d7568, 
    aChannel=0x869a9c8)
    at /builds/trunk/mozilla/docshell/base/nsDocShell.cpp:5029
#21 0x416641b1 in nsDocShell::CreateContentViewer (this=0x85d7568, 
    aContentType=0xbffff074 "text/html", request=0x869a9c8, 
    aContentHandler=0xbffff120)
    at /builds/trunk/mozilla/docshell/base/nsDocShell.cpp:3532
#22 0x416785a6 in nsDSURIContentListener::DoContent (this=0x85d7928, 
    aContentType=0xbffff074 "text/html", aIsContentPreferred=0, 
    request=0x869a9c8, aContentHandler=0xbffff120, aAbortProcess=0xbffff0c0)
    at /builds/trunk/mozilla/docshell/base/nsDSURIContentListener.cpp:107
#23 0x40bd71b9 in nsDocumentOpenInfo::DispatchContent (this=0x869ab80, 
    request=0x869a9c8, aCtxt=0x0)
    at /builds/trunk/mozilla/uriloader/base/nsURILoader.cpp:355
---Type <return> to continue, or q <return> to quit---
#24 0x40bd69e1 in nsDocumentOpenInfo::OnStartRequest (this=0x869ab80, 
    request=0x869a9c8, aCtxt=0x0)
    at /builds/trunk/mozilla/uriloader/base/nsURILoader.cpp:226
#25 0x40ce5499 in nsHttpChannel::ProcessNormal (this=0x869a9c8)
    at /builds/trunk/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:571
#26 0x40ce4fc7 in nsHttpChannel::ProcessResponse (this=0x869a9c8)
    at /builds/trunk/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:483
#27 0x40cec532 in nsHttpChannel::OnStartRequest (this=0x869a9c8, 
    request=0x86b2ac4, ctxt=0x0)
    at /builds/trunk/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:2270
#28 0x40d144ac in nsOnStartRequestEvent::HandleEvent (this=0x42c03150)
    at /builds/trunk/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp:161
#29 0x40c9768c in nsARequestObserverEvent::HandlePLEvent (plev=0x42c03150)
    at /builds/trunk/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp:115
#30 0x401e2444 in PL_HandleEvent (self=0x42c03150)
    at /builds/trunk/mozilla/xpcom/threads/plevent.c:590
#31 0x401e2259 in PL_ProcessPendingEvents (self=0x80b0e78)
    at /builds/trunk/mozilla/xpcom/threads/plevent.c:520
#32 0x401e448a in nsEventQueueImpl::ProcessPendingEvents (this=0x807cfe0)
    at /builds/trunk/mozilla/xpcom/threads/nsEventQueue.cpp:388
#33 0x40edd474 in event_processor_callback (data=0x807cfe0, source=7, 
    condition=GDK_INPUT_READ)
    at /builds/trunk/mozilla/widget/src/gtk/nsAppShell.cpp:184
---Type <return> to continue, or q <return> to quit---
#34 0x40edd053 in our_gdk_io_invoke (source=0x8227cd0, condition=G_IO_IN, 
    data=0x8227cc0) at /builds/trunk/mozilla/widget/src/gtk/nsAppShell.cpp:77
#35 0x4076d01e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#36 0x4076e7f3 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#37 0x4076edd9 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#38 0x4076ef8c in g_main_run () from /usr/lib/libglib-1.2.so.0
#39 0x40683803 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#40 0x40eddae9 in nsAppShell::Run (this=0x80be6c8)
    at /builds/trunk/mozilla/widget/src/gtk/nsAppShell.cpp:349
#41 0x40e7f005 in nsAppShellService::Run (this=0x80bdcf0)
    at /builds/trunk/mozilla/xpfe/appshell/src/nsAppShellService.cpp:302
#42 0x080589e5 in main1 (argc=3, argv=0xbffff6bc, nativeApp=0x0)
    at /builds/trunk/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1269
#43 0x080596b7 in main (argc=3, argv=0xbffff6bc)
    at /builds/trunk/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1599
#44 0x408b9177 in __libc_start_main (main=0x805949c <main>, argc=3, 
    ubp_av=0xbffff6bc, init=0x80532c0 <_init>, fini=0x8061424 <_fini>, 
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff6ac)
    at ../sysdeps/generic/libc-start.c:129

Comment 3

[David :Bienvenu]

Taking, I'll look at this today.

Comment 4

[David :Bienvenu]

Attachment: proposed fix

Don't call closeMdbObject - it should be removed because of our move to xpcom
ref-counting semantics. The caller will just need to make sure that file
references are removed in order for the file handle to get release - in this
case, history is holding onto a file reference.

Comment 5

[David :Bienvenu]

requesting r/sr. I believe this was the only caller to CloseMdbObject left in
the tree - I'll file a separate bug to remove it completely. If you could review
this quickly, that would be great since it's a top crash for people with
corrupted history databases.

Comment 6

[Navin Gupta]

Comment on attachment 60325 [details] [diff] [review]
proposed fix

r=naving

Comment 7

[(not reading, please use [e-mail] instead)]

Comment on attachment 60325 [details] [diff] [review]
proposed fix

sr=sspitzer

Comment 8

[David :Bienvenu]

fix checked in.

Comment 9

[David :Bienvenu]

*** Bug 113813 has been marked as a duplicate of this bug. ***

Comment 10

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]