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
I get the same on my NVidia box, it runs fine on my ATI machine.
Here's a crash stat. http://crash-stats.mozilla.com/report/index/bp-e5a4f19d-0323-4519-8817-c40d82100629
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.
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 :)
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 :)
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>
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.
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
Last Resolved: 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.