http://bugs.winehq.org/show_bug.cgi?id=4078
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #12 from Luke Bratch l_bratch@yahoo.co.uk 2008-06-18 04:07:11 --- Steve, please post in Bugzilla instead of replying to wine-bugs. Email read:
"Jon, I'm not saying it's impossible but it's more likely that the tool is s= howing false hits. QuickPi has been around since 2000 and has been through = various tools including Boundschecker and others. If you can tell me addres= ses where Valgrind is complaining, perhaps I can help. Steve"
--- Comment #13 from Anastasius Focht focht@gmx.net 2008-10-25 08:10:47 --- Hello,
--- quote --- 4.5 works, but still gives similar errors. It looks like the program is buggy, but happens to work under windows due to the stack layout (i.e. maybe the stack is zeroed on windows). --- quote ---
No, the program is not buggy - it just reveals a wine shortcoming ;-)
The app seems to walk the process virtual memory map using VirtualQuery/NtQueryVirtualMemory, looking for free vm regions. If it finds them (MEM_FREE), it stores the info in a list to be later used for allocation. Failure to allocate a vm region with specific base address will force rescan/walk the vm space again.
The main problem is that wine's vm regions reported as MEM_FREE (which basically means it's not found in wine's internal list of virtual memory views) doesn't mean it's really freely available for allocation to apps (unlike windows). Some of the "free" regions are committed to linux dynamic libraries/glibc allocations (see /proc/<pid>/maps).
The app unfortunately requests some of the regions reported with MEM_FREE with a base address which wine can't mmap() exactly (conflicting addresses).
Partially mimicking memory managers in apps might not always be a good idea ...
Regards