Hello, I am trying(once again) to get Empire Earth [1] running with wine. After solving a few problems[2], I've run into a strange access violation crash. It looks like a buffer overrun, followed by a return to an invalid adress. A +relay,+snoop trace gives this: ... 0009:CALL Low-Level Engine.?Deactivate(a)GERasterizer@@UAEJXZ() ret=7e2b9a14 0009:CALL Low-Level Engine.?Dereference(a)UReferenceCounter@@QAEXXZ() ret=7e2bd6c5 0009:RET Low-Level Engine.?Dereference(a)UReferenceCounter@@QAEXXZ() retval=7f24fa70 ret=7e2bd6c5 0009:Call ntdll.RtlEnterCriticalSection(7f074a40) ret=7f0294c5 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7f0294c5 0009:Call ntdll.RtlLeaveCriticalSection(7f074a40) ret=7f029506 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7f029506 0009:CALL MSVCRT._except_handler3(<unknown, check return>) ret=7beb649b 0009:CALL MSVCRT._XcptFilter(<unknown, check return>) ret=00665947 0009:Call kernel32.GetLastError() ret=7800385f 0009:Ret kernel32.GetLastError() retval=000005b4 ret=7800385f 0009:Call kernel32.TlsGetValue(00000000) ret=7800386d 0009:Ret kernel32.TlsGetValue() retval=7f180f80 ret=7800386d 0009:Call kernel32.SetLastError(000005b4) ret=7800387e 0009:Ret kernel32.SetLastError() retval=000005b4 ret=7800387e 0009:Call kernel32.UnhandledExceptionFilter(7fc2f81c) ret=7800ed71 0009:Call ntdll.NtQueryVirtualMemory(ffffffff,9803a11c,00000000,7fc2f6e8,0000001c,7fc2f6a8) ret=7fd1aae1 0009:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7fd1aae1 0009:Call kernel32.IsBadCodePtr(7800add3) ret=22d2b743 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=22d2b743 0009:Call ntdll.NtCreateEvent(7fc2f6e8,001f0003,7fc2f6ec,00000001,00000000) ret=7fccb9b9 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=7fccb9b9 wine: Unhandled exception (thread 0009), starting debugger... ... The crash messages look a little bit different every time, with illegal instructions / access violations or even a Segmentation Fault without starting winedbg at various addreses(Attached file crashes). On very rare occasions, this crash doesn't occur, and the game continues to load and crashes later in some ddraw function. Instead of crashing it complains about a corrupted heap: err:heap:HEAP_ValidateInUseArena Heap 0x7fd80000: prev arena 0x7fe01640 is not prev for in-use 0x7fe01cb0 I've looked at a +heap trace, but I couldn't find anything usefull. (See ee-nocrash for a log). I've also attached a normal log without any special debug flags set(ee-normal.log.gz). I've added a few ERR statements for testing in some functions. So my questions are: *Am I right with my suspection that the problems are caused by a incorrect return? *How can I get a disassembly of Low-Level Engine.?Deactivate(a)GERasterizer@@UAEJXZ or simmilar functions. I didn't find this symbol. Thanks for your help, Stefan Dösinger [1] A demo is available at http://www.vugames.de/scripts/download.aspx?content=4&id=53721&nf=21&url=ftp..., but I haven't checked wheter it produces the same results. [2] Other users reported a msvc runtime error, apparently caused by an error returned by Main_DirectDraw_SetCooperativeLevel. EE calls this function with cooplevel == DDSCL_SETFOCUSWINDOW. I made the function simply return DD_OK in this case. Furthermore it checks for sound support and the OS version(setting it to Win98 or WinME is recommended) and it needs native msvcrt(It even seems to ship it's own version)
On Thu, 2005-08-11 at 21:39 +0000, Stefan Dösinger wrote:
Hello, I am trying(once again) to get Empire Earth [1] running with wine. After solving a few problems[2], I've run into a strange access violation crash. It looks like a buffer overrun, followed by a return to an invalid adress.
A +relay,+snoop trace gives this: ... 0009:CALL Low-Level Engine.?Deactivate(a)GERasterizer@@UAEJXZ() ret=7e2b9a14 0009:CALL Low-Level Engine.?Dereference(a)UReferenceCounter@@QAEXXZ() ret=7e2bd6c5 0009:RET Low-Level Engine.?Dereference(a)UReferenceCounter@@QAEXXZ() retval=7f24fa70 ret=7e2bd6c5 0009:Call ntdll.RtlEnterCriticalSection(7f074a40) ret=7f0294c5 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7f0294c5 0009:Call ntdll.RtlLeaveCriticalSection(7f074a40) ret=7f029506 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7f029506 0009:CALL MSVCRT._except_handler3(<unknown, check return>) ret=7beb649b 0009:CALL MSVCRT._XcptFilter(<unknown, check return>) ret=00665947 0009:Call kernel32.GetLastError() ret=7800385f 0009:Ret kernel32.GetLastError() retval=000005b4 ret=7800385f 0009:Call kernel32.TlsGetValue(00000000) ret=7800386d 0009:Ret kernel32.TlsGetValue() retval=7f180f80 ret=7800386d 0009:Call kernel32.SetLastError(000005b4) ret=7800387e 0009:Ret kernel32.SetLastError() retval=000005b4 ret=7800387e 0009:Call kernel32.UnhandledExceptionFilter(7fc2f81c) ret=7800ed71 0009:Call ntdll.NtQueryVirtualMemory(ffffffff,9803a11c,00000000,7fc2f6e8,0000001c,7fc2f6a8) ret=7fd1aae1 0009:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7fd1aae1 0009:Call kernel32.IsBadCodePtr(7800add3) ret=22d2b743 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=22d2b743 0009:Call ntdll.NtCreateEvent(7fc2f6e8,001f0003,7fc2f6ec,00000001,00000000) ret=7fccb9b9 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=7fccb9b9 wine: Unhandled exception (thread 0009), starting debugger... ...
The crash messages look a little bit different every time, with illegal instructions / access violations or even a Segmentation Fault without starting winedbg at various addreses(Attached file crashes). On very rare occasions, this crash doesn't occur, and the game continues to load and crashes later in some ddraw function. Instead of crashing it complains about a corrupted heap: err:heap:HEAP_ValidateInUseArena Heap 0x7fd80000: prev arena 0x7fe01640 is I've also seen similar problems with related heap functions in WinMM. I'm told that there's something wrong with the heap manager library Wine uses. not prev for in-use 0x7fe01cb0 I've looked at a +heap trace, but I couldn't find anything usefull. (See ee-nocrash for a log). I've also attached a normal log without any special debug flags set(ee-normal.log.gz). I've added a few ERR statements for testing in some functions.
So my questions are: *Am I right with my suspection that the problems are caused by a incorrect return? It's possible. I'm working on a problem like that with palm desktop. But you won't know until you debug it :) It could be nasty to fix though. *How can I get a disassembly of Low-Level Engine.?Deactivate(a)GERasterizer@@UAEJXZ or simmilar functions. I didn't find this symbol. If I had to guess, I'd say these functions are in the game itself, most likely in one or more DLLs. Your best bet here is to use a good disassembler. My personal favorite is IDA. You can find a demo version here: http://www.datarescue.be/downloaddemo.htm. This version works just fine for this sort of thing.
Thanks for your help, Stefan Dösinger
[1] A demo is available at http://www.vugames.de/scripts/download.aspx?content=4&id=53721&nf=21&url=ftp..., but I haven't checked wheter it produces the same results.
[2] Other users reported a msvc runtime error, apparently caused by an error returned by Main_DirectDraw_SetCooperativeLevel. EE calls this function with cooplevel == DDSCL_SETFOCUSWINDOW. I made the function simply return DD_OK in this case. Furthermore it checks for sound support and the OS version(setting it to Win98 or WinME is recommended) and it needs native msvcrt(It even seems to ship it's own version) I've had a few programs with this behavior. Programs ship with copies of this library to make sure that it's available, since they can't assume that it'll be there. Normally I stick with native msvcrt in pretty much all cases. I hope this advice helps.
Good Hunting ;-) James
Hi,
So my questions are: *Am I right with my suspection that the problems are caused by a incorrect return?
It's possible. I'm working on a problem like that with palm desktop. But you won't know until you debug it :) It could be nasty to fix though. I was lucky with setting a brakepoint in the wine code. The crash happens in the DDraw implementation. The return from Main_DirectDraw_Release(ddraw_main.c:154) leads to a random adress. The call which leads to this is "HeapFree(GetProcessHeap(), 0, This);" in Main_DirectDrawSurface_Destroy, surface_main.c:154. If I comment out this call, Empire Earth continues loading and crashes more or less randomly at some later points.
I've edited the IDirectDrawSurfaceImpl structure and added a 2048 byte block at the beginning and the end. This makes the crashes reliable: With the HeapFree call, the ret jumps to NULL, and without the call Empire Earth crashes little later. This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me?
*How can I get a disassembly of Low-Level Engine.?Deactivate(a)GERasterizer@@UAEJXZ or simmilar functions. I didn't find this symbol.
If I had to guess, I'd say these functions are in the game itself, most likely in one or more DLLs. Your best bet here is to use a good disassembler. My personal favorite is IDA. You can find a demo version here: http://www.datarescue.be/downloaddemo.htm. This version works just fine for this sort of thing. Yes it's a part of the game in a Dll called "low-level engine.dll". The IDA disassembler looks really great, I'm considering ordering it. But it's quite expensive.
Thanks for your help so far, Stefan
This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me?
I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer:
This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me?
I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) I've made a +ddraw,+heap,+relay,+tid,+snoop tray long ago, and it didn't bring up anything usefull to me. I'll have another look and report back.
I indeed was in doubt that ddraw or dinput are causing the problem, and I didn't find anything wrong in the DDraw code. Well, I'll see. BTW, Empire Earth crashes in exactly the same way in Cedega, where I expect the DirectX implementation to be quite different. Stefan
On Sat, 2005-08-13 at 22:15 +0000, Stefan Dösinger wrote:
I indeed was in doubt that ddraw or dinput are causing the problem, and I didn't find anything wrong in the DDraw code. Well, I'll see.
BTW, Empire Earth crashes in exactly the same way in Cedega, where I expect the DirectX implementation to be quite different.
That's not too surprising. I agree with your theory that ddraw/dinput aren't the problem. It probably has to do with some internal heap function, maybe some kind of buffer overrun somewhere. And since Cedega is basically a really old version of wine with a bunch of half-baked DX hacks in it, I would expect the crash to happen there as well. Good luck finding the cause though. ;-)
Stefan
James
Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer:
This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me?
I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) This is interesting: Setting the +heap trace flag sets the bad address realiably to 0xaaaaaaaa(without my changes to DDraw). Does this say anything?
Stefan
On Sat, 2005-08-13 at 22:35 +0000, Stefan Dösinger wrote:
Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer:
This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me?
I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) This is interesting: Setting the +heap trace flag sets the bad address realiably to 0xaaaaaaaa(without my changes to DDraw). Does this say anything?
Looks like an uninitialized value to me. I've seen similar cases like that, and that's what it was.
Stefan
James
Hi, On Sat, Aug 13, 2005 at 10:35:34PM +0000, Stefan Dösinger wrote:
Am Samstag, 13. August 2005 19:34 schrieb Lionel Ulmer:
This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me?
I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) This is interesting: Setting the +heap trace flag sets the bad address realiably to 0xaaaaaaaa(without my changes to DDraw). Does this say anything? dlls/ntdll/heap.c:#define ARENA_FREE_FILLER 0xaa
I'd guess this is an adress in an area that's actually gotten freed. Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Hi, That thing gets more and more interesting: I was mislead by the belief that 'next' would behave as 'nexti' at the end of the known C code. But obviosly it doesn't. Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: First chance exception: page fault on read access to 0xaaaaaaaa in 32-bit code (0xaaaaaaaa). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:aaaaaaaa ESP:7fc1fc58 EBP:7f2703e0 EFLAGS:00210293( - 00 RISA1C) EAX:7fe049f0 EBX:00000001 ECX:7fe01b38 EDX:7803a11c ESI:7f288aa0 EDI:7f288acc Stack dump: 0x7fc1fc58: 7dbbd6d7 7fe049f0 7f288aa0 7f2703e0 0x7fc1fc68: 00000001 7dbb1c20 7dbc59b4 00000000 0x7fc1fc78: 7f9f24fc 00000001 7fa24015 7dbc5998 0x7fc1fc88: 7fa23451 7dbc5998 7f270838 00000000 0x7fc1fc98: 00000002 7dbb9a14 7fa6bda1 00000000 0x7fc1fca8: 7fc1fd04 00000000 0052ba8b 5c575f20 Backtrace: =>1 0xaaaaaaaa (0x7f2703e0) 2 0x00000000 (0x00000000) 0xaaaaaaaa: addb %al,0x0(%eax) The surface to to release is in %eax and the 2nd element on the stack: 7fe049f0.
From the log, a few lines before the crash: warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x7fe049f0 with refcnt 1 The address of the function is taken from the surface structur and now points to 0xaaaaaaaa.
(I do not expect a reply to this mail. I write it for a few reasons: *Someone might have seen something like this allready *Someone(maybe I) might search the archives sometimes and find this information usefull. If I shouldn't do so, just tell me)
Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump:
Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Am Montag, 15. August 2005 17:07 schrieb Lionel Ulmer:
Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump:
Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Sure. The log can be found at www.doesi.gmxhome.de/ee-ddraw.log.gz (38KB)
Stefan
Am Montag, 15. August 2005 17:07 schrieb Lionel Ulmer:
Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump:
Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code.
Oh, I forgot to add that I've done a little change to the ddraw code. Empire Earth calls Main_DirectDraw_SetCooperativeLevel with cooplevel == DDSCL_SETFOCUSWINDOW and expects a successfull result. I don't think that this is related to the problem. I've also modified dlls/ntdll/heap.c to allways fill freed heap areas with 0xaaaaaaaa. Stefan
How dumb icone of wine in kde? I want to place my image when to minimize it _______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/
Hi,
Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. It looks to me that Empire Earth accidentally frees the DirectDraw Interface it's working with. During my look at the ddraw code, I've stubled accross this thing in DDRAW_Create:
{ ... driver = DDRAW_FindDriver(lpGUID); if (driver == NULL) return DDERR_INVALIDDIRECTDRAWGUID; hr = driver->create(lpGUID, &pDD, pUnkOuter, ex); if (FAILED(hr)) return hr; hr = IDirectDraw7_QueryInterface(pDD, iid, lplpDD); IDirectDraw7_Release(pDD); <-- Is this correct??? return hr; } I haven't found any useable Documentation on MSDN, because it's all archived content. But this Release Call seems odd to me. If I remove this call, Empire Earth continues loading and bails out on some string operation, which I haven't investigated yet. Stefan
Hi, I've continued my work on Empire Earth my Solution(or is it a hack that works by pure chance?) seems to work quite well, and the string operation was also easy to solve, I just may not delete the intro movie. Now I've run into the next problem: Any call to glBegin(GL_Something) crashes in the libs of my OpenGL driver(ATI fglrx) due to some NULL pointer access[1]. If I disable Hardware Acceleration, the crash doesn't occur and Empire Earth starts up to the Main Menu more or less successfully: It only shows a black screen, but it reacts to keypresses(Sounds are playing, I can take screenshots with the in-game Screen Shot Funktionality[2]. A +ddraw log can be found at http://www.doesi.gmxhome.de/ee.out.bz2 I suspect the crash and the black screen problem to have more or less the same cause somewhere in the OpenGL initialization. I will test with some other OpenGL implementations(The X.Org one and if possible the one from the nvidia driver). Does anyone have any experiance with this? Some Pointers? A few words to the Screen Shot: Appearently the screen shot is not totally black, it shows the correct mouse Pointer and the Texts are correct. It should draw a background image. The background seems not to be redrawn, so the old mouse pointer remains visible. The vertical mirroring appears only sometimes, it's perhaps also redraw related. Thanks again for your help, Stefan Dösinger PS: are there any freely downloadable Direct3D 7 games available wich are working with Wine? I'd like to test these with the somewhat strange fglrx driver. [1] Crash dump: First chance exception: page fault on read access to 0x000000d4 in 32-bit code (0x7e8b2280). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7e8b2280 ESP:5b8df1c8 EBP:5b8df1e0 EFLAGS:00210212( - 00 - RIA1) EAX:00000000 EBX:00000000 ECX:7c2926c8 EDX:0000011c ESI:00000004 EDI:7fe47b00 Stack dump: 0x5b8df1c8: 00000003 7e24dfc0 7e23945c 7c20c7c0 0x5b8df1d8: 7c20c7c0 00000004 5b8df200 7e8b1e02 0x5b8df1e8: 00000004 7e24dfc0 7e23945c 7e2394a8 0x5b8df1f8: 7e24d1d4 00000000 5b8df2cc 7e203e9c 0x5b8df208: 00000004 00000000 00000000 7e2395d3 0x5b8df218: 5b8dfed3 5b8dfb0b 5b8dfed3 00000000 Backtrace: =>1 0x7e8b2280 in atiogl_a_dri.so (+0x3a3280) (0x5b8df1e0) 2 0x7e8b1e02 in atiogl_a_dri.so (+0x3a2e02) (0x5b8df200) 3 0x7e203e9c draw_primitive_strided(This=0x7fe16ab0, d3dptPrimitiveType=0x4, d3dvtVertexType=0x152, lpD3DDrawPrimStrideData=0x5b8df308, dwVertexCount=0x4, dwIndices=0x5b8df3a8, dwIndexCount=0x6, dwFlags=0x0) [/media/usbdisk/develop/wine/dlls/ddraw/device_opengl.c:1444] in ddraw (0x5b8df2cc) 4 0x7e205304 GL_IDirect3DDeviceImpl_7_3T_DrawIndexedPrimitiveVB(iface=0x7fe16ab0, d3dptPrimitiveType=0x4, lpD3DVertexBuf=0x7fe47b00, dwStartVertex=0x0, dwNumVertices=0x4, lpwIndices=0x5b8df3a8, dwIndexCount=0x6, dwFlags=0x0) [/media/usbdisk/develop/wine/dlls/ddraw/device_opengl.c:1782] in ddraw (0x5b8df374) 5 0x7db42f41 ??0DX7Movie@@QAE(a)ABV0@@Z in dx7hrdisplay (0x5b8df3e4) 6 0x7fa60b92 ??0UIBFull@@QAE(a)KABVUString@@ABUGETextureDescription@@ABVGERectangle@@ABVUILayoutUtility@@PAVUIForm@@KKK_N(a)Z in low-level engine (0x5b8df4a8) 7 0x7fa6ca69 ?DrawBackground(a)UIForm@@MAEJABVGERectangle@@@Z in low-level engine (0x5b8df504) 8 0x7fa743dd ?AddDirtyRectangle(a)UIManager@@QAEXABVGERectangle@@PAVUIForm@@@Z in low-level engine (0x5b8df520) 9 0x005058c0 in empire earth.exe.norepe (+0x1058c0) (0x5b8df55c) 10 0x00507573 in empire earth.exe.norepe (+0x107573) (0x5b8df590) 11 0x00507104 in empire earth.exe.norepe (+0x107104) (0x00000000) 0x7e8b2280: movl 0xd4(%eax),%eax [2] Example Screenshot: www.doesi.gmxhome.de/EE000.jpg [3] www.doesi.gmxhome.de/ee.out.bz2
Hi Stefan,
Now I've run into the next problem: Any call to glBegin(GL_Something) crashes in the libs of my OpenGL driver(ATI fglrx) due to some NULL pointer access[1]. If I disable Hardware Acceleration, the crash doesn't occur and Empire Earth starts up to the Main Menu more or less successfully: It only shows a black screen, but it reacts to keypresses(Sounds are playing, I can take screenshots with the in-game Screen Shot Funktionality[2]. A +ddraw log can be found at http://www.doesi.gmxhome.de/ee.out.bz2
Perhaps you should try upgrading your fglrx drivers. They released new ones a few days ago. James
Am Montag, 22. August 2005 22:16 schrieb James Liggett:
Hi Stefan,
Now I've run into the next problem: Any call to glBegin(GL_Something) crashes in the libs of my OpenGL driver(ATI fglrx) due to some NULL pointer access[1]. If I disable Hardware Acceleration, the crash doesn't occur and Empire Earth starts up to the Main Menu more or less successfully: It only shows a black screen, but it reacts to keypresses(Sounds are playing, I can take screenshots with the in-game Screen Shot Funktionality[2]. A +ddraw log can be found at http://www.doesi.gmxhome.de/ee.out.bz2
Perhaps you should try upgrading your fglrx drivers. They released new ones a few days ago. I've seen the new driver yesterday, and I'll update it ASAP, but I don't expect it to fix this issue.
I'll try to reproduce the behaviour and write a small test for this problem and the reference counting issue. However, this may take some time... Stefan
On Tue, Aug 23, 2005 at 12:35:16PM +0000, Stefan Dösinger wrote:
I'll try to reproduce the behaviour and write a small test for this problem and the reference counting issue. However, this may take some time...
Could you do a +ddraw,+tid trace and check that all DirectX calls are done from the same thread ? If not, Wine is doing bad stuff that may lead to crashes in the GL drivers depending on the way they handle TLS and then your problem is a 'classical' one (for which the solution is still in the 'need to be done one day' phase :-) ). Lionel (back from vacation so a bit 'mail-lagged' :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Hi,
On Tue, Aug 23, 2005 at 12:35:16PM +0000, Stefan Dösinger wrote:
I'll try to reproduce the behaviour and write a small test for this problem and the reference counting issue. However, this may take some time...
Could you do a +ddraw,+tid trace and check that all DirectX calls are done from the same thread ? If not, Wine is doing bad stuff that may lead to crashes in the GL drivers depending on the way they handle TLS and then your problem is a 'classical' one (for which the solution is still in the 'need to be done one day' phase :-) ). As far as I can tell from a quick look, no. All ddraw calls are done from the same thread, there are only a few imm32 calls from another thread.
Empire Earth uses at least 2 threads, one for the sound, and another one for the rest. Perhaps there's also a third one for the DirectMusic stuff, which I have disabled in the game's config. I have noticed that it creates multiple DirectDraw and Direct3D devices, some of them are freed, re-created and freed again. At the time of the crash due to reference counting, there are at least 2 DirectDraw and 2 Direct3D objects. Is this going to work? I'll try to solve the reference counting problem first, because my first "patch" only solved the symptom, but not the cause, and I'm not sure if there are no connections between the 2 crashes. Do you still want to see a +ddraw,+tid trace? I can upload one to my homepage. Stefan
As far as I can tell from a quick look, no. All ddraw calls are done from the same thread, there are only a few imm32 calls from another thread.
OK, a shame :-)
I have noticed that it creates multiple DirectDraw and Direct3D devices, some of them are freed, re-created and freed again. At the time of the crash due to reference counting, there are at least 2 DirectDraw and 2 Direct3D objects. Is this going to work?
Well, there should be no issue with that except if there is some issue in the GL drivers about an application having multiple contexts created at the same time?
Do you still want to see a +ddraw,+tid trace? I can upload one to my homepage.
Well, if it's not multithreaded in DDraw, no need. I still have to look at your other trace with the refcounting issue to try to see where the problem lies. Lionel -- Lionel Ulmer - http://www.bbrox.org/
participants (5)
-
Andreas Mohr -
Fabio Duarte Vilas Boas -
James Liggett -
Lionel Ulmer -
Stefan Dösinger