If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Frequent hangs on shutdown, afterwards moz will not restart

VERIFIED FIXED in mozilla0.9.1

Status

SeaMonkey
Bookmarks & History
P1
critical
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: gabriel, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({hang})

Trunk
mozilla0.9.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
This problem has been occuring since at least moz0.8.1 and also in recent
nightlies. Quite often when I shut down Mozilla, it will just hang and I have to
kill the process manually. After that, the app will not restart unless I delete
my .mozilla directory.

I don't know how to reproduce this, but it seems to happen about once every 10
times.

Comment 1

17 years ago
This needs a keyword of hang and someone to verify it.

Comment 2

17 years ago
I have not seen this behavior in any recent nightlies or 0.8.1 with an old
profile (pre 0.7) and with new profiles.  
Keywords: hang

Comment 3

17 years ago
ok, first: kill your localstore.rdf file in your profile.  Does that help?

If not, try a totally new profile - does that fix it?

thanks
(Reporter)

Comment 4

17 years ago
Ok a few points.

First, this is occuring with newly created profiles.

Second, I tried deleting localsotre.rdf, mozilla still will not start.

What I mean by not starting - mozilla just sits there after 
 Registering plugin 0 for: "*","All types",".*"

ps aux shows it is using most ~80-90% of cpu so it is doing something.

If you can remind me how to get a stack trace with gdb I'll try and attach one.
(Reporter)

Updated

17 years ago
Hardware: Other → PC
(Reporter)

Comment 5

17 years ago
OK, this seems to be somehow related to bookmarks. My normal bookmark file is
about 100K, however once the profile becomes 'broken' the bookmarks file has
grown to over 5M !

Looking at bookmarks.html, the same entries seem to be repeated over and over
again. This reminds me of an old bug, so it may be a regression. I'll try and
find that old bug.
(Reporter)

Comment 6

17 years ago
Symptoms are similar to bug 51021

Could this have regressed ?
(Reporter)

Comment 7

17 years ago
OK, I figured out exactly what is going on. What is happening is that every time
I shut down mozilla, my bookmarks file grows much larger. Eventually, mozilla
just seems to sit there making a huge bookmarks file, until I kill the process.
After this mozilla takes an extremely long time to start up, because the
bookmarks file is so huge - giving the impression that it is broken.
(Reporter)

Comment 8

17 years ago
One other thing I've observed is that the file size increases only occur with
bookmarks exported from mozilla. If you export from NS4 and import into mozilla,
the file size remains the same. I now have the steps to reproduce:

1) Export bookmarks from mozilla.
2) Quit mozilla.
3) Delete bookmarks.html in ~/.mozilla
4) Import saved bookmarks back into mozilla
5) Look at the file size of bookmarks.html
6) Quit mozilla
7) Check the filesize of bookmarks.html

Expected results: bookmarks.html should be the same size in 7) as in 5)

Actual results: bookmarks file has more than doubled in size.

Comment 9

17 years ago
over to Ben.
Assignee: asa → ben
Component: Browser-General → Bookmarks
QA Contact: doronr → claudius

Comment 10

17 years ago
I am seeing the same hang on exit due to phantom windows generated when I try to
add bookmark.(bug 74027).
I have checked the size of my bookmarks.html, and indeed it was 5.6MB!

Comment 11

17 years ago
*** Bug 74207 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
Changing to All/All.
OS: Linux → All
Hardware: PC → All

Comment 13

17 years ago
nominating for 0.9
Target Milestone: --- → mozilla0.9

Comment 14

17 years ago
this may have been fixed in 2001040911 trunk.

Comment 15

17 years ago
*** Bug 74207 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 16

17 years ago
Wfm with Linux trunk build 2001041021.

Please mark as resolved.

Thanks.

Comment 17

17 years ago
Per reporter's comment and my experience, I am marking this as WFM after 0410 build.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

17 years ago
Marking as reopened. This just happened again to me again. Bookmarks exported
from mozilla and reimported, file size grew to 6M+.

Should have tested more before I said wfm, but it only seems to happen now
intermittently.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 19

17 years ago
please zip and attach your bookmarks file (mime type: application/zip)
(Reporter)

Comment 20

17 years ago
No need for me to attach bookmarks. I can now reproduce this 100%.

Just start with your default bookmarks (filesize 5400). Export this, shut down
mozilla, restart and import the saved bookmarks. You will see there are now
_two_ 'mozilla project' sections, and the filesize has grown to 20300 bytes.
Shut down mozilla and restart a few times, the filesize quickly grows. Note, I
shut down by clicking the window manager 'X' rather than File, Quit. I didn't
check whether this made a difference or not.

Let me know if you still have problems reproducing this.

Comment 21

17 years ago
Is the large Bookmarks.html file part a dupe of 73873?
(Reporter)

Comment 22

17 years ago
I would humbly suggest that 73873 be marked a dupe of this one (since this one
has steps to reproduce), and the symptoms appear to be the same. Perhaps change
the title to 'imported bookmarks file explosion' or something along those lines.

Comment 23

17 years ago
Can you add bookmarks after the Bookmarks.html size gets huge?
I think that this bug describes han on exit after trying to add a bookmark due
to large Bookmarks.html file.
Since bug 73873 describes that it is still possible to add a bookmark, this bug
should be kept separate.
This one might be marked dependent on bug 73873, though.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.9.1

Updated

17 years ago
Keywords: nsbeta1

Comment 24

17 years ago
nav triage team:

Looks serious, marking p1 and nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P1
Created attachment 31761 [details] [diff] [review]
this patch seems to do the trick...
A fix to an earlier bug removed duplicate checking when adding a bookmark to a 
container. However that fix reintroduced an older bug where the bookmark file 
would grow because of duplicates. The situation doesn't seem to affect a single 
duplicate (I hand-edited the file and duplicated one bookmark). The problem 
occurs when a duplicate bookmark-folder relationship is imported. i.e.:

Current bookmarks.html:
.. other bookmarks ..
My Folder, unique ID = "NC:#$!nerp" ->
   http://www.foopy.com/
.. more bookmarks ..

Import another bookmarks file, which includes:

.. imported stuff ..
My Folder, unique ID also = "NC:#$!nerp" ->
   http://www.foopy.com/
.. other imported stuff ..

If these IDs are ever the same, it seems the bookmarks get duplicated in the 
folder. Following this, something (I'm not sure what) spirals out of control and 
the world comes crashing down. bang. 

This patch here addresses the symptom by not relying on the ID attribute in the 
bookmarks.html file to name a folder. This is a reversion to the 4.x behaviour, 
which did not store folder IDs. I don't think it's necessary, my rudimentary 
testing did not reveal any bookmark updating problems. Each time you load the 
bookmarks file, each folder that is encountered has a unique folder id generated 
for it. This ensures (hopefully!) that such collisions/merges don't occur. 

I don't know how expensive the generation of the anonymous resource is (I should 
hope it's not too expensive) compared to parsing the ID out of an existing 
folder string. 

I'm copying waterson for comment and hopefully review. 
Created attachment 31807 [details] [diff] [review]
patch that also cleans up the use of the nsCOMPtr parameter to CreateAnonymousResource
Disregard the last patch. It is wrong. 
Created attachment 31808 [details] [diff] [review]
ok now I'm all confused, but this also compiles, and (at least appears to) work.

Comment 30

17 years ago
Does it fix the bug being reported in bug 73873 caused by non-ASCII characters
in Bookmarks.html, too?
Not that I know of. 

Comment 32

17 years ago
On problem with making the folder URIs be unique each time you load is that
you'll no longer be able to persist open/close state about the folder. Isn't the
right way to fix this is to detect duplicates at import time?
The thing is, that's what rjc was doing with his code that was calling 
IndexOf. The import operation simply calls the same code that is run 
when the app starts - BookmarksParser::Parse, but on a different file. 

The persistence thing is noted, however. I'll poke around and see if I can 
figure out exactly why the bookmarks file gets larger with such duplication

Comment 34

17 years ago
> The thing is, that's what rjc was doing with his code that was calling 
> IndexOf. The import operation simply calls the same code that is run 
> when the app starts - BookmarksParser::Parse, but on a different file. 

Gotcha. Two ideas here:

1. We could add a parameter ``aCheckDups'' that'd kick in the duplicate-
   checking code, so it's only done on import.

2. We could add a parameter ``aIgnoreID'' that'd force us to ignore the
   IDs (and instead generate unique ones), and set *that* only on import.

Comment 35

17 years ago
Er, ``add a parameter to BookmarkParser::Parse().''
(Reporter)

Comment 36

17 years ago
Wouldn't it just be enough to check for duplicates of the default bookmarks, or
is it more complicated than that ?

Comment 37

17 years ago
It's more complicated. Importing your current bookmarks file w/ at least one 
folder containing one bookmark should trigger this bug.
Chris, I like your second idea best. I'll try to produce a patch that implements
this. 

Comment 39

17 years ago
I'm gonna file an RFE eventually, but I should note here while your messing around with
this functionality that we are woeful when it comes to persistence of state across copy/move/
import/etc. in comparison to 4.x. Everytime I reinstall the "Mother of All Bookmarks File" I
have to go through and reset the state(expand) all the folders.
(Reporter)

Comment 40

17 years ago
Just to clarify, Mozilla does restart eventually, it's just that it takes a very
long time with such huge bm files. But you probably figured that by now anyway.
(Reporter)

Comment 41

17 years ago
Might I suggest that you add this to the release notes for 0.9, otherwise you
may find you get a large number of dupes if ppl export their bookmarks from
0.8.1 and import them into 0.9

Comment 42

17 years ago
*** Bug 79536 has been marked as a duplicate of this bug. ***

Comment 43

17 years ago
Ben, Do you think your on track for getting this resolved for mozilla0.9.1?

Comment 44

17 years ago
*** Bug 73873 has been marked as a duplicate of this bug. ***

Comment 45

17 years ago
while the huge bookmarks problem IS a cause of a shutdown hang/long startup lag.
I don't think it is the sole cause of shutdown hang.  I have been making
frequent copies of my bookmarks file ( and cookies ) now for those new nightly
install problems where I'm forced to delete the old profile & recreate it (
hasn't happened in while now, but I still make the backups before running
install).  I then copy in the old files rather than inporting.

That being said, I still get the intermitant hang when I shutdown Mozilla. 
Usually I notice because I can't restart it, look in taskmanager, & see that
it's still running, usually with over 40,000k mem usage, not the usual 20
some-odd.  I cancel the old one with taskmanager.  restart.  no noticable problems. 
Created attachment 34282 [details] [diff] [review]
fix, ignore ID attributes on imported bookmarks
waterson, can you r=?

Comment 48

17 years ago
Fix the funny tabs here. (I know, it's a hard tab.)

+  PRBool                      mIsImportOperation;
        char                            *mContents;

Otherwise, this fix looks great. r=waterson
I'll fix that, and move the assignment of 'id' outside the for loop while I'm at 
it. ;) 

Comment 50

17 years ago
Looks fine to me.  Who woulda thought <MENU> ... </MENU> existed in HTML?  
r=blake if you fix waterson's style nit and move id's assignment.
hey chris, can I make your r= a sr=?
Fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 53

17 years ago
I've imported and re-imported and quit and restart
and all of those things and at no point am i seeing unexplained growth of the BM file or
shutdown/restart hangs/delays.

VERIFIED Fixed with 20010515 builds. 
Status: RESOLVED → VERIFIED

Comment 54

17 years ago
*** Bug 80283 has been marked as a duplicate of this bug. ***

Comment 55

17 years ago
*** Bug 74215 has been marked as a duplicate of this bug. ***

Comment 56

17 years ago
*** Bug 78323 has been marked as a duplicate of this bug. ***

Comment 57

17 years ago
*** Bug 80191 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.