[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: wine-bugs(a)winehq.org ReportedBy: NightNord(a)gmail.com 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #1 from Night Nord <NightNord(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #2 from Night Nord <NightNord(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #3 from Henri Verbeet <hverbeet(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #4 from Night Nord <NightNord(a)gmail.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #5 from Henri Verbeet <hverbeet(a)gmail.com> 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.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #6 from Night Nord <NightNord(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #7 from Night Nord <NightNord(a)gmail.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #8 from Henri Verbeet <hverbeet(a)gmail.com> 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.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 --- Comment #9 from Night Nord <NightNord(a)gmail.com> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 Night Nord <NightNord(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #10 from Night Nord <NightNord(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26383 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #11 from Nikolay Sivov <bunglehead(a)gmail.com> 2011-04-30 01:27:25 CDT --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org