On Jul 25, 2013, at 2:11 PM, Qian Hong wrote:
> On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
>> I think your Valgrind results are telling us that there's a bug in the game
>> where it's using an uninitialized stack variable.
>>
>> There's still a chance that it's something in Wine that'
On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
> I think your Valgrind results are telling us that there's a bug in the game
> where it's using an uninitialized stack variable.
>
> There's still a chance that it's something in Wine that's using the
> uninitialized variable and passing a ga
Hi Qian,
On Jul 25, 2013, at 11:53 AM, Qian Hong wrote:
> On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases wrote:
>> Hmm. You may need to mark the dummy array as volatile to prevent it from
>> being optimized away. Worth trying. You might also increase the size of
>> the array.
>
> You are ri
Hi Ken,
On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases wrote:
> Hmm. You may need to mark the dummy array as volatile to prevent it from
> being optimized away. Worth trying. You might also increase the size of the
> array.
You are right, thanks! Increasing the size of the array helps, the
m
On Jul 24, 2013, at 12:49 PM, Qian Hong wrote:
> Hi Ken,
>
> On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases wrote:
>> Instead of enabling the trace, try replacing it with something like:
>>
>>char dummy[256];
>>memset(dummy, 0x55, sizeof(dummy));
>>
>> I bet the crash will change from a
Hi Ken,
On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases wrote:
> Instead of enabling the trace, try replacing it with something like:
>
> char dummy[256];
> memset(dummy, 0x55, sizeof(dummy));
>
> I bet the crash will change from a read access to 0x0001 to 0x.
>
Thanks for the
On Sat, Jul 20, 2013 at 2:21 AM, Marcus Meissner wrote:
> Or timing ... Also can you print out refcount there to see if the refcounting
> is good?
Thanks Marcus, yes, I tried replace the TRACE to printf, to my
surprise, the magic disappear.
In other words, if I replace the TRACE in d3d9_AddRef t
Hello,
Thanks everyone's help, sorry for delay, I was blocked by something else.
I've created http://bugs.winehq.org/show_bug.cgi?id=34125 to track
down this bug.
On Fri, Jul 19, 2013 at 10:06 PM, Henri Verbeet wrote:
> Well, it sounds a bit like some form of memory corruption. Sometimes
> WINED
On Jul 19, 2013, at 8:34 AM, Qian Hong wrote:
> I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
>
> +relay,+seh,+tid log show that there are some calls to
> wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
> wined3d.wined3d_mutex_unlock before crashing, so I turn o
On Fri, Jul 19, 2013 at 04:06:56PM +0200, Henri Verbeet wrote:
> On 19 July 2013 15:34, Qian Hong wrote:
> > Further tests show that the simplest hack to avoid crashing is
> > replacing line 71 to:
> > FIXME("anything %x\n", 0xdeadbeef);
> >
> > I have no idea what the real fix is, any suggestion
On 19 July 2013 15:34, Qian Hong wrote:
> Further tests show that the simplest hack to avoid crashing is
> replacing line 71 to:
> FIXME("anything %x\n", 0xdeadbeef);
>
> I have no idea what the real fix is, any suggestion what is the next
> step to debug?
>
Well, it sounds a bit like some form of
Hello,
I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
+relay,+seh,+tid log show that there are some calls to
wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace
to get a new log in details.
To my
12 matches
Mail list logo
