Crash @ nsNodeUtils::LastRelease

NEW
Unassigned

Status

()

--
critical
7 years ago
7 years ago

People

(Reporter: imphil, Unassigned)

Tracking

({crash, testcase})

Trunk
x86_64
Linux
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(4 attachments)

(Reporter)

Description

7 years ago
Created attachment 594539 [details]
backtrace

With the XForms extension I get a crash at nsNodeUtils::LastRelease when closing a page using XForms. Backtrace is attached.
(Reporter)

Comment 1

7 years ago
STR

In your tree:

cd extensions
hg clone http://hg.mozilla.org/xforms
cd .hg
hg clone http://philipp.wagner.name/hg/patches-xforms patches
cd ..
hg qpush # until domnodelist-newmethod.patch is on top

cd ../
hg clone http://hg.mozilla.org/schema-validation
cd .hg
hg clone http://philipp.wagner.name/hg/patches-schema-validation patches
cd ..
hg qpush -a

and there are two mozilla-central patches ....
http://philipp.wagner.name/hg/patches-mozilla-central/raw-file/7f9aa44422d7/nsixpathevaluatorexternal-string.patch
and 
http://philipp.wagner.name/hg/patches-mozilla-central/raw-file/7f9aa44422d7/bug718201-getnodeat.patch


build with 
ac_add_options --enable-extensions="default,xforms"
(Reporter)

Comment 3

7 years ago
To make it easier, I also uploaded the xforms.xpi to http://philipp.wagner.name/temp/xforms-mc.xpi It's built from yesterday's mozilla-central with debug symbols for Linux x86_64. If you need another build just tell me. If it's easier for you I could also upload a patched source tree somewhere.

Updated

7 years ago
Severity: normal → critical
Crash Signature: [@ nsNodeUtils::LastRelease(nsINode*)] [@ nsNodeUtils::LastRelease]
Keywords: crash

Comment 4

7 years ago
I haven't yet build xforms addon, but one guess is that it uses
nsINode "properties" and does something unexpected to a property when an element is being removed.
(Reporter)

Comment 5

7 years ago
What's better than doing a long bisect on a cold day to keep the CPU and your room warm?
The result is this regression range (I know, this is rather old; no idea why I didn't catch it earlier):

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cf5f013caa80&tochange=b993e9c8edbe

This would lead to bug 566466 as cause for this. Olli, any idea? I will attach a updated backtrace for the first failing changeset (b993e9c8edbe), which is a bit different than the current one but similar enough I'd say.

If you need the XForms code that builds with this revision please tell me, also the steps above to get a current XForms build have changed in the meantime. Just ping me if you need something to make your life easier with this.
(Reporter)

Comment 6

7 years ago
Created attachment 596084 [details]
backtrace for revision b993e9c8edbe (Gecko 2.0b2+)
(Reporter)

Comment 7

7 years ago
Created attachment 596090 [details]
reduced XForms testcase
(Reporter)

Comment 8

7 years ago
Created attachment 596091 [details]
run the testcase and call CC afterwards

I attached the reduced XForms test case and a small html page that runs the test case and calls the CC afterwards. In more recent builds just clicking "Minimize memory usage" in about:memory does the same trick.
To work, popup blocker must be disabled and a debug build must be used.

Comment 9

7 years ago
Oh... is there something wrong with XTF element creation.

Updated

7 years ago
Keywords: testcase
I still wonder if some xforms node has properties, and then releasing the property causes other
badness.
Assignee: alex → nobody
Component: XTF → XSLT
QA Contact: xtf → xslt
(Reporter)

Comment 11

7 years ago
XForms uses properties at some places, yes, but from my debugging I don't see anything that would hint that properties are the cause for this.

I finally managed to get a backtrace from where the nsXTFElementWrapper object is coming from, that causes the crash when it is destroyed: http://hg.mozilla.org/xforms/file/8fd9a06f667d/nsXFormsItemSetElement.cpp#l359, that is (adapted to current mozilla-central):
  templateNode->CloneNode(true, 1, getter_AddRefs(cloneNode));

The full backtrace looks like this: http://pastebin.mozilla.org/1498672
You need to log in before you can comment on or make changes to this bug.