2008/8/2 Andrew Fenn <[EMAIL PROTECTED]>:
> After doing a recent git pull I noticed that it now crashes at a different
> place in the code. Here's the backtrace (I haven't had a look yet, this is
> more of a heads up)..
>
> Backtrace:
> =>1 0x7e49089b hash_table_destroy+0xb(table=0x17, free_value=0
After doing a recent git pull I noticed that it now crashes at a different
place in the code. Here's the backtrace (I haven't had a look yet, this is
more of a heads up)..
Backtrace:
=>1 0x7e49089b hash_table_destroy+0xb(table=0x17, free_value=0x7e3e8dc0,
cb=0x7e4c9a50) [/home/andrew/wine/wine/dll
> 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.
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
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
> *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 hap
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
a
> 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
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 so
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
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_Re
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:IDire
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.
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
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
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:
> >
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.
On Thu, Jul 17, 2008 at 6:49 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> > I noticed this function gets called twice when
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/
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=0x19c4b
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 t
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> I noticed this function gets called twice when doing an alt+enter to full
> screen.
>
>From where?
I noticed this function gets called twice when doing an alt+enter to full
screen.
On Thu, Jul 17, 2008 at 4:35 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> > I added a check to make sure This->shader_priv wasn't null. Before
> > Everquest2.exe would cra
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
23 matches
Mail list logo