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

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Oskar Ivanić (:icecold)]

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)

Comment 1

[Ryan Jones-Ward [:sciguyryan]]

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.

Comment 2

[Bas Schouten (:bas.schouten)]

I get the same on my NVidia box, it runs fine on my ATI machine.

Comment 3

[Oskar Ivanić (:icecold)]

Here's a crash stat.
http://crash-stats.mozilla.com/report/index/bp-e5a4f19d-0323-4519-8817-c40d82100629

Comment 4

[Bas Schouten (:bas.schouten)]

Ugh, why don't we get symbols for DXGI and D3D10_1core :(

Comment 5

[Musawir Ali]

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.

Comment 6

[matko.kostelic]

I have same problem. nvidia 8400GS and Win7 x86. Browser crashes on loading that page.

Comment 7

[Barak Gross]

Attachment: 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?

Comment 8

[Bas Schouten (:bas.schouten)]

(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

Comment 9

[Musawir Ali]

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.

Comment 10

[timeless]

:Bas, please give out this url:
https://developer.mozilla.org/En/How_to_get_a_stacktrace_with_windbg

Barak, please try using the above :)

Comment 11

[Barak Gross]

Attachment: Windbg logfile

Here you go :)

Comment 12

[timeless]

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 :)

Comment 13

[Barak Gross]

Attachment: Windbg file

Wow that took a long time :)

Comment 14

[timeless]

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>

Comment 15

[Barak Gross]

Ok... 
So would you like me to keep hitting debug->go to hit other exceptions? what should I be looking for?

Comment 16

[timeless]

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.

Comment 17

[Barak Gross]

Attachment: 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 :)

Comment 18

[timeless]

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.

Comment 19

[Barak Gross]

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?

Comment 20

[Joe Drew (not getting mail)]

Hm! I guess we can mark this worksforme - if you come upon it again, please reopen!

Comment 21

[Oskar Ivanić (:icecold)]

I tried visiting the link I posted again with build 20100814 and it's not crashing anymore. Using 258.96 drivers.