Hi I have a Problem with wine. I have one Program, that allogaces many small pieces with "malloc()" in the memory. "many" means over 2 Mio, "small" means "from 8 to 128 bytes" in size. Running this Program on Windows gives me ~300MB Memory Usage (according to one of the values in the Tast manager). In Linux, "top" shows me a physical Usage of about 300MB and a virtual size of ~2.8 GB. With Linux/Wine, the program fails with an "out of memory"-Error (malloc returns NULL). Wine version is 0.9.8. Johannes Holzer
Johannes Holzer <hl.ichaus@arcor.de> wrote:> I have a Problem with wine. I have one Program, that allogaces many > small pieces with "malloc()" in the memory. "many" means over 2 Mio, > "small" means "from 8 to 128 bytes" in size. > > Running this Program on Windows gives me ~300MB Memory Usage (according > to one of the values in the Tast manager). In Linux, "top" shows me a > physical Usage of about 300MB and a virtual size of ~2.8 GB.2e06 chunks of 128 bytes gives about 244 MB. Wine needs 2.8 GB of virtual memory because it doesn't. It just needs an address space that large.> With Linux/Wine, the program fails with an "out of memory"-Error (malloc > returns NULL).If it fails, how can you tell its memory usage with top? Daniel
Geoff Streeter schrieb:> > Dumb question: Are you being bounced by ulimit? >hl@hlpc:~> ulimit unlimited hl@hlpc:~> No. I checked this a few times of course. But thanks for the reminder :-) Johannes Holzer
Daniel Skorka schrieb:> Johannes Holzer <hl.ichaus@arcor.de> wrote: >>>> With Linux/Wine, the program fails with an "out of memory"-Error (malloc >>>> returns NULL). >>> If it fails, how can you tell its memory usage with top? >> The programmer was a good one. He checked the returncode of malloc and >> displays a dialog on failure. (yes, it seems, that there is enough RAM >> for the dialog.) > > Do I understand correctly that exactly when malloc returns NULL, this > program uses about 300 MB? In other words, it fails just before it > finishes mallocing? >The code is the following: do { *ppvHeapPointer = malloc(ui32Size); if (*ppvHeapPointer == NULL) A01_vCALL_OUT_OF_MEMORY_FUNCTION(); } while (*ppvHeapPointer == NULL); A01_vCALL_OUT_OF_MEMORY_FUNCTION() displays an errormessage with the buttons "Repeat" and "Cancel". Cancel terminates the process. ui32Size has a value somewhere between 8 Bytes and 128 Bytes AFAIK. Johannes Holzer
At 2006-06-27 10:26 +0200, Johannes Holzer wrote:>Daniel Skorka schrieb: > > Johannes Holzer <hl.ichaus@arcor.de> wrote: > >>>> With Linux/Wine, the program fails with an "out of memory"-Error (malloc > >>>> returns NULL). > >>> If it fails, how can you tell its memory usage with top? > >> The programmer was a good one. He checked the returncode of malloc and > >> displays a dialog on failure. (yes, it seems, that there is enough RAM > >> for the dialog.) > > > > Do I understand correctly that exactly when malloc returns NULL, this > > program uses about 300 MB? In other words, it fails just before it > > finishes mallocing? > > >The code is the following: > > do > { > *ppvHeapPointer = malloc(ui32Size); > if (*ppvHeapPointer == NULL) A01_vCALL_OUT_OF_MEMORY_FUNCTION(); > } while (*ppvHeapPointer == NULL); > > >A01_vCALL_OUT_OF_MEMORY_FUNCTION() displays an errormessage with the >buttons "Repeat" and "Cancel". Cancel terminates the process. > >ui32Size has a value somewhere between 8 Bytes and 128 Bytes AFAIK. > >Johannes Holzer >_______________________________________________ >wine-users mailing list >wine-users@winehq.org >http://www.winehq.org/mailman/listinfo/wine-usersDoes 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.
Peter Beutner wrote:> Johannes Holzer schrieb: > > Geoff Streeter schrieb: > >> Dumb question: Are you being bounced by ulimit? > >> > > hl@hlpc:~> ulimit > > unlimited > thats just the max. file size iirc. > what you want is 'ulimit -m' or 'ulimit -a' to see all settings.hl@hlpc:~> ulimit -m unlimited hl@hlpc:~> ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 8191 virtual memory (kbytes, -v) unlimited These should be the default SuSE Configuration (SuSE Linux 10.0) Johannes
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. And here's my testcase (see Attachements): Sourcecode: hl_testcase.cpp Output (windows): stdout_windows.txt Output (wine): stdout_wine.txt I have used some debug options of wine: export WINEDEBUG=warn+all,+heap then i get a lot of debug output, here is the interesting part: ------------------------------------------------------------------ Allocating 3x 300 MB Virtual Memory... trace:heap:HEAP_FindFreeBlock created new sub-heap 0x40870000 of 12c00030 bytes for heap 0x40380000 trace:heap:RtlAllocateHeap (0x40380000,00000002,12c00000): returning 0x40870020 trace:heap:HEAP_FindFreeBlock created new sub-heap 0x53480000 of 12c00030 bytes for heap 0x40380000 trace:heap:RtlAllocateHeap (0x40380000,00000002,12c00000): returning 0x53480020 trace:heap:HEAP_FindFreeBlock created new sub-heap 0x66090000 of 12c00030 bytes for heap 0x40380000 trace:heap:RtlAllocateHeap (0x40380000,00000002,12c00000): returning 0x66090020 Freeing middle piece of memory.. trace:heap:RtlFreeHeap (0x40380000,00000002,0x53480020): returning TRUE Allocating same size again.. warn:heap:HEAP_CreateSubHeap Could not allocate 12c10000 bytes trace:heap:RtlAllocateHeap (0x40380000,00000002,12c00000): returning NULL trace:heap:RtlAllocateHeap (0x40380000,0000000a,00000024): returning 0x40395c08 Finished the memory games gcc linux native: pointeraddress on 'one' and 'three' are the same. MS Windows (bcc): pointeraddress on 'one' and 'three' are the same. Wine : pointeraddress on 'one' and 'three' differ OR malloc('three') failes. this depends on the size of the allocated memory. zero : 0x40870020 one : 0x53480020 two : 0x66090020 three: 0 ------------------------------------------------------------------ Hope you can help me with this. By the way, i get the same problems when compiling my testcase against winelib. Johannes Holzer P.S.: gcc 3.3.5 with Linux (native!) gives me the same results like windows. -------------- next part -------------- A non-text attachment was scrubbed... Name: hl_testcase.cpp Type: text/x-c++src Size: 2464 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-users/attachments/20060628/1f787327/hl_testcase-0001.cpp -------------- next part -------------- Allocating 3x 300 MB Virtual Memory... Freeing middle piece of memory.. Allocating same size again.. Finished the memory games gcc linux native: pointeraddress on 'one' and 'three' are the same. MS Windows (bcc): pointeraddress on 'one' and 'three' are the same. Wine : pointeraddress on 'one' and 'three' differ OR malloc('three') failes. this depends on the size of the allocated memory. zero : 1c20004 one : 14830004 two : 32770004 three: 14830004 Please type in a number and press return to quit: -------------- next part -------------- Allocating 3x 300 MB Virtual Memory... Freeing middle piece of memory.. Allocating same size again.. Finished the memory games gcc linux native: pointeraddress on 'one' and 'three' are the same. MS Windows (bcc): pointeraddress on 'one' and 'three' are the same. Wine : pointeraddress on 'one' and 'three' differ OR malloc('three') failes. this depends on the size of the allocated memory. zero : 0x40870020 one : 0x53480020 two : 0x66090020 three: 0 Please type in a number and press return to quit:
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.