regression with gothic1/2
Hi everybody, I noticed yesterday that the gothic 1/2 demos don't work anymore. Console output is the following: ... err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bc7ef44 "loader.c: loader_section" wait timed out in thread 0009, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000d, blocked by 0009, retrying (60 sec) ... A regression test came up with the following result: $ git bisect bad 13163349521e50e7039e188a22b6a814dcfcfc37 is first bad commit commit 13163349521e50e7039e188a22b6a814dcfcfc37 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Jul 21 11:53:24 2006 +0200 ntdll: Add a few more free list entries to the heap. :040000 040000 dba2d276a01c6d148826a913f4163e0db0ed4689 eb1abe2301ff4698ac939b7e1b1fa225ceca4338 M dlls I can provide traces and additional info if needed. Bye Sebastian
On Mon, 2006-08-21 at 15:13 +0200, Sebastian Schlingmann wrote:
Hi everybody,
I noticed yesterday that the gothic 1/2 demos don't work anymore.
Console output is the following:
... err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bc7ef44 "loader.c: loader_section" wait timed out in thread 0009, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000d, blocked by 0009, retrying (60 sec) ...
A regression test came up with the following result:
$ git bisect bad 13163349521e50e7039e188a22b6a814dcfcfc37 is first bad commit commit 13163349521e50e7039e188a22b6a814dcfcfc37 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Jul 21 11:53:24 2006 +0200
ntdll: Add a few more free list entries to the heap.
:040000 040000 dba2d276a01c6d148826a913f4163e0db0ed4689 eb1abe2301ff4698ac939b7e1b1fa225ceca4338 M dlls
I can provide traces and additional info if needed.
Bye Sebastian
I cannot tell you why, but I have found the same patch to introduce a regression (in a positive way, my app now runs) as well (it crashes when using WINEDEBUG=+heap though). The only logic I can see is that heap-errors are now more easily triggered, but I guess AJ has to comment on that. The patch in itself should not introduce heap related errors AFAIK. Cheers, Paul.
Am Montag 21 August 2006 19:22 schrieb Paul Vriens:
On Mon, 2006-08-21 at 15:13 +0200, Sebastian Schlingmann wrote:
Hi everybody,
I noticed yesterday that the gothic 1/2 demos don't work anymore.
Console output is the following:
... err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bc7ef44 "loader.c: loader_section" wait timed out in thread 0009, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000d, blocked by 0009, retrying (60 sec) ...
A regression test came up with the following result:
$ git bisect bad 13163349521e50e7039e188a22b6a814dcfcfc37 is first bad commit commit 13163349521e50e7039e188a22b6a814dcfcfc37 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Jul 21 11:53:24 2006 +0200
ntdll: Add a few more free list entries to the heap.
:040000 040000 dba2d276a01c6d148826a913f4163e0db0ed4689
eb1abe2301ff4698ac939b7e1b1fa225ceca4338 M dlls
I can provide traces and additional info if needed.
Bye Sebastian
I cannot tell you why, but I have found the same patch to introduce a regression (in a positive way, my app now runs) as well (it crashes when using WINEDEBUG=+heap though).
The only logic I can see is that heap-errors are now more easily triggered, but I guess AJ has to comment on that. This is odd, I did a regression testing and it came up with Jason Greens dynamic shader constant patch as the first bad commit. While this sounds odd for a d3d7 game it could happen because of broken stateblock initialization.
With a enabling the heap filler I ended ap with a crash in dmusic(altough music in the game is disabled), using native dmusic made the game working again.
Am Tue, 22 Aug 2006 08:56:05 +0200 schrieb Stefan Dösinger <stefandoesinger(a)gmx.at>:
This is odd, I did a regression testing and it came up with Jason Greens dynamic shader constant patch as the first bad commit. While this sounds odd for a d3d7 game it could happen because of broken stateblock initialization.
With a enabling the heap filler I ended ap with a crash in dmusic(altough music in the game is disabled), using native dmusic made the game working again.
You are right - with native dmusic,dmloader,dmime,dmsynth the game runs. I also had some dmusic/dmime output with the heap error, but that looked quite normal. Strange though that my regression testing had a different result. I did it just like the GitWine entry in the wiki suggests...
Hi,
You are right - with native dmusic,dmloader,dmime,dmsynth the game runs. I also had some dmusic/dmime output with the heap error, but that looked quite normal.
Strange though that my regression testing had a different result. I did it just like the GitWine entry in the wiki suggests... The error occurs only sporadic, sometimes it works with native dmusic & friends stuff. I guess that sometimes it started successfully even though the bad patch was in.
participants (3)
-
Paul Vriens -
Sebastian Schlingmann -
Stefan Dösinger