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

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

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.

Comment 1

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: close connection earlier

https://tbpl.mozilla.org/?tree=Try&rev=81cbb2d8c27a

Comment 2

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: 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.

Comment 3

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: close connection earlier

https://tbpl.mozilla.org/?tree=Try&rev=62dd7535e3bc

Comment 4

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: close connection

Comment 5

[Neil Deakin]

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.

Comment 6

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: close connection

Would you mind checking if I got the code review right?
https://tbpl.mozilla.org/?tree=Try&rev=c7ec73bf07e1

Comment 7

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Looks like try found a problem. Trying the hack xpcom hack as before.

Comment 8

[Neil Deakin]

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.

Comment 9

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

What is happening is that nsINode::doRemoveChildAt looks like

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

  aKid->UnbindFromTree();

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?)

Comment 10

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: hack patch to reproduce the windows failures with the new patch

Comment 11

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

I did a try push to

https://tbpl.mozilla.org/?tree=Try&rev=cc011e039cc2

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

Comment 12

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: close connection

https://tbpl.mozilla.org/?tree=Try&rev=f9fddcb2f788

Comment 13

[Neil Deakin]

Comment on attachment 611854 [details] [diff] [review]
close connection

Seems ok, although I wonder why the script runner was necessary.

Comment 14

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=5d82421a984d

Comment 15

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/5d82421a984d