Closed Bug 564008 Opened 14 years ago Closed 8 years ago

Crash in [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] [@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]

Categories

(Core :: XPCOM, defect)

x86
Windows Vista
defect
Not set
critical

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
Version: unspecified → Trunk
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&) ]
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.
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.
seems this is our number 1 topcrash on beta 1 now
blocking2.0: --- → ?
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
Just sent a message to the devs.
See also bug 382356 for a similar situation with the same add-on on 3.6.
Depends on: 578443
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
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.
(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.
(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.
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.
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.
(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.
(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?
(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
blocking2.0: ? → betaN+
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.)
Assignee: general → nobody
Component: JavaScript Engine → General
QA Contact: general → general
This is #244 for the trunk and #210 for beta7 - past 7 days.
Keywords: topcrash
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.
blocking2.0: betaN+ → -
bp-05ecf7b2-0f9b-4a56-8eec-b45ab2101216 same stack ....
nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>() | nsPurpleBuffer::SelectPointers(GCGraphBuilder&)
Crash Signature: [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] [@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ]
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&) ]
Blocks: 512486
Component: General → XPCOM
Crash Signature: [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] [@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] → [@ nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] [@ @0x0 | nsPurpleBuffer::SelectPointers(GCGraphBuilder&) ] [@ nsPurpleBuffer::SelectPointers ] [@ @0x0 | nsPurpleBuffer::SelectPointers ]
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.