Closed
Bug 650149
Opened 13 years ago
Closed 6 years ago
Firefox 4.2a1pre Crash Report [@ nsDocument::CreateElement(nsAString_internal const&, nsIDOMElement**) ] called from rlxg.dll or bdaphff4.dll
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: smooney, Assigned: sayrer)
References
Details
(Keywords: crash)
Crash Data
New crash started appearing in the trunk April 12th, 2011 and it also appears on Aurora. Looks maybe malware related but probably needs more investigation to see if we broke something. Looks like a startup crash. Signature nsDocument::CreateElement(nsAString_internal const&, nsIDOMElement**) UUID 191e4a5c-6ee3-4ee6-9ef1-4f1df2110414 Time 2011-04-14 08:57:30.857836 Uptime 2 Last Crash 49970 seconds (13.9 hours) before submission Install Age 162132 seconds (1.9 days) since version was first installed. Product Firefox Version 4.2a1pre Build ID 20110412030535 Branch 2.2 OS Windows NT OS Version 6.1.7601 Service Pack 1 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 11 Crash Reason EXCEPTION_ACCESS_VIOLATION_WRITE Crash Address 0xfffffffffd21f6ba User Comments App Notes AdapterVendorID: 10de, AdapterDeviceID: 0611, AdapterDriverVersion: 8.17.12.6658 D2D? D2D+ DWrite? DWrite+ Processor Notes EMCheckCompatibility False Frame Module Signature [Expand] Source 0 xul.dll nsDocument::CreateElement content/base/src/nsDocument.cpp:4372 1 bdaphff4.dll bdaphff4.dll@0x47d5 2 bdaphff4.dll bdaphff4.dll@0x5e17 3 bdaphff4.dll bdaphff4.dll@0x3876 4 msvcr90.dll msvcr90.dll@0x361a1 5 mozcrt19.dll free obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:6124 Crash reports: https://crash-stats.mozilla.com/report/list?product=Firefox&branch=2.2&platform=windows&build_id=20110412030535&query_search=signature&query_type=exact&query=&date=04%2F14%2F2011%2016%3A03%3A52&range_value=30&range_unit=days&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsDocument%3A%3ACreateElement%28nsAString_internal%20const%26%2C%20nsIDOMElement**%29
Reporter | ||
Updated•13 years ago
|
OS: Mac OS X → Windows 7
Reporter | ||
Comment 1•13 years ago
|
||
Ok, I don't know anything about this one but it started showing up on the April 14th and it's moved up the list on Aurora. Can we at least get someone to look at it?
tracking-firefox5:
--- → +
Comment 2•13 years ago
|
||
Do you have a link to the c-s.m.c query for this, some recent query.
Comment 3•13 years ago
|
||
https://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsDocument%3A%3ACreateElement%28nsAString_internal%20const%26%2C%20nsIDOMElement**%29&version=Firefox%3A5.0a2
Comment 4•13 years ago
|
||
There seems to be bdaphff4.dll or some other .dll in the stack.
Reporter | ||
Updated•13 years ago
|
This is probably a regression from https://hg.mozilla.org/mozilla-central/rev/4d2da0c23ae2 which removed one entry from the nsIDOMNode vtable. That patch looks correct on our end, though, since it appears to have regenerated the IIDs of all the derived classes. Perhaps this DLL: * is injecting code into our process without being an XPCOM component * is using nsIDOMDocument and calling createDocumentFragment on it without checking the IID. (We only bump the IIDs of the interfaces whose signatures change, not the IIDs of interfaces that have methods that take or return such an object.)
Blocks: 604592
It's probably worth double-checking that we didn't miss any IIDs of interfaces derived from nsIDOMDocument, though.
Summary: Firefox 4.2a1pre Crash Report [@ nsDocument::CreateElement(nsAString_internal const&, nsIDOMElement**) ] → Firefox 4.2a1pre Crash Report [@ nsDocument::CreateElement(nsAString_internal const&, nsIDOMElement**) ] called from rlxg.dll or bdaphff4.dll
Yeah, it's a problem that interfaces which take and return (especially return) interfaces which have been modified aren't updated. Really, the only realistic way to catch them all is either using some sort of automated scripts, or by simply revving the iid on *all* interfaces for each release.
rlxg.dll is RelevantKnowledge; we've had issues with them before. bdaphff4.dll has only a single google hit for it, which is: http://www.prevx.com/filenames/X1727969008474019628-X1/BDAPHFF4.DLL.html
Comment 10•13 years ago
|
||
Bug 615518 is on file for blocklisting rlxg.dll.
Comment 11•13 years ago
|
||
It doesn't sound like anyone is proposing actually taking the steps Jonas outlined in comment 9 in time for Firefox 5, so is blocklisting relevant knowledge sufficient here for 5 or is there more we can do?
Updated•13 years ago
|
Assignee: nobody → sayrer
Reporter | ||
Comment 12•13 years ago
|
||
We are not seeing the signature (rlxg.dll) in b3 right now. We don't see the bdaphff4.dll either.
Updated•13 years ago
|
status-firefox5:
--- → fixed
Updated•13 years ago
|
Crash Signature: [@ nsDocument::CreateElement(nsAString_internal const&, nsIDOMElement**) ]
Updated•9 years ago
|
Crash Signature: [@ nsDocument::CreateElement(nsAString_internal const&, nsIDOMElement**) ] → [@ nsDocument::CreateElement(nsAString_internal const&, nsIDOMElement**) ]
[@ nsDocument::CreateElement ]
Comment 13•6 years ago
|
||
Closing because no crashes reported for 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•