I am trying to track down the source of some STATUS_ACCESS_VIOLATION in Restricted Area (http://appdb.winehq.org/objectManager.php?sClass=application&iId=8710) and I can find an seh that coincides with the freezes, but I can't figure out what is throwing it. I've pasted an example below. Any thoughts on where to go from here? Code: 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x51fde2 ip=0051fde2 tid=0009 0009:trace:seh:raise_exception info[0]=00000001 0009:trace:seh:raise_exception info[1]=0428e7b8 0009:trace:seh:raise_exception eax=00004e00 ebx=04280078 ecx=00024e56 edx=0000e740 esi=00000056 edi=0000000c 0009:trace:seh:raise_exception ebp=0032fcc0 esp=0032fcb4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210206 0009:trace:seh:call_vectored_handlers calling handler at 0x7e423680 code=c0000005 flags=0 0009:trace:seh:call_vectored_handlers handler at 0x7e423680 returned ffffffff
Burzmali wrote:> I am trying to track down the source of some STATUS_ACCESS_VIOLATION in Restricted Area (http://appdb.winehq.org/objectManager.php?sClass=application&iId=8710) and I can find an seh that coincides with the freezes, but I can't figure out what is throwing it. I've pasted an example below. Any thoughts on where to go from here? > > >Not with what you posted here. How about the complete logs on a site like pastebin.com and then the URL here. James McKenzie> >
Here's a link to the error and the prior 200 lines run with +d3d http://pastebin.com/Qqkc3gGu Here's 100 priors the with +relay http://pastebin.com/JJsDBNcs After the first seh, the system loops throwing an seh, waiting for a resolution, and then throwing the same seh again until something timeouts or breaks the deadlock or whatever. The issue always seems to raise when the application handles "context 0x32f6620"
James McKenzie wrote:> Burzmali wrote: > > > Here's a link to the error and the prior 200 lines run with +d3d http://pastebin.com/Qqkc3gGu > > > > Here's 100 priors the with +relay > > http://pastebin.com/JJsDBNcs > > > > After the first seh, the system loops throwing an seh, waiting for a resolution, and then throwing the same seh again until something timeouts or breaks the deadlock or whatever. The issue always seems to raise when the application handles "context 0x32f6620" > > > > > > > Did someone ask you to post a log with +relay? If not, please repost > the log file without it. +relay shows inter-dll communication and > generates LARGE log files (which pastebin.com will not accept) and makes > it hard to determine what triggered the first seh error. > > James McKenzieI've been working on this for a few days and the DIB (or lack thereof) is to blame. Basically, the seh I am getting is Wine flipping a flag to mark that X needs to sync. In the application, the developers choose to do something pixel by pixel, we sends the flipping locks on and off and syncing to achieve in 3 minutes what Windows does in less than a second. I'll update the bug that relates to this (http://bugs.winehq.org/show_bug.cgi?id=22968) and maybe poke through the code some more, but it isn't hopeful.