StackOverflow Firefox crashes on website using Direct2D [@ _cairo_pattern_acquire_surface_for_surface+0x6b1]

RESOLVED WORKSFORME

Status

()

defect
--
critical
RESOLVED WORKSFORME
9 years ago
8 years ago

People

(Reporter: icecold, Unassigned)

Tracking

({crash})

Trunk
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, )

Attachments

(2 attachments, 2 obsolete attachments)

108.13 KB, text/plain
Details
117.49 KB, text/plain
Details
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre
Build Identifier: 

Tried to go on a website, it started to load but it crashed. It crashes every time.
How it seems crash doesn't happen to everyone who uses Direct2D.

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.mondo.rs/s174726/Vesti/Tevez-_Znao_sam_da_je_bio_ofsajd.html
2.Browser crashes.
3.
Actual Results:  
Browser crashed.

Expected Results:  
It should load website normally.

Nvidia 8400GS (257.21 drivers)
I cannot get a crash directly but the browser does completely lock up and become unresponsive.

Using Nvidia GeForce 8800 GT with 257.21 drivers installed. Marking as confirmed since a complete lockup is pretty bad - had I left it, it may have crashed anyway.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
I get the same on my NVidia box, it runs fine on my ATI machine.
Ugh, why don't we get symbols for DXGI and D3D10_1core :(
can you please use the MS symbol server? But just looking at the callstack as is, I don't see the NV driver module involved anywhere, although this could be an earlier problem (from a previous lock operation perhaps) manifesting.
I have same problem. nvidia 8400GS and Win7 x86. Browser crashes on loading that page.
Posted file windbg console log (obsolete) —
Also happened to me- Nvidia 8600M GT.
Followed the guide on http://support.microsoft.com/kb/311503 on how to get windbg working with the MS symbol server (sounded interesting :)).
The console log is attached though it doesn't show anything useful, I'm guessing you need the .pdb files to make sense of this? which ones?
(In reply to comment #7)
> Created an attachment (id=455229) [details]
> windbg console log
> 
> Also happened to me- Nvidia 8600M GT.
> Followed the guide on http://support.microsoft.com/kb/311503 on how to get
> windbg working with the MS symbol server (sounded interesting :)).
> The console log is attached though it doesn't show anything useful, I'm
> guessing you need the .pdb files to make sense of this? which ones?

If you're using a nightly or something of the likes, you'll want to add the mozilla symbol server into the mix:

https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server
That "log" seems to be windbg syntax error ;) 

"Couldn't resolve error at 'RV*C:\Users\Barak\Documents\symbols*http://msdl.microsoft.com/download/symbols'"

Unfortunately windbg searches all the modules before spitting that out, and therefore can easily get lost in all that spew.

Once you specify your symbol server(s), you should get a few bits of information, the important ones being the call stack (with symbols reloaded), registers, and the instructions being executed.
:Bas, please give out this url:
https://developer.mozilla.org/En/How_to_get_a_stacktrace_with_windbg

Barak, please try using the above :)
Posted file Windbg logfile (obsolete) —
Here you go :)
Attachment #455229 - Attachment is obsolete: true
Attachment #455438 - Attachment mime type: application/octet-stream → text/plain
sorry,

each time you get:
 Break instruction exception - code 80000003 (first chance)

you need to do debug>go

We're waiting for a different type of exception :)
Posted file Windbg file
Wow that took a long time :)
Attachment #455438 - Attachment is obsolete: true
Attachment #455451 - Attachment mime type: application/octet-stream → text/plain
PRIMARY_PROBLEM_CLASS:  STACK_OVERFLOW

BUGCHECK_STR:  APPLICATION_FAULT_STACK_OVERFLOW

LAST_CONTROL_TRANSFER:  from 778e4f2b to 778720a5

STACK_TEXT:  
...
d3d10_1core!operator new+0x10
d3d10_1core!CTexture2D<0>::CTexture2D<0>+0x215
d3d10_1core!CLayeredObject<CTexture2D<6> >::CreateInstance+0x2d
d3d10_1core!CDevice::CreateLayeredChild+0x273
d3d10_1core!CBridgeImpl<IDXGILayeredDevice,IDXGILayeredDevice,CLayeredObject<CDevice> >::CreateLayeredChild+0x22
dxgi!CD3D10LayeredChild<ID3D10DeviceChild,CD3D10Device,64>::FinalConstruct+0x2a
dxgi!CD3D10DeviceChild<IDXGISurface>::FinalConstruct+0x1b
dxgi!CD3D10Resource::FinalConstruct+0x20
dxgi!CLayeredObject<CD3D10Resource>::CreateInstance+0x73
dxgi!CD3D10Device::CreateLayeredChild+0xca
dxgi!CBridgeImpl<IDXGILayeredDevice,IDXGILayeredDevice,CLayeredObject<CD3D10Device> >::CreateLayeredChild+0x22
d3d10_1core!CD3D10LayeredChild<ID3D10VertexShader,NMultithread::CDevice,16>::FinalConstruct+0x2a
d3d10_1core!NMultithread::CTexture2D::FinalConstruct+0x1a
d3d10_1core!CLayeredObject<NMultithread::CTexture2D>::CreateInstance+0x57
d3d10_1core!NMultithread::CDevice::CreateLayeredChild+0xbf
d3d10_1core!CBridgeImpl<IDXGILayeredDevice,IDXGILayeredDevice,CLayeredObject<NMultithread::CDevice> >::CreateLayeredChild+0x22
dxgi!NOutermost::CDeviceChild::FinalConstruct+0x2a
dxgi!CUseCountedObject<NOutermost::CDeviceChild>::CUseCountedObject<NOutermost::CDeviceChild>+0x45
dxgi!CUseCountedObject<NOutermost::CDeviceChild>::CreateInstance+0x72
dxgi!NOutermost::CDevice::CreateLayeredChild+0xd2
d3d10_1core!CDevice::CreateTexture2D_Worker+0x227
d3d10_1core!CDevice::ID3D10Device1_CreateTexture2D_+0x1d
d3d10_1core!NMultithread::CDevice::CreateTexture2D+0x3c

this is just a call to d3d which eventually hits the end of stack space, it's uninteresting.

_cairo_d2d_acquire_source_image+0xae
_cairo_surface_acquire_source_image+0x29
_cairo_surface_clone_similar+0xec
_cairo_pattern_acquire_surface_for_surface+0x6b1 <LOOP>
_cairo_pattern_acquire_surface+0x1ce
_cairo_pattern_acquire_surfaces+0xdf
_cairo_image_surface_composite+0x60
_cairo_surface_composite+0x61
_composite_rectangle+0x71
_clip_and_composite_trapezoids+0xb9
_cairo_surface_fallback_paint+0x1ff
_cairo_surface_paint+0x7b
_cairo_surface_fallback_clone_similar+0xa1
_cairo_surface_clone_similar+0x193
_cairo_pattern_acquire_surface_for_surface+0x6b1 <LOOP>
Keywords: crash
Summary: Firefox crashes on website using Direct2D → StackOverflow Firefox crashes on website using Direct2D [@ _cairo_pattern_acquire_surface_for_surface+0x6b1]
Ok... 
So would you like me to keep hitting debug->go to hit other exceptions? what should I be looking for?
Well, if you still want to play w/ windbg, we can try to get the bottom of the stack trace, as it might be more enlightening.

To do that, when you hit this for the first time:
ntdll!LdrpDoDebuggerBreak+0x2c:
778be60e cc              int     3
?:???> 

enter:
bp xul!_cairo_pattern_acquire_surface_for_surface "kp; g"

then do debug>go as usual.

The log will be *much* longer than before, but basically what we're looking for is the first time there's a stack that shows:

_cairo_pattern_acquire_surface_for_surface
...
_cairo_pattern_acquire_surface_for_surface+0x6b1
...
_cairo_pattern_acquire_surface_for_surface+0x6b1
<interesting non repeating part here>

If not, we're mostly done, you can choose to wait for someone to play engineer and figure out why it ran away. It should be possible for someone to figure it out from what you've provided.

If you'd like to look into this from a developer perspective, I can hold your hand. Roughly you'd load the windbg log, and pick the range i highlighted and visit http://mxr.mozilla.org/mozilla1.9.2/ and read the source and try to figure out how it decided to recurse forever.
Posted file Second windbg log
Entered the command as you suggested in comment 16, unfortunately the stack trace has the same length as before and doesn't seem (at least to me) to show where the recursion started...
I don't have the time atm, but when I do I'll get back to you on this (as I would like to "play the developer perspective" on this) - providing this bug doesn't get fixed by then :)
Attachment #455474 - Attachment mime type: application/octet-stream → text/plain
hrm, oh well. i think for now i'll worry about other things. i'm pretty sure the devs who work on this can figure it out w/o us.
Thought I'd get back on this, since now I have some free time on my hands but unfortunately I can't reproduce it with the latest nightly... oh well :)

Should this bug be marked as resolved?
Hm! I guess we can mark this worksforme - if you come upon it again, please reopen!
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
I tried visiting the link I posted again with build 20100814 and it's not crashing anymore. Using 258.96 drivers.
Crash Signature: [@ _cairo_pattern_acquire_surface_for_surface+0x6b1]
You need to log in before you can comment on or make changes to this bug.