Closed Bug 416521 Opened 18 years ago Closed 7 years ago

Crash [@ _free] (XPCWrappedNative::CallMethod)

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: pavlov, Unassigned)

References

(
URL
)

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

lm, !lmi firefox
9.07 KB, text/plain
Details
enabled addons
336 bytes, text/plain
Details
My Firefox addons, as listed by one of them (MR-Tech Toolkit).
14.70 KB, text/html
Details
Ever since jemalloc went in there have been a bunch of crashes on Windows showing up from breakpad. They all have basically the same stack: 0 free jemalloc.c:6024 1 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2509 2 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned int, long*, long*) mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1470 ... This would probably be pretty easy to figure out if I could get it to happen in the debugger, but I don't have a reproducible testcase. [Wild speculation]Looking through that code most of it hasn't changed in years but I'm wondering if maybe the shared IID changes last month cause the nsXPTType::T_IID SetValIsAllocated() code to do bad things.[/Wild Speculation] Anyone have any thoughts?
Flags: blocking1.9+
Otherwise, could we somehow be getting mismatched allocations/frees here?
Another possibility is a double free. jemalloc may react differently than the system malloc to freeing the same object twice, depending on the allocation pattern.
This looks to be caused by the "Free Download Manager" extension -- very similar to bug 354624. this code certainly looks bad: http://freedownload.svn.sourceforge.net/viewvc/freedownload/FDM/Firefox/XPCOM%20Component/FDMUrl.cpp?view=markup Can we blacklist this extension (again?) until it gets updated?
Version: unspecified → Trunk
(In reply to comment #3) > This looks to be caused by the "Free Download Manager" extension -- very > similar to bug 354624. > > this code certainly looks bad: > http://freedownload.svn.sourceforge.net/viewvc/freedownload/FDM/Firefox/XPCOM%20Component/FDMUrl.cpp?view=markup > > Can we blacklist this extension (again?) until it gets updated? > reopen bug 408445?
Go for it -- update 408445 with the hnew ranges and GUID and will get it in.
Assignee: nobody → honzab
Assignee: honzab → nobody
Severity: normal → critical
As given in the comments field of crash reports this mostly happens when opening the context menu of a website at any place. http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&signature=free&query=free&range_value=1
Um, is this just the free download manager crash? (bug 354624)
Could be or not. But as bug 354624 comment 42 states the crash was getting fixed in the newest release 1.3.1 of FDM. After one and a half month nearly all installations should have been updated or everyone has deselected the add-ons check. I think that we shouldn't dupe this bug as this time. Please let us investigate.
There are more crashes with this stack than just free download manager. As best I can tell the only way to figure out what they are is to look at the modules and look for ones that don't have symbols and do some google searches :/ I haven't had time to track down more of them, FDM was certainly the one I saw most often, but if someone can go through and find the other extensions causing this crash that would be great.
Probably would help if we fixed bug 412605 :-/
This is definitely a topcrash for 3.0b4. So far: * it's 6 out of a sample of 10 of the "RtlEnterCriticalSection" crashes (#2) * it's 9 out of a sample of 10 of the "free" crashes (#3) * it's 5 out of a sample of 10 of the "arena_dalloc_small" crashes (#15) By "this", I mean crashes where the stack involves crashing in free called from http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/xpcwrappednative.cpp&rev=1.188&mark=2539#2539
(In reply to comment #11) > Probably would help if we fixed bug 412605 :-/ For binary extensions you can just look at the list of modules. For free download manager, look for vmsfdmff.dll. I sampled 10 consecutive new Fx3b4 crashes in "free". Of them: * 10 were this crash (per standard in comment 12) * 9 of those had vmsfmdff.dll loaded (version 738.0.0.8 -- although I don't think I checked the version every time) Likewise, for a new (and more spread out, to avoid issues with the same user crashing many times in a row) sample of 10 RtlEnterCriticalSection crashes: * 6 were this crash (per standard in comment 12) * two of those had vmsfmdff.dll loaded * two of them (different ones) had the skype toolbar components loaded (SPhoneParser.dll and PNRComponent.dll)
I took a more spread out sample of 10 crashes in free: * 9 of the 10 were this crash (per comment 12) * 7 of those 9 had vmsfmdff.dll loaded (and the other two had SPhoneParser.dll and PNRComponent.dll loaded)
Did this get missed during the Great Retriage?
Flags: tracking1.9+ → blocking1.9?
This should either be closed WONTFIX or we should do work here to blacklist bad binary extensions.
K, not gonna block on this. Sam or Hoffmann, can you file follow ups for blacklisting offending add-ons?
Flags: blocking1.9? → blocking1.9-
Hi, I have a crash dump I believe may be useful to track this one down (or perhaps it's another bug). My stack: 08 0012f65c 60006d3e 002a0040 0f300000 0f3dd000 MOZCRT19!arena_dalloc_small+0x1c [e:\fx19rel\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\jemalloc.c @ 4094] 09 0012f674 60007d90 0f3dd000 0012f6ec 00000000 MOZCRT19!arena_dalloc+0x2e [e:\fx19rel\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\jemalloc.c @ 4200] 0a 0012f684 604dabaa 0f3dd000 80000000 80000000 MOZCRT19!free+0x20 [e:\fx19rel\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\jemalloc.c @ 6009] 0b 0012f698 606e736e 00000000 132a5a10 60712e7b xul!nsACString_internal::SetCapacity+0xda [e:\fx19rel\winnt_5.2_depend\mozilla\xpcom\string\src\nstsubstring.cpp @ 563] 0c 0012f6a4 60712e7b ffffffff 132a5a10 00000000 xul!nsACString_internal::Adopt+0x17c76e 0d 0012f6f8 605b5b6b 132a5a10 132a5a3c 132a5a3c xul!nsHttpChannel::CheckCache+0x101bf9 0e 0012f71c 605b565d 00000000 16d55ebc 00000000 xul!nsHttpChannel::Connect+0xf9 [e:\fx19rel\winnt_5.2_depend\mozilla\netwerk\protocol\http\src\nshttpchannel.cpp @ 317] 0f 0012f734 60538b2d 142432b8 16bf6520 00000000 xul!nsHttpChannel::AsyncOpen+0x117 [e:\fx19rel\winnt_5.2_depend\mozilla\netwerk\protocol\http\src\nshttpchannel.cpp @ 3712] 10 0012f7a4 605a5adb 132a5a3c 00000000 01cb4000 xul!CSSLoaderImpl::LoadSheet+0x37d [e:\fx19rel\winnt_5.2_depend\mozilla\layout\style\nscssloader.cpp @ 1460] 11 0012f7e4 605a9e9c 06529b40 16d0a970 00000000 xul!CSSLoaderImpl::LoadChildSheet+0x235 [e:\fx19rel\winnt_5.2_depend\mozilla\layout\style\nscssloader.cpp @ 1951] 12 0012f85c 605c2eaf 0012f968 00000000 155ecdb0 xul!CSSParserImpl::ProcessImport+0xdd [e:\fx19rel\winnt_5.2_depend\mozilla\layout\style\nscssparser.cpp @ 1434] 13 0012f928 6057a08b 604c66a0 01cb4000 01cb4000 xul!CSSParserImpl::ParseImportRule+0xb9 [e:\fx19rel\winnt_5.2_depend\mozilla\layout\style\nscssparser.cpp @ 1405] The crash happened when I dragged an url into a tab to have it opening there.
we'd need to see a list of your loaded modules !lmi (as an attachment) and probably a list of your extensions (as an attachment)
Attached file lm, !lmi firefox —
contents from windbg lm and !lmi firefox
Attached file enabled addons —
My addons list. If anyone knows a way of getting this easily from an about:* url it would be appreciated as it's quite boring to copy the list by hand :P
hrm, that should have been "!lmi *", the only thing interesting that i could see from lm was prism (which i don't know to do anything interesting) and npswf32 (flash) which i don't think we've implicated in this class of crashes.... i'm pretty sure there's an extension that lets you copy the extension list. irc.mozilla.org should have someone who could help you find it. i'd suggest trying to run w/ all (or half) of your extensions disabled for a while and see how things go... if things go well, try the other half, if things go poorly, disable half of what isn't disabled ....
I'm a Web app developer, and use FF 3.0 since rc2 for my job, and all goes well until today, since today the FF crashes in every time in different parts of my application ! There seams no pattern to reproduce the error. I generated allot of crash reports like : ID: 9064f700-4799-11dd-98f8-001cc45a2c28 and ID: db02fbc5-479f-11dd-a234-001a4bd43ed6 Is this but related ? or I need to create another ? If you need more information, just ask, the crash is easily reproducible :-(
Did you recently install any extensions? What you're seeing could easily have been triggered by a broken extension and/or plugin.
The problem happens in Safe Mode too, because of this I excluded this possibility. I this right ?
I honestly don't know how safe our safe mode is (not something I've been involved in personally), so I don't know the answer to that question.
Oh, and I meant to say, testing with a fresh profile and/or a fresh install of Firefox and reporting back what you find could be useful information as well.
(In reply to comment #23) > until today, since today the FF crashes in every time in different parts of my > application ! There seams no pattern to reproduce the error. > I generated allot of crash reports like : > ID: 9064f700-4799-11dd-98f8-001cc45a2c28 > and > ID: db02fbc5-479f-11dd-a234-001a4bd43ed6 The stacks are different and even the second link can't resolved to a stack trace. Looks like the uid is broken. But anyway, I believe that your problem better fits into bug 434752.
I tried with a empty profile and the error is gone, this teach to me that the safe mode isn't so safe... Thanks for your help, I will go to the bug you suggested.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11pre) Gecko/2009042504 GranParadiso/3.0.11pre - Build ID: 2009042504 crash bp-fcbfc017-efd8-4b3f-ae6f-45a562090426 [@ XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)] [@ XPC_WN_CallMethod] on Linux today trying to scroll the bookmark manager by clicking the scrollbar outside the thumb. Didn't try to reproduce, and I'm soon going to install the next Fx3.0 nightly. Deep down the stack I see a "ButtonPressEvent" which (if not the scrolling click mentioned above) could have been the OK click in the Ctrl-D dialog (that dialog looked weird, with buttons and input boxes, but no background, and the underlying page was visible "under" it). Download manager not yet used in this session. The rest of the stack points to javascript routines with a loop back (once) to XPCWrappedNative::CallMethod, XPC_WN_CallMethod, js_Invoke, js_Interpret, js_Invoke, js_InternalInvoke, etc. Can someone check if this is the right bug for this crash? If it is, Platform should be changed to All and the stack appended to the bug. If it isn't, then it's some other bug.
Crash Signature: [@ _free]
Keywords: crash
Stuart, I have a hard time finding that signature in current data, is this bug still of any value? The very low volume https://crash-stats.mozilla.com/report/list?signature=free%20%7C%20XPCWrappedNative%3A%3ACallMethod%28XPCCallContext%26%2C%20XPCWrappedNative%3A%3ACallMode%29 might be this, but could be something else as well. Not sure if it makes sense to keep the bug report around when we can't even connect anything specific to it any more.
Removing the top crash keyword for now.
Keywords: topcrash
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: