330776 - crash when accessibility enabled and browsing with history sidebar open [@ nsXULTreeBuilder::HasGeneratedContent] [@ nsTreeRows::FindByResource]

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If I enable the GNOME systemwide accessibility preference (Desktop -> Preferences -> Accesibility -> Assistive Technology Support -> Enable Assistive Technologies) and log out of GNOME and log back in, I see frequent crashes when browsing using the history sidebar.  I don't have 100% reliable steps to reproduce, however, I've been able to reproduce pretty frequently when opening the history sidebar, loading something from it, and then middle-clicking links in that page to open them in a new tab, and potentially browsing around a little bit.

In a DEBUG build, the crash is pretty reliable because it's accessing freed memory which has been marked with 0xd8d8d8d8 by nsFixedSizeAllocator, dereferencing mResult (i.e., mResult is 0xd8d8d8d8) in the line:

            rv = iter->mMatch->mResult->GetResource(getter_AddRefs(findres));

in nsTreeRows::FindByResource.

If I stub out nsFixedSizeAllocator::Alloc and nsFixedSizeAllocator::Free to just call malloc and free instead of doing what they normally do, then I can get valgrind to tell me about what happened, and it says the following:

==7905== Invalid read of size 4
==7905==    at 0x5AA165C: nsCOMPtr<nsIXULTemplateResult>::operator->() const (nsCOMPtr.h:849)
==7905==    by 0x5AA12F0: nsTreeRows::FindByResource(nsIRDFResource*) (nsTreeRows.cpp:189)
==7905==    by 0x5AB3109: nsXULTreeBuilder::HasGeneratedContent(nsIRDFResource*, nsIAtom*, int*) (nsXULTreeBuilder.cpp:1092)
==7905==    by 0x5A9FA33: nsContentTestNode::Constrain(InstantiationSet&) (nsContentTestNode.cpp:110)
==7905==    by 0x5AA9223: TestNode::Constrain(InstantiationSet&) (nsRuleNetwork.cpp:403)
==7905==    by 0x5AC4682: nsXULTemplateQueryProcessorRDF::Propagate(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsXULTemplateQueryProcessorRDF.cpp:757)
==7905==    by 0x5AC665F: nsXULTemplateQueryProcessorRDF::OnAssert(nsIRDFDataSource*, nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsXULTemplateQueryProcessorRDF.cpp:573)
==7905==    by 0x5E50030: CompositeDataSourceImpl::OnAssert(nsIRDFDataSource*, nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsCompositeDataSource.cpp:1462)
==7905==    by 0xA6E44B0: nsGlobalHistory::NotifyAssert(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsGlobalHistory.cpp:3228)
==7905==    by 0xA6E77B2: nsGlobalHistory::NotifyFindAssertions(nsIRDFResource*, nsIMdbRow*) (nsGlobalHistory.cpp:3620)
==7905==    by 0xA6ED323: nsGlobalHistory::AddNewPageToDatabase(nsIURI*, long long, int, int, nsIURI*, nsIMdbRow**) (nsGlobalHistory.cpp:867)
==7905==    by 0xA6EDB02: nsGlobalHistory::AddPageToDatabase(nsIURI*, int, int, long long, nsIURI*) (nsGlobalHistory.cpp:663)
==7905==    by 0xA6EDC5A: nsGlobalHistory::AddURI(nsIURI*, int, int, nsIURI*) (nsGlobalHistory.cpp:578)
==7905==    by 0x5FE9255: nsDocShell::AddToGlobalHistory(nsIURI*, int, nsIChannel*) (nsDocShell.cpp:8106)
==7905==    by 0x5FEBAC3: nsDocShell::OnNewURI(nsIURI*, nsIChannel*, unsigned, int, int) (nsDocShell.cpp:7338)
==7905==    by 0x5FEBD39: nsDocShell::OnLoadingSite(nsIChannel*, int, int) (nsDocShell.cpp:7383)
==7905==    by 0x5FF48F3: nsDocShell::CreateContentViewer(char const*, nsIRequest*, nsIStreamListener**) (nsDocShell.cpp:5664)
==7905==    by 0x6016548: nsDSURIContentListener::DoContent(char const*, int, nsIRequest*, nsIStreamListener**, int*) (nsDSURIContentListener.cpp:130)
==7905==    by 0x601D54F: nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (nsURILoader.cpp:778)
==7905==    by 0x601DEA5: nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (nsURILoader.cpp:489)
==7905==    by 0x601EA1B: nsDocumentOpenInfo::OnStartRequest(nsIRequest*, nsISupports*) (nsURILoader.cpp:334)
==7905==    by 0x53F2913: nsHttpChannel::CallOnStartRequest() (nsHttpChannel.cpp:787)
==7905==    by 0x53F3609: nsHttpChannel::ProcessNormal() (nsHttpChannel.cpp:955)
==7905==    by 0x53F772E: nsHttpChannel::ProcessResponse() (nsHttpChannel.cpp:892)
==7905==    by 0x53F7B8D: nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) (nsHttpChannel.cpp:4038)
==7905==    by 0x535AD45: nsInputStreamPump::OnStateStart() (nsInputStreamPump.cpp:429)
==7905==    by 0x535B7A4: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (nsInputStreamPump.cpp:385)
==7905==    by 0x44E6A70: nsInputStreamReadyEvent::EventHandler(PLEvent*) (nsStreamUtils.cpp:120)
==7905==    by 0x450A866: PL_HandleEvent (plevent.c:688)
==7905==    by 0x450B268: PL_ProcessPendingEvents (plevent.c:623)
==7905==    by 0x450D52F: nsEventQueueImpl::ProcessPendingEvents() (nsEventQueue.cpp:419)
==7905==    by 0x6073F4D: event_processor_callback(_GIOChannel*, GIOCondition, void*) (nsAppShell.cpp:67)
==7905==    by 0x1A14FB: (within /usr/lib/libglib-2.0.so.0.600.6)
==7905==    by 0x17B4CD: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.600.6)
==7905==    by 0x17E4D5: (within /usr/lib/libglib-2.0.so.0.600.6)
==7905==    by 0x17E7C2: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.600.6)
==7905==    by 0x46C6A45: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.600.10)
==7905==    by 0x6074801: nsAppShell::Run() (nsAppShell.cpp:139)
==7905==    by 0x60B6EFB: nsAppStartup::Run() (nsAppStartup.cpp:161)
==7905==    by 0x402E0BA: XRE_main (nsAppRunner.cpp:2364)
==7905==  Address 0x8034EA8 is 8 bytes inside a block of size 16 free'd
==7905==    at 0x4004F6B: free (vg_replace_malloc.c:235)
==7905==    by 0x4057F23: free (nsTraceMalloc.c:1680)
==7905==    by 0x44BC2B2: nsFixedSizeAllocator::Free(void*, unsigned) (nsFixedSizeAllocator.cpp:150)
==7905==    by 0x5AAF499: nsTemplateMatch::Destroy(nsFixedSizeAllocator&, nsTemplateMatch*) (nsTemplateMatch.h:101)
==7905==    by 0x5ABF3C8: nsXULTemplateBuilder::UpdateResultInContainer(nsIXULTemplateResult*, nsIXULTemplateResult*, nsTemplateQuerySet*, nsIRDFResource*, nsIRDFResource*, nsIContent*) (nsXULTemplateBuilder.cpp:770)
==7905==    by 0x5AC0665: nsXULTemplateBuilder::UpdateResult(nsIXULTemplateResult*, nsIXULTemplateResult*, nsIDOMNode*) (nsXULTemplateBuilder.cpp:517)
==7905==    by 0x5AC07D6: nsXULTemplateBuilder::AddResult(nsIXULTemplateResult*, nsIDOMNode*) (nsXULTemplateBuilder.cpp:400)
==7905==    by 0x5AA0064: nsInstantiationNode::Propagate(InstantiationSet&, int, int&) (nsInstantiationNode.cpp:109)
==7905==    by 0x5AA91A8: TestNode::Propagate(InstantiationSet&, int, int&) (nsRuleNetwork.cpp:371)
==7905==    by 0x5AC477A: nsXULTemplateQueryProcessorRDF::Propagate(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsXULTemplateQueryProcessorRDF.cpp:765)
==7905==    by 0x5AC665F: nsXULTemplateQueryProcessorRDF::OnAssert(nsIRDFDataSource*, nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsXULTemplateQueryProcessorRDF.cpp:573)
==7905==    by 0x5E50030: CompositeDataSourceImpl::OnAssert(nsIRDFDataSource*, nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsCompositeDataSource.cpp:1462)
==7905==    by 0xA6E44B0: nsGlobalHistory::NotifyAssert(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsGlobalHistory.cpp:3228)
==7905==    by 0xA6E76FC: nsGlobalHistory::NotifyFindAssertions(nsIRDFResource*, nsIMdbRow*) (nsGlobalHistory.cpp:3610)
==7905==    by 0xA6ED323: nsGlobalHistory::AddNewPageToDatabase(nsIURI*, long long, int, int, nsIURI*, nsIMdbRow**) (nsGlobalHistory.cpp:867)
==7905==    by 0xA6EDB02: nsGlobalHistory::AddPageToDatabase(nsIURI*, int, int, long long, nsIURI*) (nsGlobalHistory.cpp:663)
==7905==    by 0xA6EDC5A: nsGlobalHistory::AddURI(nsIURI*, int, int, nsIURI*) (nsGlobalHistory.cpp:578)
==7905==    by 0x5FE9255: nsDocShell::AddToGlobalHistory(nsIURI*, int, nsIChannel*) (nsDocShell.cpp:8106)
==7905==    by 0x5FEBAC3: nsDocShell::OnNewURI(nsIURI*, nsIChannel*, unsigned, int, int) (nsDocShell.cpp:7338)
==7905==    by 0x5FEBD39: nsDocShell::OnLoadingSite(nsIChannel*, int, int) (nsDocShell.cpp:7383)
==7905==    by 0x5FF48F3: nsDocShell::CreateContentViewer(char const*, nsIRequest*, nsIStreamListener**) (nsDocShell.cpp:5664)
==7905==    by 0x6016548: nsDSURIContentListener::DoContent(char const*, int, nsIRequest*, nsIStreamListener**, int*) (nsDSURIContentListener.cpp:130)
==7905==    by 0x601D54F: nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (nsURILoader.cpp:778)
==7905==    by 0x601DEA5: nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (nsURILoader.cpp:489)
==7905==    by 0x601EA1B: nsDocumentOpenInfo::OnStartRequest(nsIRequest*, nsISupports*) (nsURILoader.cpp:334)
==7905==    by 0x53F2913: nsHttpChannel::CallOnStartRequest() (nsHttpChannel.cpp:787)
==7905==    by 0x53F3609: nsHttpChannel::ProcessNormal() (nsHttpChannel.cpp:955)
==7905==    by 0x53F772E: nsHttpChannel::ProcessResponse() (nsHttpChannel.cpp:892)
==7905==    by 0x53F7B8D: nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) (nsHttpChannel.cpp:4038)
==7905==    by 0x535AD45: nsInputStreamPump::OnStateStart() (nsInputStreamPump.cpp:429)
==7905==    by 0x535B7A4: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (nsInputStreamPump.cpp:385)
==7905==    by 0x44E6A70: nsInputStreamReadyEvent::EventHandler(PLEvent*) (nsStreamUtils.cpp:120)
==7905==    by 0x450A866: PL_HandleEvent (plevent.c:688)
==7905==    by 0x450B268: PL_ProcessPendingEvents (plevent.c:623)
==7905==    by 0x450D52F: nsEventQueueImpl::ProcessPendingEvents() (nsEventQueue.cpp:419)
==7905==    by 0x6073F4D: event_processor_callback(_GIOChannel*, GIOCondition, void*) (nsAppShell.cpp:67)
==7905==    by 0x1A14FB: (within /usr/lib/libglib-2.0.so.0.600.6)
==7905==    by 0x17B4CD: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.600.6)
==7905==    by 0x17E4D5: (within /usr/lib/libglib-2.0.so.0.600.6)
==7905==    by 0x17E7C2: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.600.6)
==7905== 

followed by an equivalent error for the get() just inside operator->, and then the same pair of errors repeated again with a slightly different access stack (but with all 4 errors complaining about accessing the same freed address):

==7905== Invalid read of size 4
==7905==    at 0x5AA165C: nsCOMPtr<nsIXULTemplateResult>::operator->() const (nsCOMPtr.h:849)
==7905==    by 0x5AA12F0: nsTreeRows::FindByResource(nsIRDFResource*) (nsTreeRows.cpp:189)
==7905==    by 0x5AB2FCE: nsXULTreeBuilder::GetInsertionLocations(nsIXULTemplateResult*, nsISupportsArray**) (nsXULTreeBuilder.cpp:1122)
==7905==    by 0x5AC03C1: nsXULTemplateBuilder::UpdateResult(nsIXULTemplateResult*, nsIXULTemplateResult*, nsIDOMNode*) (nsXULTemplateBuilder.cpp:446)
==7905==    by 0x5AC07D6: nsXULTemplateBuilder::AddResult(nsIXULTemplateResult*, nsIDOMNode*) (nsXULTemplateBuilder.cpp:400)
==7905==    by 0x5AA0064: nsInstantiationNode::Propagate(InstantiationSet&, int, int&) (nsInstantiationNode.cpp:109)
==7905==    by 0x5AA91A8: TestNode::Propagate(InstantiationSet&, int, int&) (nsRuleNetwork.cpp:371)
==7905==    by 0x5AC477A: nsXULTemplateQueryProcessorRDF::Propagate(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsXULTemplateQueryProcessorRDF.cpp:765)
==7905==    by 0x5AC665F: nsXULTemplateQueryProcessorRDF::OnAssert(nsIRDFDataSource*, nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsXULTemplateQueryProcessorRDF.cpp:573)
==7905==    by 0x5E50030: CompositeDataSourceImpl::OnAssert(nsIRDFDataSource*, nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsCompositeDataSource.cpp:1462)
==7905==    by 0xA6E44B0: nsGlobalHistory::NotifyAssert(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*) (nsGlobalHistory.cpp:3228)
==7905==    by 0xA6E77B2: nsGlobalHistory::NotifyFindAssertions(nsIRDFResource*, nsIMdbRow*) (nsGlobalHistory.cpp:3620)
...


It seems like this could be the kind of crash if code isn't resistant against having some of its objects leaked, or something like that.  That's just speculation, though.

Comment 1

[Neil Deakin]

I couldn't get this to crash when I tried, so some more specific steps to reproduce would be good.

Offhand, it could be caused by the need for error handling for the calls to ReplaceMatch in nsXULTemplateBuilder::UpdateResultInContainer

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I just saw this for the first time without accessibility enabled, although it's much rarer that way.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I just saw it in a (non-places) build from yesterday afternoon, without accessibility enabled, so it's still around.  It may have something to do with clicking something in the history sidebar and then quickly closing it.

Comment 4

[Mike Schroepfer]

Since this is not a topcrash and requires a specific set of things to repro we are taking it off the blocking 1.8.1 radar.  Would happily take a fix if there were one.

Comment 5

[Felix Miata]

On moznet ajschult said that my tb22809368y looks like this bug. I use KDE 3.4.2, and don't believe I have switched on any kind of accessibility enabling. I do not use any sidebars. I had what I think is the same crash twice within a few hours. I believe I had the history window open each time, and I know I had it open the last time. I didn't submit the TB report the first time. The trigger was right clicking the link in the context menu "open in new tab".

Comment 6

[Felix Miata]

If my comment 5 talkback and the two more talkbacks from me today are the same as this bug, the summary needs "sidebar" removed, and severity increased.

Comment 7

[Felix Miata]

tb22984627m & tb22965570z happened from attempting to open link in new tab shortly after clicking the close window X on the history window.

Comment 8

[Nickolay_Ponomarev]

I'm consistently crashing with this stack with the following steps to repro (win):
2. Open history toolbar (CTRL+H)
3. Open the 'Today' folder
4. CTRL+B to switch to the bookmarks sidebar
5. Open Bookmarks Toolbar Folder -> Getting Started
6. If previous step doesn't crash, hit CTRL+H (quickly).

Comment 9

[[e-mail]]

*** Bug 361508 has been marked as a duplicate of this bug. ***

Comment 10

[Neil Deakin]

Attachment: fix crash by clearing rows list when setting boxobject to null

The main fix is in nsXULTreeBuilder::SetTree. Most of the rest is just adding comments and making sure that matches are cleaned up properly. I've tested with the various template tests at http://www.xulplanet.com/ndeakin/tests/xts/templates/ as well as some automated tests I'm working on and things seem to work.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not really the right person to review template stuff. I can sr though.

Comment 12

[Felix Miata]

same as comment 7 TB27763100Y

Comment 13

[Felix Miata]

I built my own SM trunk on Linux with GCC 4.0.2 on SUSE 10.0 yesterday using the attached patch, but that didn't stop my crashes, so I filed bug 367310.

Comment 14

[Neil Deakin]

This should be fixed now that bug 367310 is fixed.