http://bugs.winehq.org/show_bug.cgi?id=26383
--- Comment #4 from Night Nord NightNord@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?