Closed Bug 354624 (fdmcrash) Opened 18 years ago Closed 17 years ago

right click on any page will crash firefox with free download manager extension

Categories

(Core :: XPConnect, defect)

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

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: fullmetaljacket.xp+bugmail, Unassigned)

References

Details

(Keywords: crash, topcrash)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20060927 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20060927 Minefield/3.0a1 right click on any page will crash firefox after extension of free download manager version 2.91 build 264 was installed Reproducible: Always Steps to Reproduce: 1. just right click any open page 2. 3. Actual Results: no output, firefox just crashed Expected Results: firefox context menu will be showned
Version: unspecified → Trunk
sorry it was free download manager version 2.91 build 494 extension and not build 264.
Please understand that Bugzilla does not deal with problems with third party extensions or programs. Please report such problems to the maker of the extension/program itself.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
reporter: please install talkback and provide an incident id. edjackiel@gmail.com: that's odd. i was pretty sure we did want to fix any crashes we could.
URL: any site
Keywords: stackwanted
(In reply to comment #3) > reporter: please install talkback and provide an incident id. > > edjackiel@gmail.com: that's odd. i was pretty sure we did want to fix any > crashes we could. > as per your advise, here is the incident id (one of many): TB23847868Z
(In reply to comment #2) > Please understand that Bugzilla does not deal with problems with third party > extensions or programs. Please report such problems to the maker of the > extension/program itself. > sorry but does this not fall under extension compatibility issue?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Incident ID: 23847868 Stack Signature ntdll.dll + 0x5d8df (0x7749d8df) 8b8954cb Product ID FirefoxTrunk Build ID 2006092704 Trigger Time 2006-09-27 22:25:20.0 Platform Win32 Operating System Windows NT 6.0 build 5728 Module ntdll.dll + (0005d8df) URL visited User Comments Since Last Crash 11 sec Total Uptime 11 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace ntdll.dll + 0x5d8df (0x7749d8df) ntdll.dll + 0x5d56c (0x7749d56c) ntdll.dll + 0x5d456 (0x7749d456) kernel32.dll + 0x5af3a (0x772eaf3a) MSVCR80.dll + 0x4c3b (0x78134c3b) XPCWrappedNative::CallMethod [mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2330] hrm, not very helpful. could you possibly follow the steps at http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg our bugzilla does deal with crashes in gecko code, your talkback incident qualifies.
Keywords: crash
(In reply to comment #1) > sorry it was free download manager version 2.91 build 494 extension and not > build 264. Could you provide a URL where this extension can be obtained?
(In reply to comment #7) > > Could you provide a URL where this extension can be obtained? > http://www.freedownloadmanager.org/download.htm note: extension is included on the whole software installer.
I tried this out with mcsmurf's debug build (after installing FDM) and this is what I get: When I right click, WinDBG breaks with this message: HEAP[firefox.exe]: Invalid Address specified to RtlFreeHeap( 01120000, 02A91818 ) (cb8.550): Break instruction exception - code 80000003 (first chance) eax=02a91810 ebx=02a91810 ecx=7c91eb05 edx=0013dba2 esi=01120000 edi=02a91810 eip=7c901230 esp=0013ddac ebp=0013ddb0 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c901230 cc int 3 and the stacktrace: 0:000> kp ChildEBP RetAddr 0013dda8 7c96c943 ntdll!DbgBreakPoint 0013ddb0 7c96cd80 ntdll!RtlpBreakPointHeap+0x28 0013ddc4 7c96df66 ntdll!RtlpValidateHeapEntry+0x113 0013de38 7c94a5d0 ntdll!RtlDebugFreeHeap+0x97 0013df20 7c9268ad ntdll!RtlFreeHeapSlowly+0x37 0013dff0 78134b9f ntdll!RtlFreeHeap+0xf9 0013e03c 0048d77f MSVCR80!free(void * pBlock = 0x02a91818)+0xcd [f:\rtm\vctools\crt_bld\self_x86\crt\src\free.c @ 110] 0013e1e8 004903ea firefox!XPCWrappedNative::CallMethod(class XPCCallContext * ccx = 0x0013e204, XPCWrappedNative::CallMode mode = CALL_METHOD (0))+0xa4e [h:\mozilla\tree-main\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 2330] 0013e284 10020efa firefox!XPC_WN_CallMethod(struct JSContext * cx = 0x01bda0f8, struct JSObject * obj = 0x01e90328, unsigned int argc = 1, long * argv = 0x01d6af00, long * vp = 0x0013e2cc)+0xa2 [h:\mozilla\tree-main\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp @ 1455] 0013e33c 100269bf js3250!js_Invoke(struct JSContext * cx = 0x01bda0f8, unsigned int argc = 1, unsigned int flags = 0)+0x558 [h:\mozilla\tree-main\mozilla\js\src\jsinterp.c @ 1377] 0013e4b4 10020f38 js3250!js_Interpret(struct JSContext * cx = 0x01bda0f8, unsigned char * pc = 0x01d72100 ";", long * result = 0x0013e540)+0x4f71 [h:\mozilla\tree-main\mozilla\js\src\jsinterp.c @ 3929] 0013e564 0049889a js3250!js_Invoke(struct JSContext * cx = 0x01bda0f8, unsigned int argc = 1, unsigned int flags = 2)+0x596 [h:\mozilla\tree-main\mozilla\js\src\jsinterp.c @ 1396] 0013e724 0049694d firefox!nsXPCWrappedJSClass::CallMethod(class nsXPCWrappedJS * wrapper = 0x0237f080, unsigned short methodIndex = 3, class nsXPTMethodInfo * info = 0x019db940, struct nsXPTCMiniVariant * nativeParams = 0x0013e760)+0x7a6 [h:\mozilla\tree-main\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp @ 1418] 0013e73c 002b3fc6 firefox!nsXPCWrappedJS::CallMethod(unsigned short methodIndex = 0xf080, class nsXPTMethodInfo * info = 0x00000003, struct nsXPTCMiniVariant * params = 0x0013e81c)+0x27 [h:\mozilla\tree-main\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp @ 478] 0013e7f4 002b403b xpcom_core!PrepareAndDispatch(class nsXPTCStubBase * self = 0x0237f080, unsigned int methodIndex = 3, unsigned int * args = 0x0013e81c, unsigned int * stackBytesToPop = 0x0013e80c)+0xf9 [h:\mozilla\tree-main\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 117] 0013e810 0057f957 xpcom_core!SharedStub(void)+0x16 [h:\mozilla\tree-main\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 147] 0013e874 01ed86f4 firefox!nsEventListenerManager::HandleEventSubType(struct nsListenerStruct * aListenerStruct = 0x00000000, class nsIDOMEventListener * aListener = 0x002ca730, class nsIDOMEvent * aDOMEvent = 0x0013e898, class nsISupports * aCurrentTarget = 0x0000000c, unsigned int aPhaseFlags = 0x10011)+0x12d [h:\mozilla\tree-main\mozilla\content\events\src\nseventlistenermanager.cpp @ 1295] WARNING: Frame IP not in any known module. Following frames may be wrong. 0013e8c4 006bdc06 0x1ed86f4 0013e8e0 00a5f028 firefox!nsDOMUIEvent::QueryInterface(struct nsID * aIID = 0x0013ea94, void ** aInstancePtr = 0x01f26c58)+0x94 [h:\mozilla\tree-main\mozilla\content\events\src\nsdomuievent.cpp @ 114] 0013e8f4 0028335f firefox!`nsIDOMEventListener::GetIID'::`2'::iid Does that look good? Also I see the "Invalid Address specified to RtlFreeHeap" message a lot with another problem I have been having. What does it mean? Wildmyron
OS: Windows XP → Windows Vista
stack looks fine, thanks. rtl=runtime library heap=memory pool that can be dynamically grown by allocations (classically 'malloc', c++ 'new'). in order for things to work eventually you're supposed to release that memory with the matched deallocator system. things get bad when you pass incorrect pointers to the deallocate functions, because then they can't do the right thing. which would be about what the message meant. google probably has a better explanation floating around. can you please meticulously record the steps to use mcsmurf's build with a new profile, install whichever *one* extension it was (include links for everything, you're being meticulous...), and the steps leading to your crash? hopefully we can get someone to figure out what's going on.
Assignee: nobody → dbradley
Component: Extension Compatibility → XPConnect
Product: Firefox → Core
QA Contact: extension.compatibility → xpconnect
Thank you for the explanation The version of Free Download Manager available at http://www.freedownloadmanager.org/download.htm is the version causing the crash. The extension is bundled with the application installer and automatically installed into all Firefox profiles. The application does not need to be run for the crash to occur, nor even to be installed. In case FDM is updated (or installing the app is undesirable) I have packaged the extension separately. This does not appear to be prohibited by the license, but just in case it is I won't attach it here. It is available at http://www.iinet.net.au/~myron/fdm_ffext-2.1.xpi Steps to reproduce with mcsmurf's debug build 1. Fetch build from http://www.mcsmurf.de/mozilla/firefox-trunk-20061010.zip Symbols are available from http://www.mcsmurf.de/mozilla/ff-symbols/ 2. Unzip build. 3. Create a clean profile. 4. Install Free Download Manager OR start firefox and install the extension. 5. (Re)start firefox. 6. Right click anywhere in the browser window. Wildmyron
The extension in question includes a binary (components/component.dll) and claims: <em:minVersion>1.5</em:minVersion> <em:maxVersion>3.0</em:maxVersion> Now it's possible that it actually is compatible with trunk, if it's _very_ careful about which interfaces it uses. But if it's compiled against the 1.8 Gecko branch and uses any unfrozen interfaces that have changed on trunk, crashes can happen... Also, since it's using native code it can in fact have its own allocator/deallocator bugs that are not under our control. Have you contacted the authors of this extension about this problem? And does it only happen with trunk? Or also with Firefox 2?
Assignee: dbradley → nobody
i had tested it on firefox 2.0 (20061010) and apparently, the problem only occur on trunk. yes i tried to email them (FDM group) before but i haven't got any response. i tried it again today and this time i gave them the link to this bugzilla.
i cant get positive response from fdm development team http://www.freedownloadmanager.org/board/viewtopic.php?t=3681
Summary: right click on any page will crash firefox → right click on any page will crash firefox with free download manager extension
it would be possible to trace calls into and out of that library, although i don't know of any "simple" ways to do it. The elegant way is for someone(maybe me - but probably not) to write a wrapper which would enable this to be done automatically - basically the wrapper would live in components and be assigned to proxy an initial call to NSGetModule to a specified foreign component. It would wrap the result of its call to NSGetModule and return the wrapper to xpcom. It would autowrap every object it passes in/out of the untrusted module relying heavily on xptcall and just logging all calls w/ arguments, possibly in one mode just logging nsISupports.QueryInterface. Until that happens, you just get to use breakpoints. The first breakpoint is: component!NSGetModule that should give you a module creature, from there you basically walk up to the thing that grabs the nsIModule. when you get the nsIModule, you'd check the vtable cast the nsIModule* to xpcom_core!nsIModule* or firefox!nsIModule* using the view>locals window. from there you should see an address for the nsIModule::GetClassObject, you'd set a breakpoint on this. continue until you hit it. step out. you should be in nsFactoryEntry::GetFactory (you can breakpoint here actually, but you want to set breakpoints just in time, otherwise you'll be very annoyed, although you can disable breakpoints...). That gives you an nsIFactory. most likely you're called from nsComponentManagerImpl::CreateInstance, set a breakpoint into the component's impl of nsIFactory::CreateInstance (so that you can trap each time an object is created in this module). with the object returned by CreateInstance, cast aResult to firefox!nsISupports** in locals, again follow the vpointer, this time set a breakpoint in that object's QueryInterface function (actually, you want to set breakpoints in *all* of that object's methods) at this point you should be taking notes (actually, windbg has a way to log all actions you take, you probably want to do that), specifically you're going to want to step through each function in this object. basically you set breakpoints at every jmp, jle, jne, and call. once you've decided that a function is clean, clear the breakpoints and make a note that you've decided it isn't interesting. an interesting function is any function/path that lands back into mozilla. whenever you land there, you'll want to check the name of the function that it shows you're in, and also make sure that it's the beginning of a function. step a bit in this function and see if the arguments seem valid (judgement call, at the very least make a note of which objects are being called and their arguments, you can list them here and we can take guesses). note that this howto analyze a black box xpcom component comment is not just for your sake, until someone wikifies it, i expect to point others to this bug. from this gecko function you can now step out back into the untrusted code. and resume continuing/stopping at breakpoints on jmp/jle/jne/call and clearing breakpoints as you investigate them. Probably the most useful thing for you to do wrt investigating calls from the foreign object to gecko are: 1. getting all calls to any_gecko_module!any_gecko_object::QueryInterface, specifically logging the nsIID structure (it's 128 bits). 2. recording the last couple of function call transitions and stacks between the foreign module and gecko before gecko crashes you'll probably want an asm reference, the one i use <http://viper.haque.net/~timeless/bookmarks.html> is to http://google.com/search?q=site%3Awebster.cs.ucr.edu+%S with a bookmark keyword of 'asm'. so i just type |asm jmp| into the urlbar.
I've spent some time on this (most of it learning about windbg, assembly and a little on how xpcom works) and I feel I'm in the position to ask some meaningful questions now. I haven't made a lot of progress with determining the clean/interesting functions yet but I was able to follow most of the instructions. I have some comments on your HOWTO, some questions and links to more detailed notes. --- Comments on the HOWTO: 1) The interesting part of the stack (after component!NSGetModule returns) looks like: xpcom_core!nsNativeModuleLoader::LoadModule xpcom_core!nsFactoryEntry::GetFactory+0x133 xpcom_core!nsComponentManagerImpl::CreateInstance+0x4a firefox!nsJSCID::CreateInstance+0x1b8 xpcom_core!XPTC_InvokeByIndex+0x27 firefox!AutoJSSuspendRequest::SuspendRequest+0x1a 2) I had no idea how to find the address for nsIModule::GetClassObject (see points 5&6) but I just stepped out to nsFactoryEntry::GetFactory after examining the nsIModule. Did I miss something important? 3) The nsIModule and nsIFactory objects are already cast as class nsCOMPtr<nsIModule> and class nsCOMPtr<nsIFactory> so they don't seem to need to be cast. 4) The pointers to them are cast as class nsIModule* and class nsIFactory* so that seems OK too. 5) What is a problem is they have the following form (nsIModule, for example): aResult (class nsIModule **) |- * (class nsIModule *) |- nsISupports (class nsISupports) |- __vfptr 0x7324 (__fptr [3]) (pointer to a function table in component) |- [0] 0x5be2 component!NSGetModule+0x4822 (__fptr) |- [1] 0x5ba0 component!NSGetModule+0x47e0 (__fptr) |- [2] 0x5bb2 component!NSGetModule+0x47f2 (__fptr) So these addresses are interesting, but the next entry in the component's function table is (in this example) 0x5dfa component!NSGetModule+0x4a3a They seem to be grouped and I believe there are seven in this group. I know that this function (and I'm guessing the others as well) is called from nsFactoryEntry::GetFactory. So why don't they appear in the table in view->locals? 6) I tried looking at the source to see how these objects are defined but I can't work out which of the component's functions implement which method. I'm pretty sure the second is Object::AddRef and the third is Object::Release (that's what they seem to do) but I can't work out the other five 7) Quote: "with the object returned by CreateInstance, cast aResult to firefox!nsISupports** in locals" What I think this should say is that aResult is the object that will _be_ returned by CreateInstance. It should be cast before CreateInstance returns. This object needed to be cast to firefox!nsISupports* to show pointers to sensible function addresses. --- Questions: Am I going in the right direction? If nothing else I'm learning a lot so it doesn't bother me too much if I can't really achieve anything. Specifically, I need some help interpreting the data structures as presented by the debugger and relating them to the class definitions in the source. For example, looking at the nsIModule object, which methods does the object need to implement and can it implement others. Is that what ::QueryInterface is supposed to define? I couldn't find a definition for the class nsIModule. OK, having said that I just looked at lxr.mozilla.org again and things are becoming clearer. nsIModule.idl defines four functions that must be implemented and nsISupports.idl defines three. This corresponds to the group of seven functions in the function table. I still don't understand why pointers to them don't appear in view->locals. I'll stop here. I appreciate any information you can point me at that will clarify what's going on. --- I've made my notes available in case anyone else is interested: http://members.iinet.com.au/~myron/fdm_analysis.log http://members.iinet.com.au/~myron/fdm_functions.log
*** Bug 363744 has been marked as a duplicate of this bug. ***
As far as I'm concerned FDM is compatible with all versions, except for Gran Paradiso
Wait a moment! OS: Windows Vista This bug affects -all- windows versions...
bugzilla doesn't have a provision for saying "all windows", in general it's best if the os matches the oldest version of a platform with a problem. so far all crashes in this bug say vista. can you crash firefox this way using windows 3.1? that would be part of all windows. what about windows 95? (note that firefox doesn't run there anymore either...) Don't say all, if you have crash evidence for other versions, indicate it.
talkback from dup bug# 363744 ( TB27284515X ) says Windows NT 5.1 build 2600
OS: Windows Vista → Windows XP
ok then, would it be okay to say instead... all *supported* versions
no. first, you're spamming this bug. second there's no provision in Bugzilla to say all supported versions of X either (not that it makes sense). third, you should have been able to figure out all of this without asking any questions in bugzilla, but if you really need help understanding how to use bugzilla, please try a forum or irc channel. ============================================================================== A while ago I provided some other bits out of band, I'm including them now because they belong here. > Why are only pointers to the nsISupports methods listed in view locals? I don't know, http://groups-beta.google.com/group/microsoft.public.windbg/browse_frm/thread/b84f4564b1b3d09f/e530d9552d93eabf?hl=en#e530d9552d93eabf the answer we got from the owner of that code wasn't really satisfactory :(, and it doesn't look like they took the request as an RFE :(. That said, use dt -v {objectname} in the command area [view>command], it should work. (I tested using the nsThread object which is always available in a running firefox's stack because it's part of the event loop.) > Matching up function names in the idl files with the actual > functions is confusing. The general rules for this are: 1. lines in idl interfaces will appear in order in a class's vtable format. 2. if it's a method, that's 1 entry 3. if it's a readonly attribute, that's 1 entry 4. if it's just an attribute, that's 2 entries *this is important!* 5. for the general mangling of interfaces (which is covered all over the place) please see <http://groups.google.com/group/mozilla.dev.security/browse_frm/thread/42438eff1abb83e/6ea2ceeaecf7a1ce?lnk=gst&q=timeless&rnum=1#6ea2ceeaecf7a1ce>. 6. if a method says [notxpcom] then its mangling is *different*. 7. things guarded by "{%C++ " are going to be part of the C++ class definition if they're in the interface (this is obviously going to result in an unhappy JS mapping, and anyone running the xpidl compiler will be scolded about them) and will influence the vtable/class layout exactly as it would (and i can't say more because it is obviously entirely dependent on whatever content is in that block). (additional information that's less relevant, but was included in what I wrote when I wrote it:) A. If a method says [noscript] or [notxpcom], then it won't appear in js and won't be callable from js. B. [arguably a bug] even if a method in a scriptable interface is neither notxpcom nor noscript, but it takes or returns an object that isn't a scriptable interface, then you can't today call or see that method from js (I have a patch somewhere that allows js code to call these methods as long as the methods aren't explicitly noscript/notxpcom). ============================================================================== It occurs to me, that if we had a debug version of mozilla/firefox (and mcsmurf might have one of those on his server), we might be able to do something fairly evil and basically pass the object that's misbehaving to js and just interrogate it there. also, in looking back, it doesn't appear that I commented on this line from comment 9: WARNING: Frame IP not in any known module. Following frames may be wrong. 0013e8c4 006bdc06 0x1ed86f4 That's presumably part of the component we're worried about.... Some other thoughts, from frames like this: XPCWrappedNative::CallMethod you can (with debug builds) do this with windbg: .call DumpJSStack; g I've actually started looking into some of the related bits for this. specifically I'm fairly close to extending impersonator so that it could handle this abstraction stuff (assuming the evil code in question is restricted to scriptable apis). I think I'll finish off documenting impersonator and go home. Maybe next week I can try to adapt impersonator to the scope here. the steps are basically: * Ask the component manager for a list of files * pick from the list of files the interesting ones * ask the component manager for the list of classids implemented by that file list * impersonate the component manager * for each classid, get the classfactory from the component manager * impersonate each classfactory and register the replacements (For session only) with the component manager * whenever the impersonated object is called with objects, impersonate them too. I'm not sure if i'll be able to get away with this, if i can't, I might need to add a c++ component which exposes NSGetModule(). anyway, if i can get impersonator to work here, i can add the logging i need to find out what interfaces are being used. an alternative would be to try to get xpconnect's wrapping code to do the logging, but to do that, you'd want a lot of logic to limit the logging to the relevant module (perhaps this could be done by having xpcom taint all created objects with xpconnect markers, but i think by the time you've done that, i can hook up impersonator....
If you have a problem understanding INFERRED language, please tell me. Otherwise please be quiet. Why would all versions refer to 3.1, 95 etc if it is NOT SUPPORTED IN THE FIRST PLACE? You have pointed out it in the first place, so why not understand that it was inferred? Anyone with an IQ over 50 can figure it out... And why would someone try to install FDM on Wine and see if it would work with a *nix version of Gran Paradiso? It's just a stupid reply, and absoloutely pointless. The same goes for DarWine on OSX. In case you reply saying "but what if someone decides to install the Win32 version of Gran Paradiso?" I can tell you WineHQ App DB says it performs below average. ------------------------ It appears that after a reinstall of Gran Paradiso (I had uninstalled Gran Paradiso and used 2.0.0.1) the right click works, and I can confirm that the FDM plugin was installed as "Download all with Free Download Manager" appears in the context menu. However after a restart of Gran Paradiso the right click will cause to FDM to crash. Obviously therefore it could be possible to avoid this problem by uninstalling and reinstalling Gran Paradiso after each use, however it would be very time-consuming and annoying.
free download manager version 2.5 build 713 is out, and still, extension still crashing minefield. :(
Does stackwanted really apply to this bug still? If so, I can probably provide one.
This is not a bug in Firefox. This is a bug in a binary component in the free download manager Firefox extension. Specifically it's a bug on line 68 here: http://freedownload.svn.sourceforge.net/viewvc/freedownload/FDM/Firefox/XPCOM%20Component/FDMForFirefox.cpp?revision=7&view=markup That code does: NS_IMETHODIMP CFDMForFirefox::GetLngString(const char *strIDString, PRUnichar **_retval) { *_retval = new wchar_t [1000]; and that's a violation of the XPCOM rules that state that you need to use malloc() (or nsMemory::Alloc(), really) when passing back data to the caller of an XPCOM method. This will result in an allocator mismatch, which on Win32 often (always?) leads to crashes. IOW we crash after having called that method when we call free() on the pointer we got back from the above method. Anyone here in touch with the free download manager extension developer(s)? Or anyone set up to file a bug on http://sourceforge.net/projects/freedownload about this? Marking this bug INVALID as this is not a problem in our source code.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → INVALID
i emailed them before and posted the problem on their forum but i haven't got a positive response. this time i filed new bug at their sourceforge site: http://sourceforge.net/tracker/index.php?func=detail&aid=1836315&group_id=201856&atid=979232
can we file new bug requesting extension blocking for free download manager (ver 1.3 extension) similar to what we had done to older version of internet download manager? see: https://bugzilla.mozilla.org/show_bug.cgi?id=382356#c27
jst wrote in comment 32 a mention of plain malloc, but that's not legal on windows at all, as each dll has its own unrelated malloc, it must be nsMemory or NS_Alloc.
Alias: fdmcrash
i filed bug 408445 for blocklisting of this extension.
version 1.3.1 of this extension no longer crashes firefox 3.0.
Whiteboard: FIXED by free download manager extension version 1.3.1
This bug is still causing Firefox to crash on right-click. I'm glad I found this bug which told me what the culprit was. I've disabled FDM addon and now can use right click again. Since you know there is a problem, it sure would be nice to block FDM programatically until it is fixed.
Please update to the latest version of FDM. see comment 43 - this crash is fixed.
(In reply to comment #45) > This bug is still causing Firefox to crash on right-click. I'm glad I found > this bug which told me what the culprit was. I've disabled FDM addon and now > can use right click again. if you already installed fdm extension version 1.3.1 and still crashing, you might be hitting bug 416521.
Whiteboard: FIXED by free download manager extension version 1.3.1
The latest version of the FDM extension claims to be compatible with Firefox version "3.*". That's pretty awful. It didn't actually crash my browser on right-click, but I didn't test anything else.
(In reply to comment #52) hmmm...? would it be fdm dev team fixed their extension without bumping fdm extension version? latest fdm version 2.5 build 755 still had fdm extension version 1.3.1.
FDM's plugin crashes Firefox 3 when you right click for me too. Disable the extension (so it won't keep reinstalling it) and use FlashGot instead, which supports FDM.
I suppose I should have read the thread more carefully before replying, some people are saying the crash is fixed, and I forgot to mention I had problems with an older FDM extension and disabled it long ago. I would still recommend using FlashGot over the FDM extension.
You need to log in before you can comment on or make changes to this bug.