test_tmpl_storage_bad_parameters_2.xul (and others) don't close their database

RESOLVED FIXED in mozilla14



7 years ago
7 years ago


(Reporter: espindola, Assigned: espindola)



Firefox Tracking Flags

(Not tracked)



(2 attachments, 5 obsolete attachments)

This is similar to bug 739656, but in this case the database is created implicitly, so it is harder to know how to close it.
Summary: est_tmpl_storage_bad_parameters_2.xul (and others) don't close their database → test_tmpl_storage_bad_parameters_2.xul (and others) don't close their database
Created attachment 610537 [details] [diff] [review]
close connection earlier

Assignee: nobody → respindola
Attachment #610537 - Flags: review?
Created attachment 610660 [details] [diff] [review]
hack patch to reproduce the windows failures

This is just a hack patch I used it to reproduce the windows failure.
It is a useful debugging hack to replace a T* with at nsCOMPtr<T> just to check the refcount.
Created attachment 610661 [details] [diff] [review]
close connection earlier

Attachment #610537 - Attachment is obsolete: true
Attachment #610537 - Flags: review?
Attachment #610661 - Flags: review?(enndeakin)
Created attachment 610662 [details] [diff] [review]
close connection
Attachment #610661 - Attachment is obsolete: true
Attachment #610661 - Flags: review?(enndeakin)
Attachment #610662 - Flags: review?(enndeakin)

Comment 5

7 years ago
Comment on attachment 610662 [details] [diff] [review]
close connection

You may also want to clear mQueryProcessor at the end of nsXULTemplateBuilder::ContentRemoved as it calls Uninit(false)

Just to be safe, can you also add a null check (returning 0) to nsXULTreeBuilder::CompareResults before mQueryProcessor is accessed as that can indirectly be called by script.
Attachment #610662 - Flags: review?(enndeakin) → review+
Created attachment 610894 [details] [diff] [review]
close connection

Would you mind checking if I got the code review right?
Attachment #610662 - Attachment is obsolete: true
Attachment #610894 - Flags: review?(enndeakin)


7 years ago
Attachment #610894 - Flags: review?(enndeakin) → review+
Looks like try found a problem. Trying the hack xpcom hack as before.

Comment 8

7 years ago
The crash stack suggests that the query processor is being accessed by the call to UninitFalse from nsXULTemplateBuilder::ContentRemoved after the query processor has been set to null. The issue is that the script runner delays calling UninitFalse because it isn't safe to run script.

It may be possible to just add a variation of UninitFalse which clears mQueryProcessor afterwards or just remove that change again.
What is happening is that nsINode::doRemoveChildAt looks like

  if (aNotify) {
    nsNodeUtils::ContentRemoved(this, aKid, aIndex, previousSibling);


On the ContentRemoved call we get to nsXULTemplateBuilder::ContentRemoved which in the new patch sets mQueryProcessor to null.

On the call to UnbindFromTree we get to nsXULTemplateBuilder::Uninit which calls

mMatchMap.Enumerate(DestroyMatchList, &mPool);

which will end up deleting a nsRDFQuery whose destructor will access the deleted nsXULTemplateQueryProcessorRDF.

The two simple fixes I see are
* Don't set mQueryProcessor to null in nsXULTemplateBuilder::ContentRemoved (i.e., go with the old patch).
* Run mMatchMap.Enumerate(DestroyMatchList, &mPool) in nsXULTemplateBuilder::ContentRemoved. (can we do that?)
Created attachment 611016 [details] [diff] [review]
hack patch to reproduce the windows failures with the new patch
Attachment #610660 - Attachment is obsolete: true
I did a try push to


and it looks green. I will remove the debug bits and send for review.

Comment 13

7 years ago
Comment on attachment 611854 [details] [diff] [review]
close connection

Seems ok, although I wonder why the script runner was necessary.
Attachment #611854 - Flags: review?(enndeakin) → review+
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Duplicate of this bug: 739656
You need to log in before you can comment on or make changes to this bug.