Closed Bug 207636 Opened 22 years ago Closed 16 years ago

FF10 M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla if imported IE favorites were deleted [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin]

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: rlf9, Unassigned)

References

Details

(Keywords: crash, helpwanted, topcrash+)

Crash Data

Attachments

(1 file, 4 obsolete files)

Crash report generated by Mozilla-Mac 1.7RC1 showing crash at nsRDFConMemberTestNode::FilterInstantiations
8.47 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030529 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030529 Other reports claim extreme slowdown and even freezing but this is actually crashing, and it's every time. NOTE: This is no different for me than was your 1.4b release except that this time I am also reporting it as a bug instead of merely providing the usual automatic Talkback reports. Reproducible: Always Steps to Reproduce: 1. Start up Mozilla 1.4fc1 2. Reveal bookmarks list via (Cmd-B) key combo 3. Search for (Cmd-F) any key word in any bookmark in the list Actual Results: After several seconds, Mozilla simply vanishes, that is, crashes. No Error # in resulting crash info box. Expected Results: Should promptly find every instance of the search word (e.g. "mozilla") and promptly display a list of each URL containing it. Unfortunately I don't have MacsBug and can't provide a Talkback Crash ID because I had foolishly deleted the crash log's contents. After posting this, I can reproduce the error again and post its ID though. The machine is a 1 GHz Titanium Powerbook with 1024MB installed RAM. Mozilla 1.4a nor previous builds did not present this problem here. During all of Mozilla's life as a Mac program, my bookmarks.html file has never been less than 600KB.
The latest Talkback ID I have for this bug is TB272341Z.
Confirmed using FizzillaMach/2003-05-29-08-trunk and 1.4 RC1 (FizzillaMach/2003-05-29-05-1.4), generating TB272369E and TB272371W respectively, though my bookmarks.html file is only 28 KB in size. Nominating blocking1.4?.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.4?
Keywords: crash
Summary: Find Bookmark in Large 700KB Bookmarks File Crashes Mozilla Every Time → Find Bookmark in Large 700KB Bookmarks File Crashes Mozilla Every Time [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl]
Summary: Find Bookmark in Large 700KB Bookmarks File Crashes Mozilla Every Time [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl] → Search Bookmarks operation in Manage Bookmarks crashes Mozilla [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl]
-> Jan
Assignee: chanial → varga
Summary: Search Bookmarks operation in Manage Bookmarks crashes Mozilla [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl] → Find Bookmark in Large 700KB Bookmarks File Crashes Mozilla Every Time [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl]
Summary: Find Bookmark in Large 700KB Bookmarks File Crashes Mozilla Every Time [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl] → Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl]
I need a test file for this.
Well, I was able to reproduce this once using a new profile, generating TV272448H, but not subsequently. I'll keep trying. FWIW, some of the stacks look very, very different.
Okay, reproduced it again, generating TB273238W. 1. Create a new profile 2. Quit Mozilla 3. Replace new profile's bookmarks.html with my bookmarks.html 4. Restart Mozilla 5. Press Command+b, then command+f, then type "gecko" and press return. Kerblam. It doesn't happen with the default bookmarks.html, or by importing my bookmark.html. Jan, I'll send you my bookmarks.html via e-mail. Please delete it when you're done.
Hm, tried it again and it didn't happen. Try it two or three times to be sure. I think my attached stack may be the wrong one. The real stack appears to crash at nsFixedSizeAllocator::FindBucket.
Summary: Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ CompositeAssertionEnumeratorImpl::CompositeAssertionEnumeratorImpl] → Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsFixedSizeAllocator::FindBucket]
I've asked a few other people to try, and so far none has had this trouble with 1.4fc1. The idea that a 28K file can reproduce the same crash encourages me to spend some more time on this during the next few days though. I'll report back if I come up with more that's possibly useful to you.
Blocks: 209542
Confirmed for both 1.4rc2 and 1.5a build of 16 June 2003. My bookmarks are 400k. Mac OS X 10.2.6, Powerbook G4/550. I consider this a release-blocker.
Flags: blocking1.4? → blocking1.4+
Are you sure you're allowed to set this flag ?
Flags: blocking1.4+ → blocking1.4-
Flags: blocking1.4- → blocking1.4?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030529 Apple TiBook 1GHz, 10.2.6. Am having no problems doing bookmark searches with this RC2. However, when trying to close the search results window via the window widget, the program crashes (see TB288393H).
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Bug still preventing bookmark searches in rc3, downloaded this morning. Program crashes immediately upon hitting Find button. Darn.
I just reported this again as Bug # 212584. Sorry! Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030712
*** Bug 212584 has been marked as a duplicate of this bug. ***
Mac G4, OS 10.2.6, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030721 Exactly the same problem
*** Bug 213325 has been marked as a duplicate of this bug. ***
Blocks: 212552
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030721 Bug is gone. Search works fine using either the Search field in Bookmarks Mgr window or by using Cmd-F in Bookmarks window. Hooray!
I should add: This time I trashed all the Mozilla files I could find (but the bookmarks file) before installing 1.5a.
Bug still here for me with new 1.5b nightlies (both 7/16 and 7/28). Am running highly customized preferences; do not want to re-create my profile if not absolutely needed.
Still crashes for me
Any idea when this will be rectified? The last time searching bookmarks worked for me was on v1.3
Requesting blocking for 1.5b, this is a highly visible and annoying crash.
Flags: blocking1.5b?
I'm not able to reproduce a crash or a hang when testing with my 1.4-created profile or clean profile created with today's build.
only two talkback reports on this in the database... has avoidance kicked in??? 1 nsFixedSizeAllocator::FindBucket 2 Source File : /builds/nightly/seamonkey/trunk/mozilla/xpcom/ds/nsFixedSizeAllocator.cpp line : 96 ==================================================================================================== Count Offset Real Signature [ 1 nsFixedSizeAllocator::FindBucket() d6ce799c - nsFixedSizeAllocator::FindBucket() ] Crash date range: 2003-08-16 to 2003-08-16 Min/Max Seconds since last crash: 100000 - 100000 Min/Max Runtime: 100000 - 100000 Count Platform List 1 Darwin 6.6 Count Build Id List 1 2003081203 No of Unique Users 1 Stack trace(Frame) nsFixedSizeAllocator::FindBucket() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/ds/nsFixedSizeAllocator.cpp line 96] ==================================================================================================== Count Offset Real Signature [ 1 nsFixedSizeAllocator::FindBucket() 1b42e314 - nsFixedSizeAllocator::FindBucket() ] Crash date range: 2003-08-14 to 2003-08-14 Min/Max Seconds since last crash: 33 - 33 Min/Max Runtime: 260 - 260 Count Platform List 1 Darwin 6.6 Count Build Id List 1 2003081403 No of Unique Users 1 Stack trace(Frame) nsFixedSizeAllocator::FindBucket() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/ds/nsFixedSizeAllocator.cpp line 96] nsFixedSizeAllocator::Alloc() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/ds/nsFixedSizeAllocator.cpp line 115] TestNode::Propagate() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/nsRuleNetwork.cpp line 1046] TestNode::Propagate() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/nsRuleNetwork.h line 904] RootNode::Propagate() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/nsRuleNetwork.h line 904] nsXULTreeBuilder::OpenSubtreeOf(nsTreeRows::Subtree* () [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/nsXULTreeBuilder.cpp line 1609] nsXULTreeBuilder::OpenContainer() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsCOMPtr.h line 649] nsXULTreeBuilder::RebuildAll() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsCOMPtr.h line 649] nsXULTemplateBuilder::Rebuild() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsVoidArray.h line 61] nsXULTemplateBuilder::AttributeChanged() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/templates/src/nsXULTemplateBuilder.cpp line 325] nsXULDocument::AttributeChanged() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/document/src/nsXULDocument.cpp line 1151] nsXULElement::SetAttr() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/content/src/nsXULElement.cpp line 2502] nsXULElement::SetAttribute() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/content/src/nsXULElement.h line 121] _XPTC_InvokeByIndex() XPCWrappedNative::CallMethod(XPCCallContext& XPCWrappedNative::CallMode)() [/builds/nightly/seamonkey/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2016] XPC_WN_CallMethod() [/builds/nightly/seamonkey/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1269] _js_Invoke() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 843] _js_Interpret() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 2859] _js_Invoke() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 860] _js_InternalInvoke() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 936] _JS_CallFunctionValue() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsapi.c line 3538] nsJSContext::CallEventHandler() [/builds/nightly/seamonkey/trunk/mozilla/dom/src/base/nsJSEnvironment.cpp line 1218] nsJSEventListener::HandleEvent() [/builds/nightly/seamonkey/trunk/mozilla/dom/src/events/nsJSEventListener.cpp line 183] nsEventListenerManager::HandleEventSubType() [/builds/nightly/seamonkey/trunk/mozilla/content/events/src/../../../dist/include/xpcom/nsCOMPtr.h line 667] nsEventListenerManager::HandleEvent() [/builds/nightly/seamonkey/trunk/mozilla/content/events/src/nsEventListenerManager.cpp line 2193] nsXULElement::HandleDOMEvent() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/content/src/nsXULElement.cpp line 3245] nsXULElement::DoCommand() [/builds/nightly/seamonkey/trunk/mozilla/content/xul/content/src/nsXULElement.cpp line 4264] _XPTC_InvokeByIndex() XPCWrappedNative::CallMethod(XPCCallContext& XPCWrappedNative::CallMode)() [/builds/nightly/seamonkey/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2016] XPC_WN_CallMethod() [/builds/nightly/seamonkey/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1269] _js_Invoke() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 843] _js_Interpret() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 2859] _js_Invoke() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 860] _js_InternalInvoke() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsinterp.c line 936] _JS_CallFunctionValue() [/builds/nightly/seamonkey/trunk/mozilla/js/src/jsapi.c line 3538] nsJSContext::CallEventHandler() [/builds/nightly/seamonkey/trunk/mozilla/dom/src/base/nsJSEnvironment.cpp line 1218] GlobalWindowImpl::RunTimeout() [/builds/nightly/seamonkey/trunk/mozilla/dom/src/base/nsGlobalWindow.cpp line 5035] GlobalWindowImpl::TimerCallback() [/builds/nightly/seamonkey/trunk/mozilla/dom/src/base/nsGlobalWindow.cpp line 5393] nsTimerImpl::Fire() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/threads/nsTimerImpl.cpp line 383] handleTimerEvent() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/threads/nsTimerImpl.cpp line 450] _PL_HandleEvent() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/threads/plevent.c line 672] _PL_ProcessPendingEvents() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/threads/plevent.c line 606] operator %() [/builds/nightly/seamonkey/trunk/mozilla/xpcom/threads/plevent.c line 1590] _DispatchEventToHandlers() _SendEventToEventTargetInternal() _SendEventToEventTargetWithOptions() ToolboxEventDispatcherHandler() _DispatchEventToHandlers() _SendEventToEventTargetInternal() _SendEventToEventTarget() ToolboxEventDispatcher() _CallEventDispatchHook() _TryEventDispatcher() _GetOrPeekEvent() _GetNextEventMatchingMask() _WNEInternal() _WaitNextEvent() nsMacMessagePump::GetEvent() [/builds/nightly/seamonkey/trunk/mozilla/widget/src/mac/nsMacMessagePump.cpp line 407] nsMacMessagePump::DoMessagePump() [/builds/nightly/seamonkey/trunk/mozilla/widget/src/mac/nsMacMessagePump.cpp line 312] nsAppShell::Run() [/builds/nightly/seamonkey/trunk/mozilla/widget/src/mac/nsAppShell.cpp line 114] main1() [/builds/nightly/seamonkey/trunk/mozilla/xpfe/bootstrap/../../dist/include/xpcom/nsCOMPtr.h line 667] _main() [/builds/nightly/seamonkey/trunk/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1672] _start() [/SourceCache/Csu/Csu-45//SourceCache/Csu/Csu-45/crt.c line 267] start() (22748983) Comments: Searching bookmarks
Problems persists. On rare occasions it will work OK for one or two searches, but soon breaks down again
Flags: blocking1.5b? → blocking1.5b-
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 This bug is *still* alive and well in my newly downloaded 1.5b release. I created a new profile for 1.5b, but that was no help. Whether "Find as you type" is on or off makes no difference either. Considering how long this bug has been active, I'm wondering just how unimportant getting this fixed must be to the Mozilla Org.
*** Bug 214984 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030916 1GHz TiBook, OS 10.2.6 Bug is gone in 1.5rc1...on first day anyhow.
Problem still there for me. Tried nightly of 11 Sep 03 and 1.5rc1 too. I generated two new talkback reports this AM. Searching in the search bar--type three characters. Moz pauses, then spinning pizza wheel, then crash.
Here, fast typing in the search field (even just 2 letters) invariably causes the crash. Ridiculously slow typing (1 second between letters) does not. Weird. I have 1024K RAM in this 1GHz machine. Peter, did you create a brand-new profile for it before first trying 1.5rc1?
I had not at last comment. I created a new profile this AM: bug gone. I went back to my original profile and tried the "slow typing" idea -- it worked for two characters, then gave pizza-wheel (and 80-90% CPU load); had to force quit. Next attempt crashed hard after typing one character. BUT BUG NOW RESOLVED FOR ORIGINAL PROFILE! My solution (possible instigator for bug?): I had deleted the Personal Toolbar Folder from my bookmarks several months ago. After experiencing Bug 88711 trying to put it back, and noticing that the new profile created (naturally enough) a new PTF, I did a manual edit of my old bookmarks file, and added in the HTML for the PTF from the new profile. Worked fine: now my original profile has a PTF again. Have tested/customized the PTF. And searching bookmarks now works as expected in my original profile.
Following on from Peter Edman observation, I also edited the "~/Library/Mozilla/Profiles/default/qmr4wmuz.slt/bookmarks.html" using BBEdit. Your's may be a slightly different location but a search for bookmarks.html should fing this file. The original file started & ended like this: <H1>Bookmarks</H1> <DL><p> <DT><H3 LAST_MODIFIED="1063920422" PERSONAL_TOOLBAR_FOLDER="true" ID="NC:PersonalToolbarFolder">Personal Toolbar Folder</H3> <DL><p> ....... whole of bookmarks </DL><p> I added a <HR> so that it read like this: <H1>Bookmarks</H1> <DL><p> <DT><H3 LAST_MODIFIED="1063920422" PERSONAL_TOOLBAR_FOLDER="true" ID="NC:PersonalToolbarFolder">Personal Toolbar Folder</H3> <DL><p> <HR> ....... whole of bookmarks <HR> </DL><p> It now appears to be stable & working well
I have never deleted my Personal Toolbar Folder, and 1.5rc1 still crashes when I try to search bookmarks. Editing the bookmarks.html file as described above didn't help, either.
So David, are you saying that "slow typing" is no longer necessary for searches to work properly, after applying your <HR> fix? In my own case, I have always used a duplicate of the original bookmarks.html file. I have never deleted my PTF either. Reading my bookmarks.html file in Tex-Edit Plus, mine lacks the <HR>'s where specified, yet my searches work, albeit only using "slow typing." It starts like this: <H1>Bookmarks</H1> <DL><p> <DT><H3 ADD_DATE="1011545955" LAST_MODIFIED="1058657864" PERSONAL_TOOLBAR_FOLDER="true" ID="NC:PersonalToolbarFolder">Personal Toolbar Folder</H3> <DL><p> Should I delete the ADD_DATE="1011545955" too? I sure would like to dispense with the slow typing.
The <HR> fix worked for me, but another method is to make another Profile that has it's own bookmark.html - give that a test using the search & you should find that it works OK, then quit Mozilla. Open the 2nd bookmark.html with BBEdit & edit that, copying details across from the 1st (faulty) bookmark. Try with just a few addresses copied, save 2nd bookmark, re-open Mozilla using 2nd Profile & test bookmark search. Assuming that it works OK, then continue using BBEdit to edit & copy all the old addresses across to 2nd bookmark.html. It can be a fiddly process with a large amount of addresses - I kept stopping & checking. Once you are satisfied that this 2nd Profile bookmark has all your old addresses, you may then copy this 2nd bookmark.html across to the folder that holds your original 1st (faulty) bookmark.html & replace that faulty file. It is best to make a copy of the 1st (faulty) bookmark.html - just in case you have omitted some addresses in the editing, so that you can come back to it later if required. You should then be able to open Mozilla using your original default Profile that holds all your personal preferences, passwords etc.
David, just adding the 2 <HR>'s fixed it for me too, using the "Taco HTML Edit" freeware program I found this afternoon. Now I can type search words as fast as I can and Mozilla just keeps on running. Amazing. You've done it, I believe, though I'm way too html-illiterate to have a clue as to how/why it should work now, much less what that has to do with "nsFixedSizeAllocator::FindBucket".
And, the <HR> fix has also solves this problem in Firebird 0.6.1.
It appears I've spoken too soon. My original profile is back to crashing again -- one-character's worth of searching is sufficient. I tried the HR tag additions, too, and they made no difference. Pity -- it worked for two days and I was getting used to having that function again. I didn't make any major changes to the bookmarks--just added a few more.
FWIW, I discovered that the HR tags have to be in exactly the right place--on the left margin--in order for David's fix to work. Oddly enough, after I Option-dragged the modified file onto my desktop to create a duplicate for Firebird which immediately crashed while trying to search, I found that Firebird's bookmarks.html file was not an exact duplicate after all. Both HR tags were there but indented. After fixing them, all was well again.
Peter try my 2nd method - that should be stable. I've got just under 500 addresses in my bookmark file & (touch wood!) it been working well for the last few days
Tried moving the HR to the left margin; worked for two characters, crashed on 3. Plus, it seems that Mozilla adds the whitespace back in once you open the bookmarks manager window, so keeping the HR in the left column looks difficult at best. Will try David's second method, but not soon -- I seem to have 2223 bookmarks (oy) and the transfer would not be a quick or happy process.
Re: "I seem to have 2223 bookmarks (oy) and the transfer would not be a quick or happy process" -- I still suspect that some anomaly in the html document is causing the problem. Have you looked through it to see if any lines are damaged? For example, I found that problem in Netscape 4.x which for a time refused to show me any bookmarks until I eliminated quite a number of absolutely blank lines which had somehow crept into the html document. Before looking, I had naively assumed that the 500KB size of it was the probable suspect. Today I checked my own files and can confirm your report of <HR>'s relocation. Nevertheless, both my 700KB bookmarks files remain easily searchable by their respective browser bookmarks managers. Still puzzled days later and having more bookmarks than ever, I obviously don't know enough about these matters to offer more useful info for the time being. I will, however, probably pipe up if/when this most inconvenient BUG crops up again for me.
A point of interest - I found that if one created a new Profile that had a successful bookmark search & then, without quiting, changed over to the the 1st faulty Profile - that bookmark search was then also successful (it might be a temporary option until you get he time the edit the whole file?) But if you then quit & restarted directly back into the 1st faulty Profile - the crash then re-occured. Somehow the introduction of a successful search then became the default even though you were working with a faulty file. I can't figure that out? FYI - my bookmark search is still functioning OK
9/24/03 The bookmarks.html file disappears (I've watched it vanish) even though Mozilla still shows bookmarks in the browser. They are kept in the Users' Library/Mozilla/Profiles/yourname/gh2nc9qj.slt Or in System 9, in the Preferences folder of the System Folder(I think). On first launch of the Sept 16th build, 1.5c the bookmarks were kept from the previous build but after a crash they've not worked right since. I can't tell what makes the file disappear. A default empty file will appear if you Manage Bookmarks. Work-around - every time I change my bookmarks, I export them so I can import them next time I launch. I also have to designate the Personal Toolbar folder (Manage bookmarks, Tools->"Import", followed by highlight the Personal Toolbar Folder and View-->"Set as Personal Toolbar Folder") I use an eMac, sys 10.1.5 Polly pbrown5931@cox.net
Polly, How does what you're describing relate to this bug? I'm puzzled. Thx.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 Downloaded/installed 1.5rc2 and started using it without creating new profile. After a day's use, tried bookmark search, typing fast. Mozilla crashed. Restarted Mozilla, tried bookmark search several times, waiting 2 seconds after first letter, then typing other letters normally. Crashed about half the time. Later, opened bookmarks.html in html editor, found David's added HR tag still there at start of list but missing at end. I added it where directed. Restarted Mozilla, tried search, typing normally. No crash. Restarting Mozilla several times and searching, still no crashes. When entering letters, the caret should blink normally after each letter is typed. However, after the first letter there is a significant delay before the caret returns. During that delay, the entire bookmarks file is searched and, by the end of the delay, the display has changed. It seems to me that something like not enough memory is allocated to allow a prompt search of my 700+KB file if D's HR tags are missing and so Mozilla crashes. I realize my interpretation is totally uneducated, yet it seems we all are in the dark as to what's what here.
A lingering question: How does simply updating Mozilla affect its bookmarks.html file so that either of these previously added HR tags is deleted?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 Mac TiBook 1GHz Same old problem. The <HR> tag at the end of the bookmarks list gets deleted early on somehow, and after that the app crashes every time I try a search with Bookmarks Mgr - until I finally add the tag again using an html editor.
This has been bothering me for ages and I think I've found a solution. For some strange and improbable reason, the Bookmark Manager does not like it if it doesn't have the folder "IMPORTED IE FAVORITES", included in default bookmarks when you set up a new profile. To get around this, simply add this text before the last line (which should be <DL><p>) of your Bookmarks.html file: <DT><H3 ID="NC:SystemBookmarksStaticRoot">Imported IE Favorites</H3> Worked for me and should be straightforward to fix permanently. Don't know why it works, I just used trial and error.
Panther update may resolve symptoms. Bookmark searching WFM now on OS X 10.3, TiBook 550, nightly 2003102905. Had been regularly crashing on Jaguar 10.2.8; some of the assorted suggestions from commenters fixed it temporarily but always reverted to crashing. Today I tested a few relatively complicated searches and it seemed solid.
Ian's new idea works for me too using the 1.6a 20031029 version running in a 10.2.8 G4 TiBook for a few days. Also, I didn't add in those two <HR> tags. Then I tried using a dupe in Firebird and it corrected the identical problem there too. Maybe this time it'll last. I don't want to upgrade to 10.3 just yet.
Roger, don't update to 10.3 to solve this issue. It hasn't solved it for me. Mozilla still crashes on search if you take out the fix. BTW, the text "Imported IE Favorites" isn't crucial. You can edit this if it annoys you. It's the "NC:System..." part that counts.
Ian, upgrading to 10.3 is not planned right now. I'll wait at least till Apple comes out with the next 10.3.x rev. This search problem has been with us for so long, I want to enjoy the benefits of your fix for a while. So far, so good! Anyway, Panther's Finder doesn't interest me much. I've tried the Pfinder and Path Finder programs just to see what the differences would be like, and once again I see change just for the sake of change to be a foolish move for me. I hear Panther is generally faster than Jag, but the complaints I've been reading overwhelm any yearnings I might have to stay right on the cutting edge and probably risk more mysterious glitches as a result. No way, after all this searching bookmarks nonsense. Right now everything I want to use finally actually works!
*** Bug 225822 has been marked as a duplicate of this bug. ***
Ben, pch, can one of you look into this? It seems like comment #52 may have isolated the problem.
Flags: blocking1.6b?
This is the crash log to go along with the Incident report TB259709W Sent 22 Nov 2003 at 09:32 PM by trscons@bellatlantic.net The bookmark file is very large... 11k+ entries. This one problem is nagging us for multiple versions for months... :-( Hope this helps.
Thomas, have you tried Ian's fix? See comment #52. As of today, this bug is still absent in both Mozilla and Firebird, due to Ian's fix.
Flags: blocking1.6b? → blocking1.6b+
Darn, the bug's back. Ian's fix got deleted. Still using Build 2003102905.
Assignee: varga → bugs
I am unable to reproduce this bug with either OS X 10.1.5 or 10.2.8 using the latest trunk SeaMonkey builds. It seems that some release or nightly build (or something else) has corrupted some peoples' bookmarks.html files and only those people are seeing the crash. If this isn't a common problem and can't be reproduced with profiles created in the last few major releases, I don't think it's a blocker. I've tested profiles created with 1.3, 1.4 and 1.5 and cannot reproduce this crasher. Can anyone who was seeing this please create a new profile and test this with a currently nightly build? (To create a new profile from the Tools menu, select "Switch Profile..." and then click the "Manage Profiles..." button and from there click "Create Profile...") If someone can reproduce this in a new profile or can point me to the release that caused the corruption (if it was some particular bad release) then please renominate this bug for fixing in 1.6. Thanks.
Flags: blocking1.6b+ → blocking1.6b-
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20031029 MacOS 10.2.6 A few days ago I downloaded and installed a fresh copy of 1.6.a, setting up a new profile for it. The bookmarks mgr list now includes a folder named "Imported IE Favorites" although it's empty. This bug is not present as of today as I search for bookmarks again and again. I've been here before of course, and haven't much confidence that without "Imported IE Favorites" Mozilla bookmark searches will remain functional. Asa seems to think none of us have ever followed the instructions he describes. I'm done with this for now.
Asa, please see my comment #52 for an explanation of the problem. The crash does not happen in any version of Mozilla if the original bookmark profile is left untouched or is only appended to. I believe it only happens if "Imported IE Favorites" folder is deleted in Manage Bookmarks OR the bookmark.html file is replaced by user and new file doesn't contain "Imported IE.." folder. I have 10.3.1 and 10.1.5 so I will outline the current situation when a search is performed AND "Imported IE.." doesn't exist. OS 10.3.1 - Mozilla 1.4.1 crashes Mozilla 1.6a crashes Firebird 0.7.1 crashes Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031203 ) works! OS 10.1.5 - All the above crash To replicate: Start with new profile, delete "Imported IE..." bookmarks folder, restart Mozilla/Firebird, do search. In summary, this has been fixed for 10.3.1 but not for 10.1.5 ( could someone else should try it for 10.2.x?)
Reproduced steps in comment 52 using Mozilla rv1.4.1 on OS X 10.2.8, crashing at nsRDFConMemberTestNode::FilterInstantiations (a new crash point, it appears).
Er, make that "reproduced steps in comment 64."
Also reproduced using Mac/2003-12-05-05-trunk, but this time crashing at JS_HashTableRawLookup. I see no similarity between this stack and the one generated using rv1.4.1.
Renominating blocking1.6? per comment 62.
Flags: blocking1.6?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031206 Just tested 1.6b on a 10.31 partition and the bug is gone, or so it seems. Same for my 10.2.6 partition. New profile in each case. Bob F
Blocks: 227975
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031208 Works fine.
resolving worksforme per reporter's comments.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
unsetting the request for 1.6
Flags: blocking1.6?
I'm of the belief that unless someone fixes a long standing crash, it isn't going to go away on its own. FWIW there are definitely places near this code where unchecked allocs happen and can (and should) be handled ...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 211061 has been marked as a duplicate of this bug. ***
*** Bug 230604 has been marked as a duplicate of this bug. ***
*** Bug 233729 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 Mac OS 10.2.8 Comment #70 reports this bug absent in 1.6b under Mac OS 10.2.6, however I see a reproducible crash in 1.6 under Mac OS 10.2.8 at nsRDFConMemberTestNode::FilterInstantiations() when a bookmarks file with the "Imported IE Favourites" bookmark deleted is searched. Restoring the IE Favourites bookmark, as suggested in comment #52, works around the crash.
Okay, comment 78 is reproducible for me using Mozilla-Mac/2004-04-20-08-trunk and 1.7RC1, crashing at nsRDFConMemberTestNode::FilterInstantiations I don’t know if this is the same crash as originally reported or not, but flagging as blocking1.7? for attention. 1. Create a new profile 2. Command+b (Bookmarks/Manage Bookmarks...) 3. Select Imported IE Favorites folder 4. Click Delete 5. Command+f (Tools/Search Bookmarks...) 6. Type “gecko”, hit return. Search completes successfully; no crash 7. Quit Mozilla 8. Relaunch Mozilla 9. Repeat stepa 2–6. This time it should crash.
Flags: blocking1.7?
Summary: Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsFixedSizeAllocator::FindBucket] → Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations]
Attachment #124647 - Attachment is obsolete: true
Attachment #136146 - Attachment is obsolete: true
Attachment #136927 - Attachment is obsolete: true
Confirming for OS 10.3.3 using 1.7b. However, 1.6 works fine using 10.3.3. Seems that for some of us this was fixed but it is now broken for all of us again...
Am I correct that the cause of this bug is removing the imported IE favorites folder (which is created as a default in all profiles?) No one who didn't remove that folder is having this problem?
Re comment 82, yes, this is my understanding and is true in my case. The workaround in comment 52 resolved crashes on my system.
Flags: blocking1.7? → blocking1.7+
Asa, deleting the "Imported IE Favourites" (IIEF) bookmark appears to be a necessary, but insufficient, condition for obtaining this bug. I have more than one Mac and on some, deletion of the IIEF bookmark does not immediately cause this bug, but I've seen this bug appear later on some of these systems. On the other hand, I've never seen this bug when the IIEF bookmark is present and, on Macs from which it has been deleted, restoring the bookmark has resolved the bug. BTW, I've seen this bug, on and off, since Mozilla 1.4.
Flags: blocking1.7+ → blocking1.7?
Crash still occuring in 1.8a 20040505. Mac OS X 10.3.3. Imported IE favorites present.
I saw this bug afresh this week when I imported the Bookmarks file from my wife's old Linux 1.6 install to her new Mac OS X 1.7RC1 install (old Powerbook G3 Bronze running 10.3.3). I just physically copied the bookmarks file into her new profile directory, and the Linux bookmarks had not of course included the IE Favorites. I was able to workaround again with the fix in comment 52 -- it's my understanding that the critical fix is the ID tag in the <H3 ID="NC:SystemBookmarksStaticRoot"> part of the code, not any text in the bookmark/folder name itself. Is that tag present in the bookmarks file referenced in Comment 85?
Adding M17rc2 to summary and topcrash keyword since this is showing up as a topcrasher for early MacOS X Talkback data for Mozilla 1.7 rc2: Rank StackSignature Count 3 nsRDFConMemberTestNode::FilterInstantiations 3 Source File : /builds/release/1.7/mozilla/content/xul/templates/src/nsRDFConMemberTestNode.cpp line : 107 ==================================================================================================== Count Offset Real Signature [ 3 nsRDFConMemberTestNode::FilterInstantiations() 8de09459 - nsRDFConMemberTestNode::FilterInstantiations() ] Crash date range: 17-MAY-04 to 19-MAY-04 Min/Max Seconds since last crash: 62 - 19408 Min/Max Runtime: 62 - 19470 Count Platform List 3 [Darwin 7.3.0] Count Build Id List 3 2004051405 No of Unique Users 2 Stack trace(Frame) nsRDFConMemberTestNode::FilterInstantiations() [/builds/release/1.7/mozilla/content/xul/templates/src/nsRDFConMemberTestNode.cpp line 107] (50511) Comments: searching bookmarks (50333) Comments: searching bookmarks
Keywords: topcrash
Summary: Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations] → M17rc2 - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations]
Flags: blocking1.7?
Flags: blocking1.7+
Flags: blocking1.6b-
Flags: blocking1.5b-
doesn't look like we are far enough along in the investigation of this for a safe fix for 1.7. renominate if someone makes a breakthough in the next few days. looks like the best chance at reproducing and debugging this might be on Mac
Flags: blocking1.8a2?
Flags: blocking1.7-
Flags: blocking1.7+
Flags: blocking1.7.1?
This appears to be a crash in Firefox as well: Incident ID: 172972 Stack Signature nsRDFConMemberTestNode::FilterInstantiations() c90c8ebc Email Address Product ID Firefox10 Build ID 2004061423 Trigger Time 2004-06-25 15:22:45.0 Platform MacOSX Operating System Darwin 6.8 Module firefox-bin + (003a229c) URL visited User Comments I had just typed in a search in the search box. The search had a typo in it so it said "hand-dyed sikl" or "hand-dyed slik". pressed search. app crashed Since Last Crash 2362 sec Total Uptime 2362 sec Trigger Reason SIGBUS: Bus Error: (signal 10) Source File, Line No. /builds/tinderbox/firefox-1.0/Darwin_6.8_Clobber/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsCOMPtr.h, line 710 Stack Trace nsRDFConMemberTestNode::FilterInstantiations() [/builds/tinderbox/firefox-1.0/Darwin_6.8_Clobber/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsCOMPtr.h, line 710] nsRDFConMemberTestNode::FilterInstantiations() [/builds/tinderbox/firefox-1.0/Darwin_6.8_Clobber/mozilla/content/xul/templates/src/nsResourceSet.h, line 86] TestNode::Propagate() [/builds/tinderbox/firefox-1.0/Darwin_6.8_Clobber/mozilla/content/xul/templates/src/nsRuleNetwork.h, line 904] RootNode::Propagate() [/builds/tinderbox/firefox-1.0/Darwin_6.8_Clobber/mozilla/content/xul/templates/src/nsRuleNetwork.h, line 904] nsXULTreeBuilder::OpenSubtreeOf(nsTreeRows::Subtree*,() [/builds/tinderbox/firefox-1.0/Darwin_6.8_Clobber/mozilla/content/xul/templates/src/nsXULTreeBuilder.cpp, line 1610] . . . Stack is huge!
Summary: M17rc2 - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations] → M17 FF09 - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@nsFixedSizeAllocator::FindBucket]
This would be really nice to get for 1.8 and the 1.7 branch. Who can help?
Flags: blocking1.8a2? → blocking1.8a2+
I can confirm this with both Mozilla 1.7 and Firefox 0.9.1, OSX only. It does not occur on win32 on linux. It seems that any bookmarks.html that does not have a NC:SystemBookmarksStaticRoot causes the crash upon searching (this is the ID that the Imported IE Favorites folder gets). Either deleting the folder within the browser or removing it by hand from bookmarks.html causes the issue. This ID seems to be only used on the mac (nsBookmarksService::HandleSystemBookmarks and ImportSystemBookmarks). I can't do a debug build on OSX atm but I'll see if I can track it down this weekend. This might be a blocker for ffox 1.0 mac (no aviary-1.0mac flag?).
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0mac+
Flags: blocking1.8a3?
*** Bug 249517 has been marked as a duplicate of this bug. ***
So, I'd love to work on a fix for this, but I can't get a working debug build of firefox on OSX. It builds, and the window comes up, but I can't interact with it, and it doesn't show up as an application when I Command-tab through open apps. I can't focus the window. OSX 10.3.4, gcc 3.3 20030304. Default options, --enable-default-toolkit=mac --enable-debug. If anyone has any ideas, please toss me an email.
I've experienced this bug since I frist switched to Moz from IE (date on my first bookmark.html file: 2/20/2003). This workaround < a href="http://bugzilla.mozilla.org/show_bug.cgi?id=207636#c52"> #52</a> fixed it immediately. Seems I did originally import the IE favorites, but immediately moved the files into the Moz bookmark tree. Mozilla 1.7 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 TiG4 667/512mb, Mac OS X: 10.2.8.
We know what's causing this from a few of the comments in this bug and also have a workaround, but we really need a permanent fix for this topcrasher. Marking this topcrash+. Ben: this is already marked + for blocking-aviary1.0mac, so i'm guessing there is no need to + it for blocking-aviary1.0PR, right?
Keywords: topcrash → topcrash+
See comment #93 -- I still can't get a build on OSX working. If someone who can wants to tackle this, all theirs.
Flags: blocking1.8a3? → blocking1.8a3-
Flags: blocking1.8a2+
This serious bug is still present in 1.0Pre on Mac OS X as of 2004-09-14. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10
This is a topcrasher for Firefox 1.0 PR1 on MacOS X. All the crashes for that platform are showing up under the "firefox-bin" stack signature. Still investigating other platforms.
Summary: M17 FF09 - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@nsFixedSizeAllocator::FindBucket] → FF10PR1 M17 - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@nsFixedSizeAllocator::FindBucket][@ firefox-bin]
*** Bug 266821 has been marked as a duplicate of this bug. ***
Still around in Firefox 1.0 RC1 and RC2: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsRDFConMemberTestNode%3A%3AFilterInstantiations&vendor=All&product=Firefox10&platform=MacOSX&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
Summary: FF10PR1 M17 - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@nsFixedSizeAllocator::FindBucket][@ firefox-bin] → FF10RC2 M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin]
So this old bug of mine is still around. Amazing. Who's minding the store, as it were? I just tried some searches from Bookmark Manager using Firefox 1.0RC1 and didn't have any problems. In fact I haven't run into anything like this bug since I quit using Mozilla and switched to Firefox earlier this year. Mac 10.3.5 right now.
*** Bug 212552 has been marked as a duplicate of this bug. ***
*** Bug 268973 has been marked as a duplicate of this bug. ***
*** Bug 270244 has been marked as a duplicate of this bug. ***
moving blocking-aviary1.0mac+ bugs to Firefox1.1 and Mozilla 1.8a6 Target Milestones.
Target Milestone: --- → mozilla1.8alpha6
Product: Browser → Seamonkey
Flags: blocking1.7.5? → blocking1.7.5-
*** Bug 274523 has been marked as a duplicate of this bug. ***
Summary: FF10RC2 M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin] → FF10x M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin]
Adding helpwnated keyword. This is a topcrasher for Firefox 1.0 on MacOSX: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsRDFConMemberTestNode%3A%3AFilterInstantiations&vendor=All&product=Firefox10&platform=All&buildid=20041107&sdate=&stime=&edate=&etime=&sortby=bbid
Keywords: helpwanted
Summary: FF10x M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin] → FF10 M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin]
Whiteboard: need testcase
Flags: blocking1.8a6?
Ben, can you take a look at this for us. It'd be good to get this in time for beta.
Flags: blocking1.8b+
Flags: blocking1.8a6?
Flags: blocking1.8a6-
*** Bug 263427 has been marked as a duplicate of this bug. ***
This looks like one of our worst Mac crasher bugs in 1.0. Ben, can will you be able to help here or recommend someone else who can?
Flags: blocking1.8b2+
Flags: blocking1.8b+
Flags: blocking1.8a6-
Flags: blocking1.8a3-
Flags: blocking1.7.5-
Flags: blocking1.7-
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0mac+
*** Bug 283857 has been marked as a duplicate of this bug. ***
This bug is back in my Firefox 1.0.1 for Mac.
*** Bug 277458 has been marked as a duplicate of this bug. ***
*** Bug 283764 has been marked as a duplicate of this bug. ***
Is there any correlation between whether the importing of IE favorites works and whether this bug shows up? I tried to test this (I deleted the imported IE favorites folder per comment 52), but I couldn't get it to crash. However, I noticed that I was seeing the NS_ENSURE_TRUE in nsBookmarksService::ImportSystemBookmarks triggered, indicating that NS_GetSpecialDirectory(NS_MAC_PREFS_DIR, ...) failed (which seems odd). So I'm wondering if the crash only happens for those people for whom it succeeds. I'm testing on 10.3.8.
Summary: FF10 M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin] → FF10 M17x - Search Bookmarks operation in Manage Bookmarks window crashes Mozilla if imported IE favorites were deleted [@ nsRDFConMemberTestNode::FilterInstantiations][@ nsFixedSizeAllocator::FindBucket][@ firefox-bin]
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 I just reproduced this bug in Mozilla 1.7.5, Talkback Incident ID TB4520886Q. I deleted the imported IE favorites bookmark and restarted Mozilla. Searching for a string that is not present in the bookmarks file wouldn't crash Mozilla, but searching for a string that would have some hits caused the crash.
I've just noticed that this crash will only occur if the first search performed after launch would return some hits. If the first search returns no results, subsequent searches that return hits (at least the two or three searches I tried) won't crash Mozilla.
Did not reproduce (!) on the following build: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1 I had previous problems with crashes while searching on Mac OSX. Appears to be working. I did not have any IE favorites before, now, during, or after. Tried two reproduction scenarios: Close Browser Open Browser Manage Bookmarks Search: "Bogus" ...no results... Search: "Something" ...results came back... Then: Close Browser Open Browser Manage Bookmarks Search: "Something" ...results came back... Search: "Bogus" ...no results... (simulating the comment #117 from jwq) In no case did it crash for me. (I've been experiencing other crashes, but not related to this particular scenario). Would like to RESOLVE as WORKSFORME, since I don't know who / what fixed it (any "sufficiently empowered users" lying around?). If anyone on the CC list is still experiencing it on latest builds, please report or reopen. Thanks! --Robert
(In reply to comment #118) Nope, it's not fixed. It still crashes for me in 20050428
Bug 288645 seems to be a duplicate of this one, and it has a workaround involving editing the Bookmarks.html file.
(In reply to comment #120) > Bug 288645 seems to be a duplicate of this one, and it has a workaround > involving editing the Bookmarks.html file. I agree that Bug 288645 looks like a duplicate. For what it's worth, the workaround described there suggests changing the Toolbar folder ID attribute from "rdf:#$foobaz" to "NC:SystemBookmarksStaticRoot". In my bookmarks.html, the attribute in question was "NC:PersonalToolbarFolder", but the workaround fixed the crash-on-search behavior for me.
still crashing for me. latest talkback: TB6565714E OSX firefox 1.0.3 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
No solution here but at least I've found a workaround which allows successful searching, at least in Firefox for Mac. There's a Firefox extension named "Enhanced Bookmark Search" which allows me to search successfully if I use it. The current version of EBS is 0.1.3.01. Perhaps someone assigned to this bug should contact the EBS extension's owner. My posting about this bug at Mozillazine forums led to a reply from him and, so far, months of relief from 207636. I'm using the stock 1.0.4 FF release in a fresh profile in Mac OS 10.3.9 on a 2004 G4 Powerbook. An "Imported IE Favorites" folder is present to no effect. Searching without using EBS still results in a crash every time. My bookmarks file is 720KB.
Same problem here! Talk-Back incident: TB9504271Z Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050918 SeaMonkey/1.1a
(In reply to comment #124) > Same problem here! > > Talk-Back incident: TB9504271Z > > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050918 > SeaMonkey/1.1a And it also happens when using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 SeaMonkey/1.0a
(In reply to comment #125) > (In reply to comment #124) > > Same problem here! > > > > Talk-Back incident: TB9504271Z > > > > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050918 > > SeaMonkey/1.1a > > ...and again in Mozilla 1.7.12 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050918 > And it also happens when using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; > en-US; rv:1.8b4) Gecko/20050914 SeaMonkey/1.0a
*** Bug 314360 has been marked as a duplicate of this bug. ***
This bug is still present in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.9a1) Gecko/20060103 SeaMonkey/1.5a. Anybody working on this?
WFM. Mac OS X 10.3.9 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060103 SeaMonkey/1.5a
*** Bug 227975 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 I can reproduce this crash in a fresh profile with Mozilla 1.7.13. Talkback ID TB20803990Z (see below). Steps to reproduce: 1. Create a new profile and start Mozilla with this profile 2. Open bookmark manager and delete the "Imported IE Favorites item" 3. Quit and restart Mozilla 4. Open bookmark manager 5. Cmd-F (search) and enter "zine" in the search field 6. Execute search Actual Result: crash. From Talkback report TB20803990Z: Stack Signature PL_ArenaAllocate() 1aa40301 Product ID Mozilla17 Build ID 2006041423 Trigger Time 2006-07-10 16:49:54.0 Platform MacOSX Operating System Darwin 7.9.0 Module libplds4.dylib.1.0.0 + (000014ac) URL visited User Comments Reproducing Bug 207636 Since Last Crash 599716 sec Total Uptime 599716 sec Trigger Reason SIGBUS: Bus Error: (signal 10) Source File, Line No. /builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/nsprpub/lib/ds/plarena.c, line 173 Stack Trace PL_ArenaAllocate() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/nsprpub/lib/ds/plarena.c, line 173] PL_ArenaAllocate() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/nsprpub/lib/ds/plarena.c, line 158] nsFixedSizeAllocator::Alloc() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/xpcom/ds/nsFixedSizeAllocator.cpp, line 118] nsRDFConMemberTestNode::FilterInstantiations() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/nsRDFConMemberTestNode.h, line 102] TestNode::Propagate() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/nsRuleNetwork.cpp, line 1046] TestNode::Propagate() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/nsRuleNetwork.h, line 904] RootNode::Propagate() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/nsRuleNetwork.h, line 904] nsXULTreeBuilder::OpenSubtreeOf(nsTreeRows::Subtree*,() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/nsXULTreeBuilder.cpp, line 1610] nsXULTreeBuilder::OpenContainer() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsCOMPtr.h, line 692] nsXULTreeBuilder::RebuildAll() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsCOMPtr.h, line 692] nsXULTemplateBuilder::Rebuild() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/templates/src/../../../../dist/include/xpcom/nsVoidArray.h, line 61] nsXULDocument::AttributeChanged() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1140] nsXULElement::SetAttrAndNotify() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2193] nsXULElement::SetAttr() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2153] nsXULElement::SetAttribute() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 1028] _XPTC_InvokeByIndex() XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2033] XPC_WN_CallMethod() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1781] js_Invoke() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/js/src/jsinterp.c, line 957] js_Interpret() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/js/src/jsinterp.c, line 3024] js_Invoke() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/js/src/jsinterp.c, line 974] js_InternalInvoke() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/js/src/jsinterp.c, line 1052] JS_CallFunctionValue() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/js/src/jsapi.c, line 3703] nsJSContext::CallEventHandler() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1299] nsJSEventListener::HandleEvent() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/dom/src/events/nsJSEventListener.cpp, line 177] nsEventListenerManager::HandleEventSubType() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/events/src/../../../dist/include/xpcom/nsCOMPtr.h, line 710] nsEventListenerManager::HandleEvent() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1534] GlobalWindowImpl::HandleDOMEvent() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 986] DocumentViewerImpl::LoadComplete() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/content/base/src/../../../dist/include/xpcom/nsCOMPtr.h, line 704] nsDocShell::EndPageLoad() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/docshell/base/nsDocShell.cpp, line 4559] nsWebShell::EndPageLoad() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/docshell/base/../../dist/include/xpcom/nsCOMPtr.h, line 533] nsDocShell::OnStateChange() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/docshell/base/../../dist/include/necko/nsNetUtil.h, line 197] nsDocLoaderImpl::FireOnStateChange() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/uriloader/base/../../dist/include/xpcom/nsCOMPtr.h, line 710] nsDocLoaderImpl::doStopDocumentLoad() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 868] nsDocLoaderImpl::DocLoaderIsEmpty() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 771] nsDocLoaderImpl::OnStopRequest() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 698] nsLoadGroup::RemoveRequest() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/netwerk/base/src/../../../dist/include/xpcom/nsCOMPtr.h, line 710] nsCachedChromeChannel::HandleStopLoadEvent() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/rdf/chrome/src/../../../dist/include/xpcom/nsCOMPtr.h, line 607] PL_HandleEvent() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/xpcom/threads/plevent.c, line 680] PL_ProcessPendingEvents() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/xpcom/threads/plevent.c, line 614] _md_EventReceiverProc() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/xpcom/threads/plevent.c, line 1590] DispatchEventToHandlers() SendEventToEventTargetInternal() SendEventToEventTargetWithOptions() ToolboxEventDispatcherHandler() DispatchEventToHandlers() SendEventToEventTargetInternal() SendEventToEventTarget() ToolboxEventDispatcher() TryEventDispatcher() GetOrPeekEvent() GetNextEventMatchingMask() WNEInternal() WaitNextEvent() nsMacMessagePump::GetEvent() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/widget/src/mac/nsMacMessagePump.cpp, line 407] nsMacMessagePump::DoMessagePump() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/widget/src/mac/nsMacMessagePump.cpp, line 312] nsAppShell::Run() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/widget/src/mac/nsAppShell.cpp, line 114] main1() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/xpfe/bootstrap/../../dist/include/xpcom/nsCOMPtr.h, line 710] main() [/builds/tinderbox/Mozilla1.7/Darwin_6.8_Depend/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1784] _start() start()
*** Bug 326028 has been marked as a duplicate of this bug. ***
(In reply to comment #131) > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) > Gecko/20060414 > > I can reproduce this crash in a fresh profile with Mozilla 1.7.13. Talkback ID > TB20803990Z (see below). > > Steps to reproduce: > 1. Create a new profile and start Mozilla with this profile > 2. Open bookmark manager and delete the "Imported IE Favorites item" > 3. Quit and restart Mozilla > 4. Open bookmark manager > 5. Cmd-F (search) and enter "zine" in the search field > 6. Execute search > > Actual Result: crash. > Did you apply the fix from message 52 (https://bugzilla.mozilla.org/show_bug.cgi?id=207636#c52)?
Removing need testcase from status whiteboard since jwq has found steps to reproduce this crash. Can anyone please test this on the latest Firefox releases (1.5.0.5 and 2.0 beta) to see if it's a problem there as well?
Whiteboard: need testcase
I can reproduce this crash in FireFox 1.0.4 and 1.0.8 with the above steps to reproduce [crash @ nsRDFConMemberTestNode::FilterInstantiations] but I can't reproduce it in FireFox 1.5, 1.5.0.4 or 1.5.0.5. I note that "Imported IE Favourites" is no longer part of the default profile created by 1.5.0.5 - has the FireFox search/filter code been changed?
This bug is also present in the latest SeaMonkey trunk builds. See bug Bug 326028 (now marked as duplicate of Bug 207636207636), especially comment 6 where I describe this independently from the comments in this bug. You do seem to need the Imported IE-Favorites folder in order to prevent the crash.
This bug is also present in the latest SeaMonkey trunk builds. See bug Bug 326028 (now marked as duplicate of Bug 207636), especially comment 6 where I describe this independently from the comments in this bug. You do seem to need the Imported IE-Favorites folder in order to prevent the crash.
*** Bug 288645 has been marked as a duplicate of this bug. ***
*** Bug 348206 has been marked as a duplicate of this bug. ***
Assignee: bugs → nobody
Status: REOPENED → NEW
QA Contact: chrispetersen → bookmarks
Target Milestone: mozilla1.8alpha6 → ---
This bug is present in SeaMonkey 1.0.5 (build of 24 September, 2006). I am afraid many of the comments below are beyond me, but I have the following additional observations: 1) By repeatedly installing a saved back-up of my bookmarks.html file and looking at the times that it was modified within my profile even though only searches and no actual modifications were carried out, I have come to the tentative conclusion that what happens is that as a result of using the Bookmarks Manager, making searches, etc., the SeaMonkey application itself sometimes (not every time) somehow becomes corrupted. This then corrupts the bookmarks.html file, so that then the crash happens every time. The only way to cure this behaviour is then to (a) download a new copy of SeaMonkey, (b) remove bookmarks.html from the profile, (c) insert the backup copy. Searches are then OK until the next time the whole thing happens. 2) At some stage before I started investigating this bug I discovered that I had two 'Imported from IE' folders, and I deleted one of them. Could this be relevant? 3) At a stage where SeaMonkey was crashing every time I tried a search, I opened a copy of Mozilla 1.7.13, and it, too, crashed when a search was attempted (using the same profile and bookmarks.html file). So the corrupted bookmarks file affected Mozilla, too. I am using an eMac G4 (PPC), OS X 10.4.7.
Re Comment #140: After writing this comment, I went back to SeaMonkey 1.0.5 and discovered that however many times I installed a fresh download of SM and inserted my unsullied backup copy of bookmarks.html, SM now crashed every time I searched in Bookmarks Manager. I cannot understand why things changed in this way. This suggested that the corruption in fact did not reside in the application after all. So I removed the entire Mozilla folder (containing my profile) from my Library, installed a fresh SM and imported my backup bookmarks file, being careful not to delete 'Imported from IE'. Now stability has been restored. This suggests that the corruption, however caused, resided in the profile, not the application.
Bug (crash on bm search / IE Favorites) is still there in SeaMonkey 1.0.6. I noticed that when I manually add a "Imported IE Favorites" bookmarks folder, to make it not crash on a search, the workaround apparently does not take effect until the next browser session. (After I added the folder, it crashed on the next search I performed. Neglected to verify whether the bookmarks.html file had yet been modified on the filesystem.) Sorry if this detail is well known, I didn't have time to make sure whether that had been explained in this long history. Thanks; Larry.
No longer blocks: 209542
can this be reproduced using latest SM trunk build? (no crashes in crash-stats for last 4 weeks)
still don't see this in crash-stats for SM 2.*, so => WFM
Status: NEW → RESOLVED
Closed: 22 years ago → 16 years ago
Resolution: --- → WORKSFORME
I think it would be safe to assume that this can be marked closed/resolved: -- Mac IE has been dead for a very long time, and the integration of IE bookmark storage into FF was the root cause -- a new implementation of how bookmarks are imported, saved, and stored in now in FF -- the PPC Mac user base continues to decrease -- and we have a manual workaround for those too hardcore/stubborn to migrate to newer browsers
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsRDFConMemberTestNode::FilterInstantiations] [@ nsFixedSizeAllocator::FindBucket] [@ firefox-bin]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: