corrupted history.dat causes crash on startup

VERIFIED FIXED

Status

VERIFIED FIXED
17 years ago
13 days ago

People

(Reporter: dbaron, Assigned: Bienvenu)

Tracking

({crash})

Trunk
x86
Linux
crash

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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.
Created attachment 60179 [details]
example corrupted history.dat
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
(Assignee)

Comment 3

17 years ago
Taking, I'll look at this today.
Assignee: blakeross → bienvenu
(Assignee)

Comment 4

17 years ago
Created attachment 60325 [details] [diff] [review]
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.
(Assignee)

Comment 5

17 years ago
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.
Status: NEW → ASSIGNED
Keywords: crash

Comment 6

17 years ago
Comment on attachment 60325 [details] [diff] [review]
proposed fix

r=naving
Attachment #60325 - Flags: review+
Comment on attachment 60325 [details] [diff] [review]
proposed fix

sr=sspitzer
Attachment #60325 - Flags: superreview+
(Assignee)

Comment 8

17 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 9

17 years ago
*** Bug 113813 has been marked as a duplicate of this bug. ***
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.]
Status: RESOLVED → VERIFIED

Updated

13 days ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.