wine users - Mar 2007 - Debugging Bug 5253: How to find who owns address space range?

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?

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?

Eyal Lotem <eyal.lotem@gmail.com> wrote:
> 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).
You propably already found this out on your own, but /proc/nnnn/maps
will tell you which process has what memory regions mapped.

Daniel