Re: one liner patch to stop crash, everquest2.exe
2008/7/24 Andrew Fenn [EMAIL PROTECTED]: Any suggestion on where to go from here? Does this need more discussion elsewhere or should a simple return WINED3DERR_INVALIDCALL do it? I'm having trouble understanding where I should be checking for this error and returning an the invalid call. Simply returning WINED3DERR_INVALIDCALL on recursive Resets is certainly worth a try to see if it fixes the game. It'll involve switching a d3d window from windowed to fullscreen, and having a window proc that calls Reset on position changes. There are two things you want to know there: does your window proc get triggered by Reset in the first place, and if it does, what does the second reset return.
Re: one liner patch to stop crash, everquest2.exe
certainly worth a try to see if it fixes the game. It'll involve There should be a You'll still need a test case though. somewhere in that line.
Re: one liner patch to stop crash, everquest2.exe
Any suggestion on where to go from here? Does this need more discussion elsewhere or should a simple return WINED3DERR_INVALIDCALL do it? I'm having trouble understanding where I should be checking for this error and returning an the invalid call. On Mon, Jul 21, 2008 at 9:28 PM, Stefan Dösinger [EMAIL PROTECTED] wrote: Ah, so it's essentially a recursive Reset call. My guess would be that we don't want to allow that, but it requires some tests on native win32 to verify. You could try returning WINED3DERR_INVALIDCALL when Reset gets called from inside another Reset call, to see how the application reacts to that. This also raises another question regarding the window handling in wined3d: Are we allowed / supposed to modify the window size and position of the destination window the app supplies like this? A lot of apps seem to need that, otherwise the rendering is placed incorrectly or not visible because the window is hidden. However, it could be that Windows somehow renders correctly without changing the Window's properties. So the SetWindowPos() call in Reset() might be the wrong thing here. It is not entirely unexpected that the app calls Reset when it receives a Window position / size change. If the Window size changes, the app is supposed to reset the D3D device, otherwise the rendering output is stretched in Present(which can look kinda ugly)
Re: one liner patch to stop crash, everquest2.exe
2008/7/21 Stefan Dösinger [EMAIL PROTECTED]: Is the shader backend recreated properly after the reset? Just to clarify, in dlls/wined3d/device.c, IWineD3DDeviceImpl_Reset(), line 7355 there's a call to shader_alloc_private(). This call is supposed to recreate This-shader_priv.
Re: one liner patch to stop crash, everquest2.exe
I changed: hr = This-shader_backend-shader_alloc_private(iface); To the following: FIXME(BEFORE, hr: 0x%08x\n, hr); hr = This-shader_backend-shader_alloc_private(iface); FIXME(AFTER, hr: 0x%08x\n, hr); ...and then I ran everquest2.exe again, alt+enter to full screen... fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER wine: Unhandled page fault on read access to 0x0008 at address 0x7e44abcc (thread 0009), starting debugger... The last two seem interesting where they don't reach shader_alloc_private() portion of the code, could this maybe be part of the problem? On Mon, Jul 21, 2008 at 1:39 PM, H. Verbeet [EMAIL PROTECTED] wrote: 2008/7/21 Stefan Dösinger [EMAIL PROTECTED]: Is the shader backend recreated properly after the reset? Just to clarify, in dlls/wined3d/device.c, IWineD3DDeviceImpl_Reset(), line 7355 there's a call to shader_alloc_private(). This call is supposed to recreate This-shader_priv.
Re: one liner patch to stop crash, everquest2.exe
2008/7/21 Andrew Fenn [EMAIL PROTECTED]: fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER wine: Unhandled page fault on read access to 0x0008 at address 0x7e44abcc (thread 0009), starting debugger... The last two seem interesting where they don't reach shader_alloc_private() portion of the code, could this maybe be part of the problem? That's probably the reason, yes. I don't see how Reset can return before calling shader_alloc_private() though.
Re: one liner patch to stop crash, everquest2.exe
Here's my uneducated idea about what's happening, it's calling the USER_SetWindowPos() in /user32/winpos.c to an x and y of 0 which goes off to SendMessageW. SendMessageW calls send_message which in turn calls call_window_proc. At this point something resets because SendMessageW should log both a 1 and 2\n which I added to be printed out but as you can see below it only prints out a 1 and then goes on to IWineD3DDeviceImpl_Reset after hitting call_window_proc.. fixme:msg:SendMessageW 1sendmsg1 fixme:msg:send_message sendmsg2 fixme:msg:send_message sendmsg3 fixme:d3d:IWineD3DDeviceImpl_Reset HELLO, hr: 0x fixme:d3d_shader:shader_glsl_free FREE SHADER wine: Unhandled page fault on read access to 0x0008 at address 0x7e452e5c (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x0008 in 32-bit code (0x7e452e5c). Does any of that make any sense? On Mon, Jul 21, 2008 at 2:58 PM, H. Verbeet [EMAIL PROTECTED] wrote: 2008/7/21 Andrew Fenn [EMAIL PROTECTED]: fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE fixme:d3d_shader:shader_glsl_free FREE SHADER wine: Unhandled page fault on read access to 0x0008 at address 0x7e44abcc (thread 0009), starting debugger... The last two seem interesting where they don't reach shader_alloc_private() portion of the code, could this maybe be part of the problem? That's probably the reason, yes. I don't see how Reset can return before calling shader_alloc_private() though.
Re: one liner patch to stop crash, everquest2.exe
2008/7/21 Andrew Fenn [EMAIL PROTECTED]: Here's my uneducated idea about what's happening, it's calling the USER_SetWindowPos() in /user32/winpos.c to an x and y of 0 which goes off to SendMessageW. SendMessageW calls send_message which in turn calls call_window_proc. At this point something resets because SendMessageW should log both a 1 and 2\n which I added to be printed out but as you can see below it only prints out a 1 and then goes on to IWineD3DDeviceImpl_Reset after hitting call_window_proc.. fixme:msg:SendMessageW 1sendmsg1 fixme:msg:send_message sendmsg2 fixme:msg:send_message sendmsg3 fixme:d3d:IWineD3DDeviceImpl_Reset HELLO, hr: 0x fixme:d3d_shader:shader_glsl_free FREE SHADER wine: Unhandled page fault on read access to 0x0008 at address 0x7e452e5c (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x0008 in 32-bit code (0x7e452e5c). Does any of that make any sense? Ah, so it's essentially a recursive Reset call. My guess would be that we don't want to allow that, but it requires some tests on native win32 to verify. You could try returning WINED3DERR_INVALIDCALL when Reset gets called from inside another Reset call, to see how the application reacts to that.
RE: one liner patch to stop crash, everquest2.exe
Ah, so it's essentially a recursive Reset call. My guess would be that we don't want to allow that, but it requires some tests on native win32 to verify. You could try returning WINED3DERR_INVALIDCALL when Reset gets called from inside another Reset call, to see how the application reacts to that. This also raises another question regarding the window handling in wined3d: Are we allowed / supposed to modify the window size and position of the destination window the app supplies like this? A lot of apps seem to need that, otherwise the rendering is placed incorrectly or not visible because the window is hidden. However, it could be that Windows somehow renders correctly without changing the Window's properties. So the SetWindowPos() call in Reset() might be the wrong thing here. It is not entirely unexpected that the app calls Reset when it receives a Window position / size change. If the Window size changes, the app is supposed to reset the D3D device, otherwise the rendering output is stretched in Present(which can look kinda ugly)
Re: one liner patch to stop crash, everquest2.exe
yes I am looking at the shaders... and am noticing something as well in the traces... some reason when it goes to ask how much memory to use... on my machine it thinks it only has 16mb of texture memory.. when the laptop has 256mb of video ram...? if you look in device.c the pixel shader fails atleast on my firegl5200.? The other curiosity is that when EverQuest2.exe runs it seems to be going through the adapter initialization two times.. once when it loads then it starts loading up sound? and then it looks atleast in my traces? it initializes the adapter again getting an adapter which is the second adapter (I think) used for dual head Chris
Re: one liner patch to stop crash, everquest2.exe
Stefan Dösinger wrote:
Is the shader backend recreated properly after the reset?
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew Fenn
*Sent:* Sunday, July 20, 2008 11:11 PM
*To:* H. Verbeet
*Cc:* wine-devel@winehq.org
*Subject:* Re: one liner patch to stop crash, everquest2.exe
I think that both calls are coming from d3d9:IDirect3DDevice9Impl_Reset
I put some FIXME's in the code and it passes the same function. In the
log below you can see where the crash is happening.
fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
fixme:d3d_shader:shader_glsl_free FREE SHADER
fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
fixme:d3d_shader:shader_glsl_free FREE SHADER
wine: Unhandled page fault on read access to 0x0008 at address
0x7e44ab4c (thread 0009), starting debugger...
Does this mean that the problem resides somewhere in
IDirect3DDevice9Impl_Reset ?
On Thu, Jul 17, 2008 at 10:44 PM, H. Verbeet [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
2008/7/17 Andrew Fenn [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Here's what I got from the debug log.
Backtrace:
=1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
(0x0032e918)
2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b8,
pPresentationParameters=0x32e9c0)
[/home/andrew/wine/wine/dlls/wined3d/device.c:7237] in wined3d
(0x0032e998)
3 0x7e4f33ce IDirect3DDevice9Impl_Reset+0x1ae(iface=register EDI
not in
topmost frame, pPresentationParameters=0x1b9f848)
[/home/andrew/wine/wine/dlls/d3d9/device.c:381] in d3d9 (0x0032ea08)
4 0x008d31a1 in everquest2 (+0x4d31a1) (0x0032ea3c)
0x7e43e9b3 shader_glsl_free+0x23
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d: movl
0x8(%esi),%eax
3491if(priv-depth_blt_glsl_program_id) {
That's the second one, but where does the previous call come from?
No I dont think it s getting reset correctly
chris
Re: one liner patch to stop crash, everquest2.exe
I'm not sure how to investigate this properly is there a way to get a back
trace every time it hits that function?
On Thu, Jul 17, 2008 at 10:44 PM, H. Verbeet [EMAIL PROTECTED] wrote:
2008/7/17 Andrew Fenn [EMAIL PROTECTED]:
Here's what I got from the debug log.
Backtrace:
=1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
(0x0032e918)
2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b8,
pPresentationParameters=0x32e9c0)
[/home/andrew/wine/wine/dlls/wined3d/device.c:7237] in wined3d
(0x0032e998)
3 0x7e4f33ce IDirect3DDevice9Impl_Reset+0x1ae(iface=register EDI not
in
topmost frame, pPresentationParameters=0x1b9f848)
[/home/andrew/wine/wine/dlls/d3d9/device.c:381] in d3d9 (0x0032ea08)
4 0x008d31a1 in everquest2 (+0x4d31a1) (0x0032ea3c)
0x7e43e9b3 shader_glsl_free+0x23
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d: movl
0x8(%esi),%eax
3491if(priv-depth_blt_glsl_program_id) {
That's the second one, but where does the previous call come from?
Re: one liner patch to stop crash, everquest2.exe
I think that both calls are coming from d3d9:IDirect3DDevice9Impl_Reset
I put some FIXME's in the code and it passes the same function. In the log
below you can see where the crash is happening.
fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
fixme:d3d_shader:shader_glsl_free FREE SHADER
fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
fixme:d3d_shader:shader_glsl_free FREE SHADER
wine: Unhandled page fault on read access to 0x0008 at address
0x7e44ab4c (thread 0009), starting debugger...
Does this mean that the problem resides somewhere in
IDirect3DDevice9Impl_Reset ?
On Thu, Jul 17, 2008 at 10:44 PM, H. Verbeet [EMAIL PROTECTED] wrote:
2008/7/17 Andrew Fenn [EMAIL PROTECTED]:
Here's what I got from the debug log.
Backtrace:
=1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
(0x0032e918)
2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b8,
pPresentationParameters=0x32e9c0)
[/home/andrew/wine/wine/dlls/wined3d/device.c:7237] in wined3d
(0x0032e998)
3 0x7e4f33ce IDirect3DDevice9Impl_Reset+0x1ae(iface=register EDI not
in
topmost frame, pPresentationParameters=0x1b9f848)
[/home/andrew/wine/wine/dlls/d3d9/device.c:381] in d3d9 (0x0032ea08)
4 0x008d31a1 in everquest2 (+0x4d31a1) (0x0032ea3c)
0x7e43e9b3 shader_glsl_free+0x23
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d: movl
0x8(%esi),%eax
3491if(priv-depth_blt_glsl_program_id) {
That's the second one, but where does the previous call come from?
RE: one liner patch to stop crash, everquest2.exe
Is the shader backend recreated properly after the reset?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Fenn
Sent: Sunday, July 20, 2008 11:11 PM
To: H. Verbeet
Cc: wine-devel@winehq.org
Subject: Re: one liner patch to stop crash, everquest2.exe
I think that both calls are coming from d3d9:IDirect3DDevice9Impl_Reset
I put some FIXME's in the code and it passes the same function. In the log
below you can see where the crash is happening.
fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
fixme:d3d_shader:shader_glsl_free FREE SHADER
fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
fixme:d3d_shader:shader_glsl_free FREE SHADER
wine: Unhandled page fault on read access to 0x0008 at address 0x7e44ab4c
(thread 0009), starting debugger...
Does this mean that the problem resides somewhere in IDirect3DDevice9Impl_Reset
?
On Thu, Jul 17, 2008 at 10:44 PM, H. Verbeet [EMAIL PROTECTED] wrote:
2008/7/17 Andrew Fenn [EMAIL PROTECTED]:
Here's what I got from the debug log.
Backtrace:
=1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
(0x0032e918)
2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b8,
pPresentationParameters=0x32e9c0)
[/home/andrew/wine/wine/dlls/wined3d/device.c:7237] in wined3d (0x0032e998)
3 0x7e4f33ce IDirect3DDevice9Impl_Reset+0x1ae(iface=register EDI not in
topmost frame, pPresentationParameters=0x1b9f848)
[/home/andrew/wine/wine/dlls/d3d9/device.c:381] in d3d9 (0x0032ea08)
4 0x008d31a1 in everquest2 (+0x4d31a1) (0x0032ea3c)
0x7e43e9b3 shader_glsl_free+0x23
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d: movl
0x8(%esi),%eax
3491if(priv-depth_blt_glsl_program_id) {
That's the second one, but where does the previous call come from?
Re: one liner patch to stop crash, everquest2.exe
Here's what I got from the debug log.
Backtrace:
=1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
(0x0032e918)
2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b8,
pPresentationParameters=0x32e9c0)
[/home/andrew/wine/wine/dlls/wined3d/device.c:7237] in wined3d (0x0032e998)
3 0x7e4f33ce IDirect3DDevice9Impl_Reset+0x1ae(iface=register EDI not in
topmost frame, pPresentationParameters=0x1b9f848)
[/home/andrew/wine/wine/dlls/d3d9/device.c:381] in d3d9 (0x0032ea08)
4 0x008d31a1 in everquest2 (+0x4d31a1) (0x0032ea3c)
0x7e43e9b3 shader_glsl_free+0x23
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d: movl
0x8(%esi),%eax
3491if(priv-depth_blt_glsl_program_id) {
Last couple of debug lines before wine crashes:
trace:d3d:IWineD3DDeviceImpl_EnumResources enumerating resource 0x2cf01a0
trace:d3d:reset_unload_resources Unloading resource 0x2cf01a0
trace:d3d:IWineD3DDeviceImpl_QueryInterface
(0x19c4b8)-({3c2aebf6-6f30-11d9-c687-00046142c14f},0x32e898)
trace:d3d:IWineD3DDeviceImpl_EnumResources enumerating resource 0x2cf0080
trace:d3d:reset_unload_resources Unloading resource 0x2cf0080
trace:d3d:IWineD3DSwapChainImpl_QueryInterface
(0x1b1170)-({3c2aebf6-6f30-11d9-c687-00046142c14f},0x32e898)
trace:d3d:IWineD3DDeviceImpl_EnumResources enumerating resource 0x1b1818
trace:d3d:reset_unload_resources Unloading resource 0x1b1818
trace:d3d:IWineD3DSwapChainImpl_QueryInterface
(0x1b1170)-({3c2aebf6-6f30-11d9-c687-00046142c14f},0x32e898)
On Thu, Jul 17, 2008 at 8:31 PM, H. Verbeet [EMAIL PROTECTED] wrote:
2008/7/17 Andrew Fenn [EMAIL PROTECTED]:
Not sure, I just figured it was the program that was doing it? I'll try
and
figure it out and reply back to you as soon as I can.
Obvious candidates would be Reset or Uninit3D in device.c, but at
first sight those appear to be safe to call multiple times.
Re: one liner patch to stop crash, everquest2.exe
2008/7/17 Andrew Fenn [EMAIL PROTECTED]: I added a check to make sure This-shader_priv wasn't null. Before Everquest2.exe would crash when I tried to alt+enter from windowed mode. This stops it crashing wine. This-shader_priv shouldn't be NULL. It probably means the backend was already destroyed when shader_glsl_free() was called.
Re: one liner patch to stop crash, everquest2.exe
2008/7/17 Andrew Fenn [EMAIL PROTECTED]: I noticed this function gets called twice when doing an alt+enter to full screen. From where?
Re: one liner patch to stop crash, everquest2.exe
2008/7/17 Andrew Fenn [EMAIL PROTECTED]: Not sure, I just figured it was the program that was doing it? I'll try and figure it out and reply back to you as soon as I can. Obvious candidates would be Reset or Uninit3D in device.c, but at first sight those appear to be safe to call multiple times.
Re: one liner patch to stop crash, everquest2.exe
2008/7/17 Andrew Fenn [EMAIL PROTECTED]:
Here's what I got from the debug log.
Backtrace:
=1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
(0x0032e918)
2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b8,
pPresentationParameters=0x32e9c0)
[/home/andrew/wine/wine/dlls/wined3d/device.c:7237] in wined3d (0x0032e998)
3 0x7e4f33ce IDirect3DDevice9Impl_Reset+0x1ae(iface=register EDI not in
topmost frame, pPresentationParameters=0x1b9f848)
[/home/andrew/wine/wine/dlls/d3d9/device.c:381] in d3d9 (0x0032ea08)
4 0x008d31a1 in everquest2 (+0x4d31a1) (0x0032ea3c)
0x7e43e9b3 shader_glsl_free+0x23
[/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d: movl
0x8(%esi),%eax
3491if(priv-depth_blt_glsl_program_id) {
That's the second one, but where does the previous call come from?
