Wine Traffic #42 For 8 May 2000 By Eric Pouech Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Mailing List Stats For This Week * Threads Covered 1. IsBadPtr and such 2. Spying tools Introduction This is the 42nd release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator). Mailing List Stats For This Week We looked at 84 posts in 236K. There were 34 different contributors. 18 posted more than once. 20 posted last week too. The top posters of the week were: * 10 posts in 61K by Alexandre Julliard * 6 posts in 13K by Uwe Bonnes * 6 posts in 13K by Marcus Meissner * 6 posts in 12K by Ulrich Weigand * 6 posts in 10K by Ove Kaaven * Full Stats 1. IsBadPtr and such Archive Link: "Problem with the new IsBad[Read|Write]Ptr() functions" People: Peter Ganten, Ulrich Weigand, Alexandre Julliard, One of Alexandre Julliard's recent patch included a rewrite of the IsBadReadPtr functions. Those functions check if a chunk of memory defined by its address and size is readable/writable... The old implementation was parsing the /proc pseudo filesystem to get the memory mappings and to derive from it if the memory chunk was mapped, and if so, with the correct attributes (read, write). Alexandre changed it to use a read/write access to that chunk protected by an exception frame. This exception frame catches all undesired accesses, and thus provides the desired behavior. Peter Ganten reported a changed behavior the loading mechanism: When COMCTL32 is loaded, PE_LoadImage() checks, if this is a system DLL (base > 2GB), which it is, and thus checks if it is already loaded at that address. This check is done by first calling IsBadReadPtr() for the base address and then comparing the content of that address with the content of the library to load. The old IsBadReadPtr() code returned true in this situation, while the new code returns false (the addresses and the relay output is identical up to this point). Most intersting is the fact, that the VirtualAlloc() call in PE_LoadImage() fails, _if_ IsBadReadPtr() has been called before. As a result, COMCTL32 will be relocated to another address and not shared, when it is loaded a second time later by the same process. COMCTL32 detects this situation and exits the process. Ulrich Weigand gave a first explanation of what went wrong: I guess what's happening here is that the base address of COMCTL32 (and the other system DLLs as well, b.t.w.) is just slightly below 3GB, and so the attempted access in IsBadReadPtr() falls into the unmapped range immediately below the Linux stack, which is mapped as VM_GROWSDOWN. Such accesses trigger automatic growing of the stack downwards to include the accessed address. Therefore, not only will the access succeed, subsequent attempts to use the range for mmap() will fail :-/ Ulrich and Alexandre discussed various solutions to solve this issue including: * mapping a dummy page to mark the end of the stack (to forbid it growing too big - as Ulrich pointed out, it would be a very bad thing if a call to IsBadReadPtr would map several of MB of stack in the address space) * change the loader behavior (this would require implementing shared segments, but this will be needed anyway) 2. Spying tools Archive Link: "Some useful info" People: , Dmitry Timoshkov Dmitry Timoshkov posted a link to some useful tools which can be of some help for people crafting Wine: http://members.xoom.com/EliCZ/import.htm (http:// members.xoom.com/EliCZ/import.htm) Sharon And Joy Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.