113378 - somehow my history.dat was corrupted, in relatively normal usage

Status: RESOLVED WORKSFORME

(Core Graveyard :: History: Global, defect)

Description

[John Morrison]

I had recently created this profile, and was just going through normal testing 
and triage of bugs today. I had shut down and restarted several times with no 
problem. But after my most recent exit, I now always crash on startup (trunk 
mozilla build win2k, pulled about 1:30am Dec 02).

I'll attach the actually history.dat (thank goodness I hadn't visited 
britneyspears.com today, or I'd be embarrassed to attach it).

This probably needs someone who knows orkins and yarns and morks to have a
look at why this is crashing.

Comment 1

[John Morrison]

Attachment: history.dat which crashes on startup; don't know how it got horked

Comment 2

[Jerome Lacoste]

Attachment: my history - same problem?

I just had the same problem. Here's my history (zipped)

Comment 3

[Jerome Lacoste]

I've had as well many talkbacks for the problem.
TB117736Z, TB117672W, TB117639Q, TB117618Z, TB117595Z, TB117575G
Most of them where reproduced by clicking on a link or by typing a URL in the
URL box.
I deleted the history.dat and it now works.
Hope it helps.

I think there are two problems:
- the history got corrupted in normal usage
- the browser crashed when history is corrupted. It should not. I posted another
bug for that: bug 113813

Comment 4

[David :Bienvenu]

the most popular and only reproducible way of corrupting history.dat is to run
two instances of mozilla/netscape at the same time.

Comment 5

[John Morrison]

To the best of my knowledge, I hadn't run comm. with that profile. However, 
that doesn't help narrowing it down anymore than what I initially said 
"It just 'happened'". Sorry I can't say anything more reproducible.

Comment 6

[Blake Ross]

Orkins and morks and yarns, oh my.  alec or bienvenu know them best...

Comment 7

[David :Bienvenu]

the remaining issue is that history.dat was corrupted - we no longer crash with
the attached history.dat. The corruption has to do with the same string written
to the db more than once, which looks like a classic case of having two clients
writing to the same db. In theory, profile locking should prevent this, but I
haven't really seen profile locking working.

Comment 8

[crassius]

I've been watching bug #31575 for resolution of this problem, and am wondering
if I'm in the right place. I don't use a second profile, and I never run two
instances of mozilla. I will occasionally use 'open in new window' on a link,
but the history.dat gets corrupted several times a day even with just one window
open. Often, this is associated with a crash of mozilla (which after updating to
1.4 locks the whole system now), but sometimes mozilla keeps running by just
deleting the history and starting a new one.

Comment 9

[crassius]

For those still struggling with history.dat corruption, here are my results so
far. Using Mozilla 1.3 on winME I lost my history 5 or 6 times a day when
Mozilla crashed out. Using Mozilla 1.4 I lost my history 5 or 6 times a day when
Mozilla crashed the whole system out. Using the workaround from bug#204374 about
GDI resource exhaustion, (set browser.cache.memory.enable=false) I only had
Mozilla 1.4 crash out the system 3 times in a whole week and only lost my
history on two of those times. Now, using Mozilla 1.5a [2003081004] for 4 days
now and pushing it hard, with browser.cache.memory.enable set back to true where
it belongs, I've had no crashes yet and no loss of history.dat. I don't
particularly like beta versions, but would recommend using the beta over using
the workaround if you are still losing your history.

Comment 10

[Christian Franke]

On Win98SE I found the following method to recover history.dat after system
crash (Mozilla 1.4 and before, still not tested with 1.5a):

First make sure that autostart of scandisk is disabled
(AutoScan=0 in MSDOS.SYS).

After a system crash (mozilla running) occurs, do the following:
1. Reboot.
2. copy history.dat to some temp place (copy, not move or rename).
3. Run scandisk. Scandisk reports allocation errors(!) on history.dat (and in
very rare cases on panacea.dat). Let scandisk fix the errors.
4a. Start Mozilla, open history.
Result: History set to empty, because moz detects history.dat corruption.
4b. Copy saved history.dat from step 2 back to profile and then start Mozilla.
Result: History is back, only some entries may be lost.

An improved file flushing strategy may possibly prevent the allocation errors.

Comment 11

[David E. Ross]

I am not sure what I describe here is the same bug or another one.  This
happened with Mozilla 1.5RC1 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5)
Gecko/20030916).  

I noticed this morning that, if I shut down Mozilla after some Web surfing and
then started it, none of the links I visited were indicated as such in my
bookmarks file (which I use as my home page).  I checked history.dat and noticed
that the date of latest modification was yesterday.  

My PC did crash early this morning while Mozilla was open.  I was able to shut
down all applications (gracefully I hope), including Mozilla, before rebooting.  

To correct my problem, I renamed history.dat as xhistory.dat.  I then copied the
file and renamed the copy as history.dat.  After that, everything worked fine.  

I have seen this before with 1.4.  This was the first time I saw it with 1.5. 
If this is not 113378, let me know so that I can submit a new bug report.  

Comment 12

[Andrew Hagen]

The last post here was five-and-a-half years ago. The issue reported was resolved at the latest in bug 374945 (implementation of Places). 

Resolving WFM.