Johannes Holzer schrieb: > Geoff Streeter schrieb: >> At 2006-06-27 10:26 +0200, Johannes Holzer wrote: >> >> Does this program use any other memory allocation functions, like >> VirtualAlloc(), or mapped files? If it is trying to predict how much >> memory is available and then allocating address space (without >> committing it) there might not be enough address space left for new >> malloc areas. Does the program use threads? How does it determine the >> stack space requirement for its threads? >> >> There are windows routines that will enumerate the virtual memory >> allocation. Using them prior to displaying the dialog box may give you a >> lot more insight into what may be happening. Note that malloc uses these >> blocks and that it allocates reasonable sized blocks from which to serve >> up small malloc()s. >> > > Well, okay, reading this i started to create a testcase to see the > isolated problem. It seems, that the wine-malloc function behave > differently than malloc with windows. > > In the testcase: > 1. Allocate three large pieces of memory. > 2. Free the second (hopefully middle) piece of memory. > 3. Allocate the same size again. > > I expect: (3) uses the same memory pointer than the one which was freed > in (2). This is what i get under windows. > > With wine, (3) gets a new piece of memory. > This failes, if the pieces are large enough (here: 300 MB), so that > 3xMEMSIZE fits into the (virtual) memory, but not 4xMEMSIZE. tried your testcase and it works here: zero : 0x692e0020 one : 0x566c0020 two : 0x43aa0020 three: 0x566c0020 tested it on a x86 machine with 512MB ram and a x86_64 machine with 1,5GB ram. Both gave the same output. _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
