[Bug 26383] New: Bulletstorm: FBO removed just before bind, resulting in crash.

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

Summary: Bulletstorm: FBO removed just before bind, resulting
                    in crash.
           Product: Wine
           Version: 1.3.15
          Platform: x86-64
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: directx-d3d
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

This is next-gen of #26265 which was, mostly wrong, belived to be a duplicate
of #23048. It seems that game also affected by #23048 anyway, but futher
investigation required.

Environment: Steam installed Bulletstorm, winetricks xact physx vcrun2005 gfw
HD4570, fglrx-11.2

I'll attach two WINEDEBUG="+d3d,+d3d_caps,err+all" logs. First comes from
vanilla wine and ends with X11_CritSection hanging up. By some lines right
above hang you may see, that process actually crashed, but debugger is messed
up. Right above debugger messages, there is two lines:

trace:d3d:context_destroy_fbo_entry Destroy FBO 7
trace:d3d:context_bind_fbo glBindFramebuffer() call ok.

By trivial TRACE into context_bind_fbo you may check, that binded FBO is also
7. Fglrx seems not to have any additional checks, so it simply locks down,
dumps some garbage on screen and finally bails out. Only console-reset
(ctrl+alt+f1 and back) and wine kill may recover it from this state.

Second log is from hacked wine, with context_destory_fbo call in
context_destroy_fbo_entry commented out. As you may see, game proceeds some
futher - it shows terribly miscolored scene and suggest to "Sign In", crashing
afterwards (after trying to acquire NULL context target)

Second crash may be because a hack, but first is almost sure not-fglrx related.
Maybe nvidia just checks buffer existence before binding it? Anyway, same log
from NVidia user whould be useful.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #1 from Night Nord  2011-03-11 04:49:33 CST ---
Created an attachment (id=33597)
 --> (http://bugs.winehq.org/attachment.cgi?id=33597)
Vanilla wine crash log

Both logs are tailed to fit into wine's bugzilla.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #2 from Night Nord  2011-03-11 05:00:02 CST ---
Created an attachment (id=33598)
 --> (http://bugs.winehq.org/attachment.cgi?id=33598)
Hacked wine log

"[...]" states for "dozens of same sequences as before and after"

Last crash is definitely hack-introduced - it just runs out of FBOs after some
time, even if you don't do anything.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #3 from Henri Verbeet  2011-03-11 05:21:30 CST ---
glBindFrambuffer() should return GL_INVALID_OPERATION when a non-existing FBO
is bound, not crash, so at least that part is a bug in fglrx. Nevertheless, if
wined3d tries to use an FBO that has just been deleted that's certainly a bug.

I don't have the game, and I don't think there's a demo yet, so could you check
where we get that FBO from? Some things to check are if it's not just a
different FBO generated in context_bind_fbo() but with the same id, if the
entry is somehow the same, or if there are multiple entries with the same FBO
id.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #4 from Night Nord  2011-03-11 15:10:58 CST ---
Created an attachment (id=33601)
 --> (http://bugs.winehq.org/attachment.cgi?id=33601)
context.c traced log

Well, I've once again failed to use winedbg, it's rather tricky thing - it just
ignores my breakpoints on context_entry... So, I've just added TRACE with
arguments for every function in context.c.

First of all: it seems to be a race condition, as I've got different behaviour
depending on launch environment. Game could show a few menu frames before
crashing when run with such heavy I/O output and may work even for a few
seconds if running under winedbg.

And that's what I've found:
1) Removed fbo is from 0x14d987b8 context's entries-to-delete list
2) Just after entry is removed (and lock, probably, unlocked) context_bind_fbo
called with _another_ context, from outside, as last context.c call with this
context was too far away.
3) Pointer to variable is the same. So, almost possible, as in one case this is
pointer &entry->id, this is pointer to the same entry somehow shared between
two contexts.

Am I correct? Could entry be shared?

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #5 from Henri Verbeet  2011-03-12 00:46:55 CST ---
(In reply to comment #4)
> trace:d3d:context_apply_fbo_state context 0x14d987b8, target 36160, render_targets 0x14dae850, depth_stencil 0x2c03c4a8, location 64
> trace:d3d:context_destroy_fbo_entry context 0x14d987b8, entry 0x2ca32f00
> trace:d3d:context_destroy_fbo_entry Destroy FBO 7
> trace:d3d:context_destroy_fbo context 0x14d987b8, fbo 0x2ca32f18
> trace:d3d:context_bind_fbo context 0x18fc48, target 36160, fbo 0x2ca32f18
> trace:d3d:context_bind_fbo Binding fbo 7.
> trace:d3d:context_bind_fbo glBindFramebuffer() call ok context.c / 84
> trace:d3d:context_clean_fbo_attachments gl_info 0x18fc48, target 36160

That's not using the FBO after it has been destroyed, actually. The "Destroy
FBO 7" in context_destroy_fbo_entry() happens before the FBO is actually
destroyed. The bind you see is from context_destroy_fbo(). Looking at the log,
it seems to actually crash on the call to glFramebufferTexture2D() from
context_clean_fbo_attachments(). That looks suspiciously like bug 21540.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #6 from Night Nord  2011-03-12 07:33:32 CST ---
Ahh, I'm terribly sorry, I've mistaken with TRACE macro, so it was giving me
gl_info pointer as context's one making me confused.

Right you are, this call comes just from context_destroy_fbo and commenting it
out removes this crash. I'm sorry for my confusion and assuming this is wine
bug.

Well, ati.cchtml.com bugzilla seems to be flushed and report from bug 21540 is
lost, so, I guess, I should fill another one.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #7 from Night Nord  2011-03-12 08:28:49 CST ---
Well, only thing I'm wandering about - I've failed to reproduce the bug in
native environment. As I've got it, bug was about removing texture before
detaching it from FBO? Looking at suspicious behaviour of game after start (it
shows very garbaged, miscolored or discolored image with very low framerate)
and NaN PixelSize errors, it looks like that something terribly messed up
driver's state, so this error could be induced by something else. Maybe I
should look for possible distortion source, before filling anything into ATI's
bugzilla?

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #8 from Henri Verbeet  2011-03-12 08:38:33 CST ---
(In reply to comment #7)
> driver's state, so this error could be induced by something else. Maybe I
> should look for possible distortion source, before filling anything into ATI's
> bugzilla?

I imagine it would certainly help if you could narrow it down to a small test
case. I'd imagine some property of the texture that's attached to the FBO to be
involved, like e.g. filtering settings or number of mip levels.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

--- Comment #9 from Night Nord  2011-03-12 14:43:51 CST ---
I'm still unable to reproduce the problem in native environment. And I can't
see any point in log, when this texture is deleted.

Texture is created on level 0, internal format GL_RGBA8, format GL_BGRA, data
format GL_UNSIGNED_INT_8_8_8_8_REV. Surface received default texture parameters
(MIN/MAG_FILTER - LINEAR). I've hacked fbotexture example from mesa-progs,
making it remove texture with glDeleteTextures before detaching it from FBO,
but it still works correctly, even with texture created with similar settings
to above ones.

I have zero DirectX knowledge, so I'm completely lost into wine's code and I
don't know is there is any subtle changes or mipmaps for this texture. But this
seems to be backbuffer render surface, related to swapchain, or I've missed
something.

And I'm not sure, that we are looking at right way at all. I'll recorded a
small video [1] of in-game process (with commented clean-up call), so you may
see how it looks like. I guess something terribly wrong with the rendering
process itself, so there could be any mistake here. As just another reason for
this version - sometime game may work for a few seconds, rendering such awful
images before crashing and sometime it crashes just before first frame even
rendered. So it's not exactly permanent.

[1] http://www.youtube.com/watch?v=kKHouTCfmlk

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

Night Nord  changed:

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

--- Comment #10 from Night Nord  2011-04-29 15:39:23 CDT ---
No longer an issue on recent 11.4 beta fglrx. Therefore this is definitely was
an fglrx bug. Sorry for bugspam.

[Bug 26383] Bulletstorm: FBO removed just before bind, resulting in crash.

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

Nikolay Sivov  changed:

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

--- Comment #11 from Nikolay Sivov  2011-04-30 01:27:25 CDT ---
Closing.