Re: Debugging Bug 5253: How to find who owns address space range?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I discovered that its simply auto-generated memcpy code that storm.dll seems
to generate on-the-fly.

Yikes! KB's of repetetive esi->edi copying code. What a bizarre
optimization.

Now its very difficult to try and understand where its figuring out the size
from, in order to find the source of the problem...

Eyal Lotem wrote:

> I am trying to debug a wine crash I am having when using GDI rendering for
> Starcraft BNet (Bug 5253).  This bug does not happen in OpenGL mode, but
> my purpose is to understand the source of the bug and not to workaround
> it. (Bug link: http://bugs.winehq.org/show_bug.cgi?id=5253)
> 
> The crash is in some unrolled memcpy loop that writes to screen memory,
> and as the bug description says, crashes after it reaches the end (and
> beyond) of video memory.
> 
> The crash is at address 0x3e0594 and that address is below 0x400000 which
> is the "lowest" address of the PE executable itself. I only managed to see
> the code via gdb attachment to the live process.
> 
> I also strace'd the whole thing and saw that the range containing this
> address is mmap'd dynamically, but not from a file descriptor (-1 is the
> fd argument of mmap2 there).
> 
> I can't find any way to back-map this address to a memory region, so I
> don't
> know who "owns" this address.  Its not in wine itself, its not in the PE's
> region (400000...) and its none of the DLLs (which are mapped after the PE
> itself).
> 
> Any idea?

_______________________________________________
wine-users mailing list
wine-users@xxxxxxxxxx
http://www.winehq.org/mailman/listinfo/wine-users

[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux