110076 - Access violation in Trunk M100 N70PR1 [@ imgContainer::StartAnimation]

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect, P2)

Description

[David Bradley]

This occured because the do_CreateInstance("@mozilla.org/timer;1") apparently
returned 0 at line 312 of imgContainer.cpp . This occured during shutdown, I
suspect there's a bigger problem as to why something is starting animation on
shutdown.

Unfortunatley I don't know the specific web page this occured on or how to
reproduce it. I was running the browser buster and just shut things down. There
are talkbacks with similar stacks as well: 37999898, 37998980, 37994873, 37991524.

Probably should test the mTimer after do_CreateInstance and not call Init if null.

Comment 1

[David Bradley]

Attachment: Stack trace of the crash on my system

Comment 2

[Jan Carpenter]

This is a topcrash in N621.  Changed the subject line to N621 [@
imgContainer::StartAnimation] for tracking.  Added topcrash keyword.

Here is the current crash information:

Min/Max Seconds since last crash: 85 - 23513
Min/Max Runtime: 85 - 23513
Crash data range: 2001-12-07 to 2001-12-10
Build ID range: 2001112815 to 2001112815
Stack Trace: 

	 imgContainer::StartAnimation
[c:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp  line 307]
	 imgContainer::EndFrameDecode
[c:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp  line 237]
	 EndImageFrame
[c:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp 
line 353]
	 gif_write
[c:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\GIF2.cpp  line 1502]
	 nsGIFDecoder2::ProcessData
[c:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp 
line 208]
	 ReadDataOut
[c:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp 
line 156]
	 nsInputStreamTee::WriteSegmentFun
[c:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp  line 82]
	 nsInputStreamTee::ReadSegments
[c:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp  line 138]
	 nsGIFDecoder2::WriteFrom
[c:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp 
line 229]
	 imgRequest::OnDataAvailable
[c:\builds\seamonkey\mozilla\modules\libpr0n\src\imgRequest.cpp  line 795]
	 ProxyListener::OnDataAvailable
[c:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp  line 466]
	 nsStreamListenerTee::OnDataAvailable
[c:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp  line 57]
	 nsHttpChannel::OnDataAvailable
[c:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 2226]
	 nsOnDataAvailableEvent::HandleEvent
[c:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp  line 188]
	 PL_HandleEvent
[c:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 591]
	 PL_ProcessPendingEvents
[c:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 524]
	 nsEventQueueImpl::ProcessPendingEvents
[c:\builds\seamonkey\mozilla\xpcom\threads\nsEventQueue.cpp  line 375]
 
 	Source File : c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgContainer.cpp
line : 307


COMMENTS/URLs:

     (259723)	Comments: i was surfing the net and the "back" and "forward" buttons stopped
working. they still dont work
     (250291)	Comments: LOGGING ON
     (247090)	Comments: I was surfing the net and recieved an error message
     (189219)	Comments: trying to access e-cards

Comment 3

[Terri Preston]

[e-mail], is this still a top crasher?

Comment 4

[Jay Patel [:jay]]

There haven't been too many incidents since N621, but I do see a few incidents
with M097 and M098....as well as a couple of recent crashes on the MozillaTrunk. 

Here's the most recent crash on the Trunk:
 Incident ID 2735793   Stack Signature  imgContainer::StartAnimation d2dd3d25
Trigger Time 2002-02-10 02:59:43
Email Address
URL visited www.another.com
Build ID 2002020610
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments
Stack Trace
imgContainer::StartAnimation
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 319]
imgContainer::EndFrameDecode
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 228]
EndImageFrame
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 315]
gif_write [d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\GIF2.cpp,
line 1401]
nsGIFDecoder2::ProcessData
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 205]
ReadDataOut
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 150]
nsInputStreamTee::WriteSegmentFun
[d:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp, line 97] 

Here's the most recent incident with M098:
 Incident ID 2807701   Stack Signature  imgContainer::StartAnimation 87525fbd
Trigger Time 2002-02-11 21:12:23
Email Address
URL visited
Build ID 2002020409
Product ID MozillaBranch
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments
Stack Trace
imgContainer::StartAnimation
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 319]
imgContainer::EndFrameDecode
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 228]
EndImageFrame
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 314]
gif_write [d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\GIF2.cpp,
line 1678]
nsGIFDecoder2::ProcessData
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 202]
ReadDataOut
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 150]
nsInputStreamTee::WriteSegmentFun
[d:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp, line 97]
nsInputStreamTee::ReadSegments
[d:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp, line 153]
nsGIFDecoder2::WriteFrom
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 223]
imgRequest::OnDataAvailable
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgRequest.cpp, line 730]
ProxyListener::OnDataAvailable
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 593]
nsStreamListenerTee::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp, line 57]
nsHttpChannel::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2487]
nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 203]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
nsEventQueueImpl::ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\nsEventQueue.cpp, line 389] 

Adding qawanted to see if we can get this reproduced somehow.  The few comments
given for recent milestones and Trunk builds mention shutting down.  Here are
the only urls I found for recent crashes:
 www.another.com
 ftp://current.freebsd.org/

If we can't reproduce this one, perhaps we should just mark it worksforme.  If
this becomes a topcrasher in the future we can always reopen it.

Comment 5

[Shiva Thirumazhusai]

nominating topcrash bugs for nsbeta1. 

Comment 6

[Stuart Parmenter]

-> 1.0

Comment 7

[Gagan]

Can someone help provide a test case for this? Terri?
per adt, not critical for nsbeta1. hence minus.

Comment 8

[greer]

Attachment: N621 User comments

For future reference, attaching the N621 comments from users crashing between
3/4 and 3/14/02. (Not much help here.)

Comment 9

[lchiang]

"There haven't been too many incidents since N621, but I do see a few incidents
with M097 and M098....as well as a couple of recent crashes on the MozillaTrunk. "

So this is no longer a topcrash?  If that is the case, we should remove topcrash
keyword.

Comment 10

[greer]

Attachment: Current crashes and comments

This one is still showing up in large numbers in NS releases and sporadically
in the Trunk and milestones. Attached are the comments from N622 for future
reference.

Comment 11

[greer]

Attachment: N622 comments

This replaces the previous attachment removing some unnecessary info.

Comment 12

[Jay Patel [:jay]]

Although not in huge numbers, this is still crashing Mozilla 1.0 and Netscape
7.0PR1.  Adding M100 and N70PR1 to summary for tracking.  All the comments still
talk about exiting the application and crashing.

Marking this topcrash- since we don't seem to be getting anywhere here.  If
anyone is able to reproduce this crash, please remove the - and make this a
topcrash again. Thanks.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

jpatel (or anybody else cc'd here), do you have the current stack for these
crashes? or is it still identical to the one in comment 4? (I'm especially
interested in the line number of imgContainer.cpp where the crash happens)

Comment 14

[Jay Patel [:jay]]

Well, the most recent incident on the MozillaTrunk with the
imgContainer::StartAnimation stack signature shows a different stack trace:
Incident ID 9086758
Stack Signature imgContainer::StartAnimation 10e83213
Email Address
Product ID MozillaTrunk
Build ID 2002080711
Trigger Time 2002-08-07 21:33:45
Platform Win32
Operating System Windows NT 5.1 build 2600
Module imglib2.dll
URL visited
User Comments
Trigger Reason Access violation
Source File Name c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgContainer.cpp
Trigger Line No. 336
Stack Trace
imgContainer::StartAnimation
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgContainer.cpp, line 336]
imgRequest::NotifyProxyListener
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgRequest.cpp, line 225]
httpValidateChecker::OnStartRequest
[c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgLoader.cpp, line 769]
nsHttpChannel::OnStartRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 2850]
nsOnStartRequestEvent::HandleEvent
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp, line 162]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 597]
PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c,
line 530]
nsEventQueueImpl::ProcessPendingEvents
[c:/builds/seamonkey/mozilla/xpcom/threads/nsEventQueue.cpp, line 392]

The line number is also different...so this might be a different crash.
--------------------------------------------
Looking at recent incidents with Gecko1.0 Branch builds, the line number has
also changed (imgContainer.cpp line 327), but the stacks remain similar to the
one originally reported:

Here's a crash with Netscape 7.0 PR1 (with original build):
Incident ID 10022346
Stack Signature imgContainer::StartAnimation d3ecdbe4
Email Address [e-mail]
Product ID Gecko1.0
Build ID 2002051220
Trigger Time 2002-08-28 21:41:20
Platform Win32
Operating System Windows 98 4.10 build 67766446
Module IMGLIB2.DLL
URL visited
User Comments This problem
Trigger Reason Access violation
Source File Name d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp
Trigger Line No. 327
Stack Trace
imgContainer::StartAnimation
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 327]
imgContainer::EndFrameDecode
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 236]
EndImageFrame
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 361]
gif_write [d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\GIF2.cpp,
line 1401]
nsGIFDecoder2::ProcessData
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 251]
ReadDataOut
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 196]
nsInputStreamTee::WriteSegmentFun
[d:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp, line 97]
0x65052c00 

and another crash with Netscape 7.0PR1 (with newer build):
Incident ID 9709705
Stack Signature imgContainer::StartAnimation 57a5ea76
Email Address
Product ID Gecko1.0
Build ID 2002061815
Trigger Time 2002-08-22 17:38:08
Platform Win32
Operating System Windows NT 5.1 build 2600
Module imglib2.dll
URL visited
User Comments
Trigger Reason Access violation
Source File Name d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp
Trigger Line No. 327
Stack Trace
imgContainer::StartAnimation
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 327]
imgContainer::EndFrameDecode
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 236]
EndImageFrame
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 361]
gif_write [d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\GIF2.cpp,
line 1401]
nsGIFDecoder2::ProcessData
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 251]
ReadDataOut
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 196]
nsInputStreamTee::WriteSegmentFun
[d:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp, line 97]
nsPipe::nsPipeInputStream::ReadSegments
[d:\builds\seamonkey\mozilla\xpcom\io\nsPipe2.cpp, line 420]
nsInputStreamTee::ReadSegments
[d:\builds\seamonkey\mozilla\xpcom\io\nsInputStreamTee.cpp, line 153]
nsGIFDecoder2::WriteFrom
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 271]
ReadDataOut
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\gif\nsGIFDecoder2.cpp,
line 193]
ntdll.dll + 0x168d (0x77f5168d)
ProxyListener::OnDataAvailable
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 705]
nsStreamListenerTee::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp, line 57]
nsHttpChannel::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2965]
nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 203]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 530]
nsEventQueueImpl::ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\nsEventQueue.cpp, line 392] 

Comment 15

[David Bradley]

About half the crashes I see in Talkbalk are due to the mTimer being null. The
others are crashes because of a jump to address zero, which is caused by the
stack getting trashed. I don't know enough about how Talkback creates the stack
is reports, so it's hard to say for sure if something StartAnimation called
corrupted the stack or the function itself did it.

The crash that I had was more than likely the animation was triggered after the
browser started to shutdown. This would cause do_CreateInstance to fail.

Most of the ones that I saw that talked about closing down had the null pointer.
The ones that had jumped to zero didn't have any comments or talked about moving
from one page to another. So we may have two types of crashes. It's easy enough
to fix the null mTimer one, and then see if that also takes care of the jump to
zero.

I was going to create a simple patch, but I think there may be too much going on
in the background that I don't know about. For instance why the the check of
mTimer in:
if (!mTimer) mTimer->Init(...)? 

The function already checked, so mTimer has to be null, unless something is
expected to happen in one of the functions or on another thread.
if (mTimer)
  return NS_OK;

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

>if (!mTimer) mTimer->Init(...)? 

such code does not exist in this function, rather the !mTimer checks look like this:
331       if (!mTimer) mTimer = do_CreateInstance("@mozilla.org/timer;1");

so if mTimer is null, a new timer is created.

Comment 17

[Shiva Thirumazhusai]

Talkback reports the crash happens in line 336 in the file imgcontainer.cpp
<snip>
Trigger Reason Access violation
Source File Name c:/builds/seamonkey/mozilla/modules/libpr0n/src/imgContainer.cpp
Trigger Line No. 336
</snip>

If you look at line number 336 in the code it a closing bracket. My suspicion is
  nsCOMPtr<gfxIImageFrame> currentFrame; is pointing to non-existent frame. When 
currentFrame pointer is released it causing a crash. I don't whether some other
thread is reducing the refcount. 


299 NS_IMETHODIMP imgContainer::StartAnimation()
300 {
301   if (mAnimationMode == kDontAnimMode)      // don't animate
302   {
303     mAnimating = PR_FALSE;
304     return NS_OK;
305   }
306 
307   mAnimating = PR_TRUE;
308         
309   if (mTimer)
310     return NS_OK;
311 
312   PRUint32 numFrames = inlinedGetNumFrames();
313 
314   if (numFrames > 1) {
315     PRInt32 timeout;
316     nsCOMPtr<gfxIImageFrame> currentFrame;
317     inlinedGetCurrentFrame(getter_AddRefs(currentFrame));
318     if (currentFrame) {
319       currentFrame->GetTimeout(&timeout);
320       if (timeout > 0) { // -1 means display this frame forever
321 
322         mAnimating = PR_TRUE;
323         if (!mTimer) mTimer = do_CreateInstance("@mozilla.org/timer;1");
324       
325         mTimer->Init(NS_STATIC_CAST(nsITimerCallback*, this),
326                      timeout, PR_TRUE, NS_TYPE_REPEATING_SLACK);
327       }
328     } else {
329       // XXX hack.. the timer notify code will do the right thing, so just
get that started
330       mAnimating = PR_TRUE;
331       if (!mTimer) mTimer = do_CreateInstance("@mozilla.org/timer;1");
332 
333       mTimer->Init(NS_STATIC_CAST(nsITimerCallback*, this),
334                    100, PR_TRUE, NS_TYPE_REPEATING_SLACK);
335     }
336   }
337 
338   return NS_OK;
339 }

Comment 18

[David Bradley]

Sorry that was a typo, was looking at wrong line when I started to type it. Note
line 309 in the previous comment. That already tests the null'ness of mTimer and
returns if it's non-null. So unless something happens to mTimer between 309 and
 323 or 333 it's going to be null. But that is what I was uncertain of, and why
I didn't want to risk just creating a simple patch (too much I don't know).

Reg comment #17. That could be for the jump to zero crashes/stack corruption.
Line numbers, though, can be misleading, due to optimization and age of code.
You really have to see the assembler to know for sure where a crash is occuring.
I think we're seeing two different types in talkback for StartAnimation. It's
just really hard to pinpoint the location for jumped to zero type crashes
because they have no assembler. For the crashes that occur on mov eax, [edi],
those are definitely caused because mTimer is null after calling
do_CreateInstance. And given that many of these occur on shutdown (probably all
of the mov eax, [edi] crashes) it's reasonable to expect do_CreateInstance to
return null. Is it reasonable for this function to be called during shutdown? I
don't know.

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

oh wow. I didn't notice that !mTimer check earlier... I'd say that the if
(!mTimer) part of the CreateInstances can be removed.

and, I think that mTimer should be null-checked after the CI

Comment 20

[ArronM (:paper)]

Attachment: Fixup StartAnimation

-Fixed up StartAnimation, including adding a mTimer check after CI

-Removed silly StartAnimation call in EndFrameDecode (no need to call
StartAnimation on each endframe notification)

-Changed timer creation in AppendFrame to call StartAnimation instead (only 1
timer creation spot is a good thing)

Comment 21

[ArronM (:paper)]

Attachment: Much smaller fix for 1.0 Branch

-diff'd against MOZILLA_1_0_0_BRANCH

-minimal changes to fix crash

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

r=biesi on both patches

Comment 23

[ArronM (:paper)]

Attachment: Fixup StartAnimation for Trunk

As per discussion with biesi on IRC:
- Removed redundant numFrames check ((numFrames>0) == (numFrames>=1) == duh)

- In StartAnimation(), removed setting mAnimating to False when mAnimationMode
is kDontAnimate.  This will never happen,  SetAnimationMode (the only way
mAnimationMode is set) calls StopAnimation, which in turn set mAnimation to
False (along with killing the timer)

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 102958 [details] [diff] [review]
Fixup StartAnimation for Trunk

r=biesi

Comment 25

[tor]

Comment on attachment 102764 [details] [diff] [review]
Much smaller fix for 1.0 Branch

sr=tor

(marking the missing r=biese)

Comment 26

[tor]

Comment on attachment 102958 [details] [diff] [review]
Fixup StartAnimation for Trunk

sr=tor

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz for trunk

Comment 28

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 102764 [details] [diff] [review]
Much smaller fix for 1.0 Branch

a=[e-mail] for 1.0 branch

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

checked in.

Comment 30

[Terri Preston]

Verified fix checked into bonsai.mozilla.org branch, addding verified1.0.2 keyword

Comment 31

[ArronM (:paper)]

Patch for Trunk _only_ caused regression Bug 177661.  Currently seeking approval
for backout.
I do have a potential corrected patch which will be ready for 1.3a.

Comment 32

[Asa Dotzler [:asa]]

drivers would rather see the regression fixed and keep the topcrash fix. Can you
try to get us a fix for bug 177661 for 1.2?