[Bug 11231] New: Regression since 0.9.49: glibc double free crashes all directx programs

http://bugs.winehq.org/show_bug.cgi?id=11231

Summary: Regression since 0.9.49: glibc double free crashes all
                    directx programs
           Product: Wine
           Version: 0.9.53.
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P2
         Component: directx-ddraw
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Hi,

Between 0.9.48 and 0.9.49, something broke DirectX(?)/DDraw rendering.

As a result, *all* tested games that use scalable or vector graphics now crash,
or even their installer crashes, e.g. VideoSetup.exe (Max&Mario,
Syberia2, BeetleCrazy etc.) with an error from glibc.  Old games using
bitmap graphics are not affected. GUI programs (regedit, notepad,
depends.exe) are not affected either.

This regression not only affects games, even wine's own testsuite
shows the exact same symptoms:

cd dlls/d3d8/tests; make test
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so
device.c && touch device.ok
*** glibc detected *** double free or corruption (!prev): 0x0013d100 ***
wine: Assertion failed at address 0xffffe410 (thread 0041), starting
debugger...
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so
surface.c && touch surface.ok
*** glibc detected *** free(): invalid next size (normal): 0x0013d108 ***
wine: Assertion failed at address 0xffffe410 (thread 0009), starting
debugger...
err:seh:raise_exception Unhandled exception code c000013a flags 0 addr
0xffffe410

Fail: 0.9.49, .50, .51, .52, .53
Work: 0.9.47, 0.9.48 (and older), urlmon/tests/

Both d3d8/tests and d3d9/tests fail.

I'm using Ubuntu 6.06 LTS (aka. Dapper) with packages:
freeglut 2.4.0-4
libgl1-mesa 6.4.1-0ubuntu8      (has /usr/lib/libGL.so.1.2)
libglu1-mesa 6.4.1-0ubuntu8     (has /usr/lib/libGLU.so.1.3.060401)
libglibb2.0-0 (2.10.3-0ubuntu1) (has /usr/lib/libglib-2.0.so.0.1000.3)
kernel 2.6.15-29-686 (sometimes also 2.6.15-28-686)
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
getconf GNU_LIBPTHREAD_VERSION  -> NPTL 2.3.6

This does not seem to be the infamous "winecfg crashes in winecfg audio tab"
bug http://bugs.winehq.org/show_bug.cgi?id=5826

Researching this bug, I found a message about
"an old C++ error" export MALLOC_CHECK_=0
That did not help.

Starting with a vanilla .wine/ doesn't help either:
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so
d3d8_main.c && touch d3d8_main.ok
wine: creating configuration directory '/home/hoehle/.wine'...
ALSA lib seq_hw.c:456:(snd_seq_hw_open) open /dev/snd/seq failed: No such file
or directory
Could not load Mozilla. HTML rendering will be disabled.
wine: '/home/hoehle/.wine' created successfully.
... [same as before]

I can exclude that the bug is caused by a change in my laptop
configuration. I have several source trees of wine, newly configured &
make'd, any only 0.9.49 and up fail the tests.

BTW, why does wine say "starting debugger..." yet no one appears? The
line about "err:seh:raise_exception" appears only approx. half a
minute after the "starting debugger..." line -- sometimes never and wine just
hangs.

Regards,
 Jörg Höhle

[Bug 11231] Regression since 0.9.49: glibc double free crashes all directx programs

http://bugs.winehq.org/show_bug.cgi?id=11231

Alexander Dorofeyev  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Alexander Dorofeyev   2008-01-17 06:03:24 ---
There's a high likelyhood the problem is on your system, I think. I've never
seen something like that on my machine and I was running ddraw/d3d tests. And,
of course, other people run tests too and the package maintainer constantly
runs all tests.

Besides, when ddraw or d3d code corrupts the heap (I had actual cases like
that), usually the problems pop up not in glibc, but in wine's own heap API,
because ddraw/d3d code doesn't use glibc free etc directly, but it uses wine's
heap functions HeapAlloc/HeapFree.

[Bug 11231] Regression since 0.9.49: glibc double free crashes all directx programs

http://bugs.winehq.org/show_bug.cgi?id=11231

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #2 from Dan Kegel   2008-01-17 06:11:28 ---
http://kegel.com/wine/valgrind/logs-2007-12-14/vg-d3d8_device.txt
shows there's been an undefined memory reference
in that test for some time, perhaps that's related.

What graphics card and X driver are you using?

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |major
           Keywords|                            |regression
            Summary|Regression since 0.9.49:    |d3d8 tests fail with mesa
                   |glibc double free crashes   |OpenGL driver
                   |all directx programs        |

--- Comment #3 from Vitaliy Margolen   2008-01-17 14:13:43 ---
Not a blocker. What video card and drivers?

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #4 from Jörg Höhle   2008-01-18 04:06:37 ---
> There's a high likelyhood the problem is on your system,

I feared that. Otherwise 100000 wine users & testers would have complained
before me :-) OTOH, I'm hopefully not the only Ubuntu 6.06 = Dapper laptop &
wine user with on-board Intel i810 graphics.
> What graphics card and X driver are you using?

Intel i810 onboard -- "Chipset 852GM/855GM found". No ATI, no NVidia.
This chip provides HW-3D accelaration, e.g. tuxkart, tux/planetpenguinracer
work fine. However Max&Mario is a game that (presumably) uses no 3D.
I have attached a snippet of my Xorg.0.log.

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #5 from Jörg Höhle   2008-01-18 04:11:25 ---
Created an attachment (id=10337)
 --> (http://bugs.winehq.org/attachment.cgi?id=10337)
part of Xorg.0.log relevant to i810

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #6 from Alexander Dorofeyev   2008-01-18 07:09:22 ---
Jorg, there was a discussion of mesa drivers recently on #winehackers and
Stefan Dosinger said random memory corruption happens with several mesa
drivers. So this can explain issues with 3d games and tests like yours.

Do you use DirectDrawRenderer=opengl registry setting? This would explain
problems in 2D only apps.

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #7 from Jörg Höhle   2008-01-25 04:04:32 ---
> Do you use DirectDrawRenderer=opengl

I have not explicitly set it. make tests creates a .wine from scratch if not
already present so wine uses all default settings.

I changed it to gdi as by:
http://wiki.winehq.org/UsefulRegistryKeys
with no improvement:
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so
device.c && touch device.ok
*** glibc detected *** double free or corruption (!prev):
> random memory corruption happens with several mesa drivers

That might be it. I booted the older Breezy (2005.10) instead of Dapper
(2006.06) and the d3d8 tests succeeded (on the same binary, without
recompilation). [d3d9 crashes but that's likely another story.]

I also booted Gutsy (2007.10) from a live CD, and d3d8 passed the tests also.

So the summary becomes: wine >= 0.9.49 is unusable with gfx applications with
Ubuntu Dapper with the xorg intel i810 driver and/or(?) the Dapper version of
the Mesa libraries.
Is that precise enough? Could any other Ubuntu Dapper user please comment on
it?

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #8 from Jörg Höhle   2008-01-25 04:05:20 ---
Oddly,
$ WINEDEBUG=trace+gdi make test
does not report any glibc error (0.9.53 source tree). Instead I see:
[...]
trace:gdi:GDI_ReleaseObj (0x1d8): leave 1
wine: Unhandled page fault on write access to 0x00000000 at address 0x601ae335
(thread 0009), starting debugger...
Unhandled exception: page fault on write access to 0x00000000 in 32-bit code
(0x601ae335).
=>1 0x601ae335 cfree+0x75() in libc.so.6 (0x0034f548)
  2 0x60b7ebdb _mesa_free+0x1d() in i915_dri.so (0x0034f558)
  3 0x60c34716 _mesa_delete_program+0x26() in i915_dri.so (0x0034f578)
  4 0x60c35d25 _mesa_DeletePrograms+0x131() in i915_dri.so (0x0034f5a8)
  5 0x60ab030d glDeleteProgramsARB+0x31() in libgl.so.1 (0x0034f5c8)
  6 0x64b6a9e8 IWineD3DImpl_FillGLCaps+0x8051(gl_info=0x64c05f4c)
[.../wine/dlls/wined3d/directx.c:448] in wined3d (0x0034f768)
  7 0x64b6fda9 InitAdapters+0x1ee7() [.../wine/dlls/wined3d/directx.c:3097] in
wined3d (0x0034fb88)

I remember in the past (in a different context) already observing different
behaviour between using or not WINEDEBUG. How comes? What must one consider in
order not to interfere with program execution?

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #9 from Jörg Höhle   2008-01-25 04:09:22 ---
Created an attachment (id=10436)
 --> (http://bugs.winehq.org/attachment.cgi?id=10436)
WINEDEBUG=trace+d3d

A case of
*** glibc detected *** double free or corruption (!prev): 0x0013d6e8 ***
with d3d tracing

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #10 from Jörg Höhle   2008-01-25 05:04:00 ---
The above backtrace hinted at .../wine/dlls/wined3d/directx.c:448
(test_arb_vs_offset_limit) so I attached a trace of WINEDEBUG=trace+d3d.

Indeed the crash is is in glDeleteProgramsARB()
    GL_EXTCALL(glBindProgramARB(GL_VERTEX_PROGRAM_ARB, 0));
    GL_EXTCALL(glDeleteProgramsARB(1, &prog));
    checkGLcall("ARB vp offset limit test cleanup\n");
Still, with trace+gdi, the glibc message vanishes and turns into a page fault
on write access to 0x00000000 (see previous post). I don't understand why.

Regards,
 Jörg Höhle

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #11 from Alexander Dorofeyev   2008-01-25 11:02:34 ---
> I remember in the past (in a different context) already observing different
> behaviour between using or not WINEDEBUG. How comes? What must one consider in
> order not to interfere with program execution?

Well that's pretty normal with memory/heap corruption cases (worst kind of bugs
IMO). Sometimes it crashes in one place, sometimes in another, at times it can
even sort of successfully run. It depends on all kinds of things and it often
crashes in a completely different place instead of where the real damage has
been done. There's little that can be done to ensure consistent behavior, but
AFAIK WINEDEBUG=+heap *may* help, because it enforces some additional checks
here and there, so if the heap is becoming corrupted, at least with some luck
it may detect it earlier (closer to the actual spot where this happens).

Regarding test_arb_vs_offset_limit - there are known problems with it, see
bug#11210. IIRC the reporter is Intel driver developer. So, if it crashes
there, it may be a different problem from other memory corruptions.
> I have not explicitly set it. make tests creates a .wine from scratch if not
> already present so wine uses all default settings.

Test aside, what was used for 2D ddraw games that crashed? Could it be that
ddraw renderer was opengl?

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #12 from Dan Kegel   2008-01-26 01:39:26 ---
Valgrind can be very useful when tracking down memory corruption bugs, too.

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |testcase

--- Comment #13 from Austin English   2008-05-16 16:21:45 ---
Is this still an issue in current (1.0-rc1 or newer) wine?

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

--- Comment #14 from Jörg Höhle   2008-05-26 18:18:10 ---
With 1.0rc2, Ubuntu Dappper and Intel I still observe a crash and backtrace
involving MESA as shown in comment #8, so my summary of the situation in
comment #7 still applies. As it's very likely a bug in MESA, you may wish to
close this issue and mark it as "Not My Bug" -- or leave it open so that Ubuntu
Dapper users find it. Ubuntu Gutsy and Hardy are not affected.

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #15 from Austin English   2008-11-23 15:39:10 ---
Not wine bug.

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #16 from Austin English   2008-11-23 15:49:48 ---
Closing.

[Bug 11231] d3d8 tests fail with mesa OpenGL driver

http://bugs.winehq.org/show_bug.cgi?id=11231

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|directx-ddraw               |directx-d3d