Closed
Bug 564008
Opened 14 years ago
Closed 8 years ago
Crash in [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] [@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: marcia, Unassigned)
References
Details
(Keywords: crash, testcase-wanted)
Crash Data
Seen while running Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100505 Minefield/3.7a5pre ( .NET CLR 3.5.30729). Not sure whether this is XPCOM or JS so filing in JS For now. My reports are here: *https://crash-stats.mozilla.com/report/index/bp-d920b950-1cdd-4d9b-b08a-1371b2100505 *https://crash-stats.mozilla.com/report/index/bp-78a9a068-5373-44a4-9900-5d21d2100505 STR: 1. Load c3dl/c3dl-dev/J3D EXplorer/J3D EXplorer.html in the URL bar. Sometimes I crash right away, and other times the browser just crashes randomly Happens frequently on this machine with this configuration. Extensions: RealPlayer Browser Record Plugin1.0false{ABDE892B-13A8-4d1b-88E6-365A6E755758} Microsoft .NET Framework Assistant1.2.1true{20a82645-c095-46ed-80e3-08825760534b} VerificationEngine®2.7.0.33false{A6EA7921-6EAD-4874-9464-90D91462A375}Grafx Bot0.1.0002truegrafxbot@mozilla.org Adblock Plus1.2true{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} IDM CC6.9.7truemozilla_cc@internetdownloadmanager.com Frame Module Signature [Expand] Source 0 @0x0 1 xul.dll nsPurpleBuffer::SelectPointers xpcom/base/nsCycleCollector.cpp:913 2 xul.dll nsCycleCollector::BeginCollection xpcom/base/nsCycleCollector.cpp:2608 3 xul.dll XPCCycleCollectGCCallback js/src/xpconnect/src/nsXPConnect.cpp:400 4 mozjs.dll GC js/src/jsgc.cpp:3013 5 mozjs.dll GCUntilDone js/src/jsgc.cpp:3182 6 mozjs.dll js_GC js/src/jsgc.cpp:3512 7 mozjs.dll JS_GC js/src/jsapi.cpp:2294 8 xul.dll nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:487 9 xul.dll nsCycleCollector::Collect
Reporter | ||
Updated•14 years ago
|
Version: unspecified → Trunk
Reporter | ||
Comment 1•14 years ago
|
||
Happening frequently today using Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100507 Minefield/3.7a5pre. Some of the things that happened right before I crashed: *I was opening a new tab *I cut and pasted some text into the Search bar, hit enter and then it crashed. *I completed a bugzilla query and it crashed. This appears to be the top crash on the trunk so adding the appropriate keyword. http://tinyurl.com/2fzynnu is the link to all the current trunk crashes.
Keywords: topcrash
Summary: Crash in [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] → Crash in [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] [@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
Reporter | ||
Comment 2•14 years ago
|
||
Beginning to wonder if this has something to down with installing Internet Download Manager - http://www.internetdownloadmanager.com/. Will try uninstalling it again to see if the crashes go away.
Reporter | ||
Comment 3•14 years ago
|
||
Crash on a different machine, also happens to have Internet Download Manager installed. jst suggests trying to get this in record and play. https://crash-stats.mozilla.com/report/index/bp-4ed922b3-21cb-46a2-ac2f-d3f032100507 is the report on the Win 7 machine.
Comment 5•14 years ago
|
||
jorge, this is the #1 top crash for 4.0b1 and by 4x over the second top crash. we should also try some outreach the Internet download manager folks if we have a contact. IDM .dll's are around 100% of the time. 101% (139/138) vs. 50% (9040/17949) idmmkb.dll 100% (2407/2411) vs. 50% (8971/17949) idmmzcc.dll 100% (2405/2411) vs. 50% (9040/17949) idmmkb.dll 100% (138/138) vs. 50% (8971/17949) idmmzcc.dll
Comment 6•14 years ago
|
||
Just sent a message to the devs.
Comment 7•14 years ago
|
||
See also bug 382356 for a similar situation with the same add-on on 3.6.
Comment 8•14 years ago
|
||
Hi, It seems to be a problem with nsISelection interface. Note that the description of the interface clearly states that it’s FROZEN! In former versions of Firefox the following code worked without a problem: nsCOMPtr<nsISelection> selection; rv = mWindow->GetSelection(getter_AddRefs(selection)); ................................................. PRUnichar* szText; rv = selection->ToString(&szText); if (NS_SUCCEEDED(rv)) { ..................... using szText nsMemory::Free(szText); } But now selection->ToString(&szText) returns 0, that means NS_SUCCEEDED(rv) true, BUT szText is not filled with data. We have resolved the problem by adding the following changes: PRUnichar* szText = NULL; rv = selection->ToString(&szText); if (NS_SUCCEEDED(rv) && szText) { ..................... using szText nsMemory::Free(szText); } please check nsISelection implementation and fix it if possible. Regards Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
Comment 9•14 years ago
|
||
Do you have a testcase for that? Looking at the code I don't see how this can happen except with OOM. With what version did the regression appear? None of this code seems to have changed in a long time.
Comment 10•14 years ago
|
||
(In reply to comment #9) Try to debug Firefox 4.01b with our extension where we have fixed the bug http://www.internetdownloadmanager.com/idmmzcc/idmmzcc.xpi and compare to old version from IDM distribution file: http://www.internetdownloadmanager.com/idman519.exe When you select a text with mouse, the extension will call nsISelection::ToString() Try to see nsISelection implementation what Firefox returns in this string. The selection really exists visually on the screen, but the selection string is not returned/assigned.
Comment 11•14 years ago
|
||
(In reply to comment #10) > and compare to old version from IDM distribution file: I wanted to clarify what I wrote above… You can debug Firefox 4.01b with any extension that calls nsISelection::ToString() method. For example you can debug with our extension where we have fixed the bug: http://www.internetdownloadmanager.com/idmmzcc/idmmzcc.xpi Or you can debug with the previous extension which is inside IDM distribution file: http://www.internetdownloadmanager.com/idman519.exe nsISelection::ToString() is called in both extensions, but the new version version will not crash since it has a workaround for your bug. When you select a text with mouse, the extension will call nsISelection::ToString() Try to see nsISelection implementation what Firefox returns in this string. The selection really exists visually on the screen, but the selection string is not returned/assigned. If you can fix it, the old version of our extension (millions of customers) will not crash new Firefox anymore.
Comment 12•14 years ago
|
||
Please note that this crash is not our fault. There is no mention that ToString method may not assign return value even if NS_SUCCEEDED(rv) returns true. Look here: http://www.mozilla.org/projects/embedding/embedapiref/embedapi74.html It says: ToString returns the whole selection into a plain text string. Syntax: wstring nsISelection::toString() Parameters: None. nsresult: NS_OK if successful Also I looked at idl and h files descriptions: /** * Returns the whole selection into a plain text string. */ wstring toString(); /** * Returns the whole selection into a plain text string. */ /* wstring toString (); */ NS_SCRIPTABLE NS_IMETHOD ToString(PRUnichar **_retval NS_OUTPARAM) = 0; There is no mention here either. Thus formally it's a bug of Firefox. Regards Charles Tonec Inc.
Comment 13•14 years ago
|
||
I'm really tired to write to Firefox forums that 1. IDM CC 6.9.9 has a workaround and Firefox 3.7 and 4.0 DO NOT crash anymore with this version of extension 2. The reason of crash is FIREFOX BUG inside nsISeletion::ToString() implementation! Please FIX your bug instead of blacklisting! Best regards, Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
(In reply to comment #12) > Please note that this crash is not our fault. There is no mention that ToString > method may not assign return value even if NS_SUCCEEDED(rv) returns true. It appears that it is assigning a value, and the value is NULL. > Syntax: > wstring nsISelection::toString() > Parameters: > None. > > nsresult: > NS_OK if successful NULL is a legal value for wstring. > Thus formally it's a bug of Firefox. I think you're mistaken: wstrings can be NULL, and code that deals with |wstring|s or |string|s has to handle them appropriately.
Comment 15•14 years ago
|
||
(In reply to comment #13) > I'm really tired to write to Firefox forums that This bug is about a specific crash. Even if there were a problem with nsISelection::ToString (but see bug 578443 comment 11), this bug is most likely not about a crash caused by that problem. We are seeing reports from multiple different crash signatures related to IDM (again, see bug 578443). Please stop posting to this bug unless you have clear evidence that the crash in nsPurpleBuffer::SelectPointers is caused by nsISelection::ToString, or if you have info about this specific crash.
Comment 16•14 years ago
|
||
(In reply to comment #14) > I think you're mistaken: wstrings can be NULL, and code that deals with > |wstring|s or |string|s has to handle them appropriately. I do not say that wstrings cannot be NULL. The problem is that when there is a selection on a page, nsISelection::ToString returns NS_OK, but it does not return any text. It worked fine in Firefox 3.6. If we assign any other value for example 1234 (see below), this method returns 1234, so we deal with complete non-assignment of return variable with NS_SUCCEEDED/NS_OK, rather than NULL assignment. PRUnichar* szText = (PRUnichar*)0x00001234; rv = selection->ToString(&szText); In result we get rv == NS_OK but szText still points to 0x00001234 Note that the selection on a page visually exists and has some text. The problem started from Firefox 3.7 (link below) and still persists in 4.01 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/06/2010-06-02-04-mozilla-central/ I have just verified it in debugger, and double checked it. Can somebody help me to file a bug?
Comment 17•14 years ago
|
||
(In reply to comment #15) > (In reply to comment #13) > > I'm really tired to write to Firefox forums that > This bug is about a specific crash. Even if there were a problem with > nsISelection::ToString (but see bug 578443 comment 11), this bug is most likely > not about a crash caused by that problem. We are seeing reports from multiple > different crash signatures related to IDM (again, see bug 578443). Please stop > posting to this bug unless you have clear evidence that the crash in > nsPurpleBuffer::SelectPointers is caused by nsISelection::ToString, or if you > have info about this specific crash. I already wrote to another thread that the crash happened because of it. When a user clicks on a link with left mouse button and move mouse a little, it starts a small selection. It happens frequently on links with several lines. We were able to repeat the same crash, and when we made the changes above, the crash disappeared. PRUnichar*szText was initialized with a wrong old address and nsMemory::Free(szText) freed a wrong memory block. Several users already upgraded IDM CC to 6.9.9. Do you have any crash statistics for this version?
There's also continuing discussion of this in bug 578443. My guess as to why you're seeing the behavior you describe with nsISelection is that the nsISelection interface has changed; there's a new method that was added, and the interface is no longer frozen. So if you're assuming the nsISelection interface is still as it was in older versions, then you'd be calling the method: void selectionLanguageChange(in boolean langRTL); instead of: wstring toString(); so the variable you're expecting to be a PRUnichar** is actually a PRBool. If that's the cause of your problem, this is not a Gecko bug; interfaces have been unfrozen for Gecko 2.0.
(In reply to comment #17) > (In reply to comment #15) > nsMemory::Free(szText) freed a wrong memory block. Several users already > upgraded IDM CC to 6.9.9. Do you have any crash statistics for this version? We didn't get any crashes for that version yesterday; we'll see what happens today. (No crashes at all from users with that version means that users haven't really upgraded to it yet, since we'd expect the users to see other crashes) Yesterday's 4.0b1 data for this crash suggest the crash was caused by IDM versions 5.9 through 6.9.8, but not 5.5-5.8: nsPurpleBuffer::SelectPointers(GCGraphBuilder&)|EXCEPTION_ACCESS_VIOLATION (2676 crashes) 100% (2665/2676) vs. 51% (9832/19168) mozilla_cc@internetdownloadmanager.com (IDM CC, https://addons.mozilla.org/addon/6973) 0% (1/2676) vs. 0% (2/19168) 5.10 0% (5/2676) vs. 0% (31/19168) 5.11 0% (0/2676) vs. 0% (2/19168) 5.5 0% (0/2676) vs. 0% (15/19168) 5.7 0% (0/2676) vs. 0% (48/19168) 5.8 0% (8/2676) vs. 0% (33/19168) 5.9 0% (10/2676) vs. 1% (108/19168) 6.1 1% (32/2676) vs. 1% (167/19168) 6.3 3% (86/2676) vs. 2% (371/19168) 6.4 1% (40/2676) vs. 1% (210/19168) 6.5 7% (184/2676) vs. 5% (996/19168) 6.7 0% (11/2676) vs. 1% (104/19168) 6.8 1% (18/2676) vs. 0% (76/19168) 6.8.2 3% (90/2676) vs. 3% (502/19168) 6.9.1 46% (1229/2676) vs. 21% (3986/19168) 6.9.7 36% (951/2676) vs. 17% (3181/19168) 6.9.8 That's a quote from: http://people.mozilla.com/crash_analysis/20100721/20100721_Firefox_4.0b1-interesting-addons-with-versions.txt
Updated•14 years ago
|
blocking2.0: ? → betaN+
Comment 20•14 years ago
|
||
Following the STR in https://bugzilla.mozilla.org/show_bug.cgi?id=597849#c5 I crashed here: http://crash-stats.mozilla.com/report/index/bp-43c808f3-fb28-43dc-ad17-cac172101011 Win32 20101011 trunk, no addons installed. (I got a variety of different stacks for those STR, but this was one of them.)
Updated•14 years ago
|
Assignee: general → nobody
Component: JavaScript Engine → General
QA Contact: general → general
Comment 23•14 years ago
|
||
This is #244 for the trunk and #210 for beta7 - past 7 days.
Comment 24•14 years ago
|
||
Now #133 on b8pre. This clearly hasn't been fixed by bug 600974, and the recent signatures don't involve IDM, so something else is left over here.
Updated•14 years ago
|
blocking2.0: betaN+ → -
Updated•14 years ago
|
Keywords: testcase-wanted
Comment 25•13 years ago
|
||
bp-05ecf7b2-0f9b-4a56-8eec-b45ab2101216 same stack .... nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>() | nsPurpleBuffer::SelectPointers(GCGraphBuilder&)
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
[@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
Comment 26•12 years ago
|
||
I couldn't find a testcase page. does the testcase still exist somewhere? There are a few crashes in 15.0.x and later versions. for example bp-00905c79-c61b-46c2-a06a-f93dd2121006 firefox 18 bp-9319673c-c2d6-4208-9efa-85b002120923 firefox 18 bp-27fef81c-1268-4311-abb2-941fa2120919 15.0.1
Crash Signature: [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
[@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] → [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
[@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
Updated•9 years ago
|
Component: General → XPCOM
Updated•9 years ago
|
Crash Signature: [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
[@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] → [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
[@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
[@ nsPurpleBuffer::SelectPointers ]
[@ @0x0 | nsPurpleBuffer::SelectPointers ]
Comment 27•8 years ago
|
||
zero examples with nsPurpleBuffer::SelectPointer in signature in the past week for any current version
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•