609041 - Calling ::MoveWindow on the Firefox HWND with a large new width/length (8000+) crashes the browser @ CDevice::ID3D10Device1_ClearRenderTargetView_

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Scott Schmerer]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; .NET4.0E) chromeframe/7.0.517.43
Build Identifier: 4.0b8pre also shows in 4.0b6


::MoveWindow( hFrameWnd, rcFrame.left, rcFrame.top, rcFrame.Width() + lScrollAdditionnalWidth, rcFrame.Height() + lScrollAdditionnalHeight, TRUE );
with the variables set with these values: http://screencast.com/t/eMeh0waW

The hFrameWnd is the HWND of the main FF4 window.

Reproducible: Always

Steps to Reproduce:
Simply calling ::MoveWindow with the values mentioned above will crash the browser.
Actual Results:  
FF Crashes

Expected Results:  
It can handle any call to the resize (or that the limit of the resize is available somewhere)

Comment 1

[timeless]

https://developer.mozilla.org/en/how_to_get_a_stacktrace_for_a_bug_report

Comment 2

[Scott Schmerer]

Sorry, should have posted these in the first place.

bp-bf9e30db-d97f-42b1-ace7-6560f2101104   11/4/2010  2:00 PM
bp-794fc258-0382-43ef-8137-bfeb52101102   11/2/2010  11:49 AM

Please holler if there is any other info you need.  I am very curious in the result of this bug.

Comment 3

[timeless]

Signature	d3d10_1core.dll@0x2d7f8
UUID	bf9e30db-d97f-42b1-ace7-6560f2101104
Time 	2010-11-04 11:00:35.939886
Uptime	25
Last Crash	40 seconds before submission
Install Age	190972 seconds (2.2 days) since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101102042148
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 37 stepping 5
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x18
User Comments	
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0a29
Processor Notes 	
EMCheckCompatibility	False
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	d3d10_1core.dll 	d3d10_1core.dll@0x2d7f8 	
1 	xul.dll 	mozilla::layers::LayerManagerD3D10::EndTransaction 	gfx/layers/d3d10/LayerManagerD3D10.cpp:239
2 	xul.dll 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:461
3 	xul.dll 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1440
4 	xul.dll 	PresShell::Paint 	layout/base/nsPresShell.cpp:6088
5 	xul.dll 	nsViewManager::RenderViews 	view/src/nsViewManager.cpp:447
6 	xul.dll 	nsViewManager::Refresh 	view/src/nsViewManager.cpp:413
7 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:912
8 	xul.dll 	AttachedHandleEvent 	view/src/nsView.cpp:193
9 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:3502
10 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:3530
11 	uxtheme.dll 	uxtheme.dll@0x5059f 	
12 	uxtheme.dll 	uxtheme.dll@0x19151 	
13 	uxtheme.dll 	uxtheme.dll@0x19164 	
14 	user32.dll 	RealGetSystemMetrics 	

hollering:
the top frame doesn't have symbols, if you follow these instructions, we can get symbols for the rest of the stack, thanks:

https://developer.mozilla.org/En/How_to_get_a_stacktrace_with_WinDbg

Comment 4

[Scott Schmerer]

Attachment: WinDbg Log of the crash

This crash didn't fire off the "Oh no, report this bug to firefox" dialog, but I assumed it was just because I was running it through WinDbg (or because I ran it as Admin, because I thought the logs weren't being created.  Hope the Admin'ness didn't add noise to the log)

Comment 5

[timeless]

that's not the right crash :(, offhand it looks like bug 607299.

the log is otherwise well formed.

and yes, you won't get the oh no dialog if you're running a debugger (well, with effort you could, but it's unnecessary).

you can provide any path you like for .logopen, if you can figure out a way for that instruction to work better for people, please help improve the article by changing it.

Comment 6

[Scott Schmerer]

Attachment: Second WindDbg crash dump

This one seems to have different crash information.  Hopefully this helps point to a more similar problem that I am running into.

Comment 7

[timeless]

Much closer.

ModLoad: 603e0000 6044f000   C:\Windows\SysWOW64\D3D10SDKLayers.dll
DXGI Error: CDXGISwapChain::GetBuffer: buffer creation failed allocation; no buffers available.

(320.1eac): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=715cd7f0 ebx=00000000 ecx=00000000 edx=04a09034 esi=00000000 edi=001accb8
eip=715cd7f8 esp=001acc4c ebp=001acd08 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
d3d10_1core!CDevice::ID3D10Device1_ClearRenderTargetView_+0x8:
715cd7f8 8b4618          mov     eax,dword ptr [esi+18h] ds:002b:00000018=????????
0:000> g

You shouldn't have used "g" here, this was the point where we wanted to switch to !analyze.  That said, it gives me the basic bits for a signature. Please do try to repeat this, and instead use !analyze at this point.

Comment 8

[Bas Schouten (:bas.schouten)]

Hrm, so we need to figure out a way to fall back to software in this particular situation. The hardware simply cannot support windows of this size. It's not a 'hard' problem to solve but it requires a bit of extra code.

Comment 9

[Scott Schmerer]

Attachment: Third WinDbg Log of crash

Was able to reproduce and analyze earlier.  I think this has the stack trace you need.

Comment 10

[timeless]

yep. thanks. i'm done, this is now between d3d/ms, bas, and you.

Comment 11

[Scoobidiver (away)]

It still happens: bp-470b995f-2983-4d1a-9ff2-284a42110114

Comment 12

[[Baboo]]

True.
bp-7b58b61f-0d0e-444f-a5a8-3df382110211

Shouldn't this block?

Comment 13

[Joe Drew (not getting mail)]

It seems that we no longer have crashes at this address; please correct me if I'm wrong.

Comment 14

[Scoobidiver (away)]

(In reply to Joe Drew (:JOEDREW!) from comment #13)
> It seems that we no longer have crashes at this address; please correct me
> if I'm wrong.
It was written before we've got Windows dll symbols.
I'd say it's a dupe of bug 706446 which has currently no STR.

Comment 16

[MarkRH]

I seem to be getting crashes that are related to this: http://crash-stats.mozilla.com/report/index/bp-5b90909e-0c9f-44cd-bb5f-273cf2130115

Happens to me when I move the mouse over Adblock Plus toolbar button and it displays its tooltop. If there is a really long filter it will make a tooltip over 2000px wide. Here's a site that can cause it: http://tvlistings.zap2it.com/tvlistings/ZCGrid.do?position=

I've been trying to write a stylish snippet to force a maximum width for tooltips but all I've managed to be able to do is change colors and fonts.

FF18 in Windows 7 Pro 64-bit with a Classic Theme. I do have Window shading turned off to correct garbage left over on Window borders and such.

Comment 17

[GBROW6373]

I had this error message constantly on a new windows 7 install. Thought it might be a tooltip or screen resolution issue . First noticed after installing a new graphics card ( GT430 ). No issues with other browsers. Tools/Options/Advanced/ turn off hardware acceleration  : seemed to work for me.

Comment 18

[MarkRH]

FYI, I was able to use this Stylish code to hide the filters line in the Adblock Plus Tooltip: (I made the border color red just so I know my filter is active)

#abp-tooltip {
   -moz-appearance: none !important;
   border-color: #ff0000 !important;
}

#abp-tooltip-filters,
#abp-tooltip-filters-label,
#abp-tooltip-more-filters  {
   display:none !important;
}

Anyway, at least I don't inadvertently crash FF moving my mouse over the ABP toolbar button now. In this case I'm not too sure if it's really a bug with FF itself but a bug with ABP in how it's handling that tooltip and its CSS.

Comment 19

[Loic]

Recent crash (https://crash-stats.mozilla.com/report/index/bp-af3ed1e2-33b1-4688-9f81-478c02130225) during testing a Flash testcase, I was minimizing the Firefox window by using the desktop icon in taskbar to switch to another app, and FF crashed.

Comment 22

[u279076]

I am closing this bug as incomplete since the most recent version reported in the last 6 months is Firefox 33 which is long past end-of-life.