Closed Bug 29212 Opened 25 years ago Closed 24 years ago

Mozilla BookMarks created a Bookmark file of 17.3 M that crash at start up

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
All
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: jmbelo, Assigned: alecf)

References

Details

(Keywords: crash, regression, Whiteboard: [nsbeta3-])

Mozilla BookMarks created a Bookmark file of 17.3 M that crash at start up. Build Id 2000022216 NT 4 Exemple: ( if you wish i could send the original file ) <!DOCTYPE NETSCAPE-Bookmark-file-1> <!-- This is an automatically generated file. It will be read and overwritten. Do Not Edit! --> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> <TITLE>Bookmarks</TITLE> <H1>Bookmarks</H1> <DL><p> <DT><H3 ADD_DATE="916354466" LAST_MODIFIED="951331673" ID="NC:BookmarksRoot#$3c97f149">Sample FTP URLs</H3> <DL><p> <DT><A HREF="ftp://ftp.netscape.com/">FTP: Netscape</A> <DT><A HREF="ftp://xpnav.mcom.com/">FTP: XPNav</A> <DT><H3 ADD_DATE="916354466" LAST_MODIFIED="951331673" ID="NC:BookmarksRoot#$3c97f149">Sample FTP URLs</H3> <DL><p> <DT><A HREF="ftp://ftp.netscape.com/">FTP: Netscape</A> <DT><A HREF="ftp://xpnav.mcom.com/">FTP: XPNav</A> <DT><H3 ADD_DATE="916354466" LAST_MODIFIED="951331673" ID="NC:BookmarksRoot#$3c97f149">Sample FTP URLs</H3> <DL><p> <DT><A HREF="ftp://ftp.netscape.com/">FTP: Netscape</A> <DT><A HREF="ftp://xpnav.mcom.com/">FTP: XPNav</A> <DT><H3 ADD_DATE="916354466" LAST_MODIFIED="951331673" ID="NC:BookmarksRoot#$3c97f149">Sample FTP URLs</H3> <DL><p> <DT><A HREF="ftp://ftp.netscape.com/">FTP: Netscape</A> <DT><A HREF="ftp://xpnav.mcom.com/">FTP: XPNav</A> <DT><H3 ADD_DATE="916354466" LAST_MODIFIED="951331673" ID="NC:BookmarksRoot#$3c97f149">Sample FTP URLs</H3> And keeps repeting itself.
How to reproduce: go to manage bookmarks, select ftp folder edit->copy, edit>->paste and you get a 17.M to - 20.M bookmark.html file
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
OS: other → Windows NT
umm yeah, recursion is bad, mmmkay? I can definitely confirm this bug with 2000022414 WinNT build. submitted talkback report and referenced bug 29212. It crashes after you select paste and then will crash on startup until you trash that bookmarks file. isn't that really two related problems? 1. freaking out with self-referential folder contents. 2. crashing with large bm file.
Severity: normal → critical
Robert, I believe this is an interesting thought problem for you or waterson rather than us front-end types ... :-)
Assignee: slamm → rjc
This is pretty trivial to fix... just prevent recursion in the tree view.
Status: NEW → ASSIGNED
Target Milestone: M15
Fixed. (Prevent recursion when writing out bookmarks.)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I actualy thought I saw this fixed in an earlier build but I just tried it with the 2000032809 build on WinNT - and submitted my talkback report. After being unresponsive for a while seamonkey finally crashed with a stack overflow. REOPENING. All i did was selecta folder. select edit|Copy. Open the folder (root still selected). Then select edit|paste. The menu never dismissed and i eventually crashed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Claudius, do you have a stack trace?
I just tried this with a tip build on Win98, works OK.
The trick to reproducing this bug appears to be to make sure that the folder is open before doing the paste. A stack trace follows. Reassigning to Hyatt for a first glance, looks like an infinite loop in nsTreeRowGroupFrame::ComputeTotalRowCount(): NS_NewAtom(const char * 0x01833448) line 138 nsXULContentUtils::GetElementResource(nsXULContentUtils * const 0x022f5d50, nsIContent * 0x03f5b5b0, nsIRDFResource * * 0x0086258c) line 468 + 11 bytes nsXULContentUtils::GetElementRefResource(nsXULContentUtils * const 0x022f5d50, nsIContent * 0x03f5b5b0, nsIRDFResource * * 0x0086258c) line 526 + 20 bytes RDFGenericBuilderImpl::CreateTemplateAndContainerContents(nsIContent * 0x03f5b5b0, nsIContent * * 0x00000000, int * 0x00000000) line 2453 + 48 bytes RDFGenericBuilderImpl::CreateContents(RDFGenericBuilderImpl * const 0x035a13e0, nsIContent * 0x03f5b5b0) line 738 + 16 bytes nsXULDocument::CreateContents(nsXULDocument * const 0x035648b4, nsIContent * 0x03f5b5b0) line 2075 + 16 bytes nsXULElement::EnsureContentsGenerated() line 3484 + 27 bytes nsXULElement::ChildCount(const nsXULElement * const 0x03f5b5b0, int & 0) line 2232 + 8 bytes XULSortServiceImpl::InsertContainerNode(XULSortServiceImpl * const 0x02d4fa30, nsIRDFCompositeDataSource * 0x035a1380, nsRDFSortState * 0x035a1404, nsIContent * 0x03598f90, nsIContent * 0x03f5bd60, nsIContent * 0x03f5b5b0, nsIContent * 0x03f5b1b0, int 0) line 2205 + 19 bytes RDFGenericBuilderImpl::BuildContentFromTemplate(nsIContent * 0x0359b7d0, nsIContent * 0x03f5bd60, nsIContent * 0x03f5b5b0, int 1, nsIRDFResource * 0x02d56970, int 0, nsIContent * * 0x00000000, int * 0x00000000) line 2126 + 81 bytes RDFGenericBuilderImpl::BuildContentFromTemplate(nsIContent * 0x0359b860, nsIContent * 0x03f5bd60, nsIContent * 0x03f5bd60, int 1, nsIRDFResource * 0x02d56970, int 0, nsIContent * * 0x00000000, int * 0x00000000) line 1926 + 57 bytes RDFGenericBuilderImpl::CreateWidgetItem(nsIContent * 0x03f5bd60, nsIRDFResource * 0x02d56670, nsIRDFResource * 0x02d56970, int 0, nsIContent * * 0x00000000, int * 0x00000000) line 2226 + 43 bytes RDFGenericBuilderImpl::CreateContainerContents(nsIContent * 0x03f5bd60, nsIRDFResource * 0x0252dc80, int 0, nsIContent * * 0x00000000, int * 0x00000000) line 2567 + 45 bytes RDFGenericBuilderImpl::CreateTemplateAndContainerContents(nsIContent * 0x03f5bd60, nsIContent * * 0x00000000, int * 0x00000000) line 2458 + 34 bytes RDFGenericBuilderImpl::CreateContents(RDFGenericBuilderImpl * const 0x035a13e0, nsIContent * 0x03f5bd60) line 738 + 16 bytes nsXULDocument::CreateContents(nsXULDocument * const 0x035648b4, nsIContent * 0x03f5bd60) line 2075 + 16 bytes nsXULElement::EnsureContentsGenerated() line 3484 + 27 bytes nsXULElement::ChildCount(const nsXULElement * const 0x03f5bd60, int & 8799564) line 2232 + 8 bytes nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f5bd60) line 667 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f5a410) line 679 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f5ac00) line 688 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f59260) line 679 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f59a50) line 688 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f58110) line 679 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f589f0) line 688 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f47330) line 679 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f57770) line 688 nsTreeRowGroupFrame::ComputeTotalRowCount(int & 6672, nsIContent * 0x03f57dc0) line 679 and nsTreeRowGroupFrame::ComputeTotalRowCount continues to recurse forever until the stack is blown out.
Assignee: rjc → hyatt
Status: REOPENED → NEW
Also cc'ing Chris (Waterson). I'm wondering if this bug is really a by-product of bug # 29359 regarding being eager with building up content. Due to the cyclic loop in the RDF graph being introduced by *this* bug via copy/paste of a node into itself, is the tree getting panic fits?
?
Assignee: hyatt → rjc
David?
Assignee: rjc → hyatt
Assignee: hyatt → waterson
Reassigning to waterson.
lazy bastard.
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
not nsbeta2, move to M17
Target Milestone: M16 → M17
Doesn't crash anymore, at least to me, but i still can't get it to do copy->paste/delete of a folder. but i guess it's a diferent bug now. So i guess this one should be closed and opened if necesssary one for "copy->paste/delete of a folder" in Mozilla BookMarks tested in Build id 2000051920 W2000.
yeah that should definitely be a different bug - it may already have been filed. I'm curious as to what waterson and rjc believe as to whether this could have just been a miracle fix, or some other fix took care of this, or what. I test this again shortly
Just to point out this also happens to me in Win98 M16; not just NT
Apparently, you can't cut, copy, or paste folders anymore. Just tried this: here's the error I get when I try to "Paste" a folder... ->>>>>>>>>>>>>> Read Clipboard from memory JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITransferable.getTransferData]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/bookmarks/bookmarks.js :: doPaste :: line 307" data: no] Pasting *individual* bookmarks is fine. I've filed bug 46052, and made this a dependent. (Can't verify it until we see "paste" working, anyway...)
Depends on: 46052
Target Milestone: M17 → ---
I can paste folders fine on mac OS 8.5.1 with the 2000072608 build. So fine that I can paste a folder inside of itself and open up that whole can of worms. After the paste my mac hung and I had to reboot the machine. Since restarting seamonkey my drive spun for about 5 min doing lord knows what. Attempting to open the embedded copy of the folder in the Manage Bookmarks window has caused me to hang(and reboot) yet again. Adding some keywords (nsbeta3,regression) and changing platform to ALL.
Keywords: nsbeta3, regression
Hardware: PC → All
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
Alec, here's one of those bookmarks bugs I was talking about.
Assignee: waterson → alecf
Status: ASSIGNED → NEW
removing nsbeta3 keywords
Status: NEW → ASSIGNED
Keywords: nsbeta3
Netscape Nav Triage Team: marking as fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
okay the crash is gone. The bahavior is still a little quirky but I've decided to verify this and open a new bug for the remaining behavior (duplicate empty copies of the folder are created as a child and peer of the original). VERIFIED Fixed with 2001041004 builds
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.