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
