On Friday 20 October 2006 05:52, Stefan Dösinger wrote:
Am Donnerstag 19 Oktober 2006 02:46 schrieb Robert Lunnon:
I'm still trying to work this out, see below, but I have a silly question, how *should* IWineGDISurfaceImpl_Blt behave if args 2 & 3 are NULL IE DestRect and SrcSurface are both NULL. Is this a no-op ?
No, look at the DDBLTFX structure and the dwFlags parameter. IDirectDrawSurface7::Blt knows a few source-less blts, like colorfill.
One of the last remaining ddraw docs on the msdn: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/ddraw7/dir ectdraw7/ddref_4b7b.asp
About the other things, I have to look at them. But it seems that there are DXTN surfaces(compressed textures) involved, and 2D operation on compressed textures are implemented in a very basic fashion only, and likely to produce problems.
More information, yes you are right.. Delving on further shows the malloc failures are handled by the signal handler (Never liked this design) but eventually fails in a colourfill operation around line 450 in gdi_surface.c (below) which I have instrumented
case 3: { BYTE *d = (BYTE *) buf; for (x = 0; x < width; x++,d+=3) { ERR("Filling %lx with %x - 3 Bytes\n",d,color); d[0] = (color ) & 0xFF; d[1] = (color>> 8) & 0xFF; d[2] = (color>>16) & 0xFF; } break; }
The debugger tells me i get a segv here which the signal handler fixes up - restarts the instruction which faults again in an infinite loop
err:d3d_surface:_Blt_ColorFill ColorFill 7d6c0000 794 550 3 2384 0 err:d3d_surface:_Blt_ColorFill Filling 7d6c0000 with 0 - 3 Bytes mdb: stop on SIGSEGV mdb: target stopped at: wined3d.dll.so`_Blt_ColorFill+0x15b: movb %al,(%edx)
::cont
err:seh:segv_handler Got trap 14 (2) accessing Address 7d6c0000 mdb: stop on SIGSEGV mdb: target stopped at: wined3d.dll.so`_Blt_ColorFill+0x15b: movb %al,(%edx)
::cont
err:seh:segv_handler Got trap 14 (2) accessing Address 7d6c0000 mdb: stop on SIGSEGV mdb: target stopped at: wined3d.dll.so`_Blt_ColorFill+0x15b: movb %al,(%edx)
This fails writing to d, which ends up fixed up in the signal handler, gets restarted then faults again with a segv PAGE Fault (IE Trap 14) TRAP_x86_PAGEFLT = 14, /* Page fault */
From here on the application continually fails with a page fault which is then restarted which results in an infinite loop.
To me this smells like a signalling problem, if we get a PAGE FAULT should this not be passed on to the OS so the page can be brought into core ?
Bob