regression with gothic1/2

[Sebastian Schlingmann]

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 
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

[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 
> 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.

[Stefan Dösinger]

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 
> > 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.

[Sebastian Schlingmann]

Am Tue, 22 Aug 2006 08:56:05 +0200
schrieb Stefan Dösinger :
> 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...

[Stefan Dösinger]

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.