[yeah, it's glibc bug time AGAIN]
Hello all,
I just wanted to let you all know that I found what I believe to be a glibc malloc bug. (yes, this happens even with 2.4.6 and latest Debian glibc 2.2.3-6). This is the only thing I did today, BTW.
When Wine loads a very large (129 MB) exe file, it does an mmap() on it. After that it tries to do some malloc()s. That fails, which causes the entirely loading/execution of that file to abort. Thus I did malloc()/free() in a for loop after that 129 MB mmap() to test the problematic behaviour. Output: trace:module:map_image mapped PE file at 0x8051000-0xfc45000 err:virtual:VIRTUAL_CreateView now that the PE file has been mmap() /dev/zero:ed, we do some other malloc()s: malloc of 4 bytes: 0x804d878 malloc of 8 bytes: 0x804d878 malloc of 12 bytes: 0x804d878 malloc of 16 bytes: 0x804d878 malloc of 20 bytes: 0x804db20 <---- (chunk size optimization algorithm) malloc of 24 bytes: 0x804db20 <---- ("") malloc of 28 bytes: 0x804e7f8 <---- ("") malloc of 32 bytes: 0x804e7f8 malloc of 36 bytes: 0x804e7f8 . . . malloc of 10224 bytes: 0x804e7f8 malloc of 10228 bytes: 0x804e7f8 malloc of 10232 bytes: 0x804e7f8 up to 0x8050fef malloc of 10236 bytes: (nil) (0x8050ff3, which probably touches mmap() management headers) malloc of 10240 bytes: (nil) . . . malloc of 131052 bytes: (nil) malloc of 131056 (0x1fff0) bytes: (nil) ... malloc of 131060 bytes: 0x404c2008 malloc of 131064 bytes: 0x404c2008 . . .
You can clearly see that malloc() is able to squeeze up to 10232 bytes into the memory range just before the mmap()ed area, but when it gets slightly larger, it is NOT capable of switching to an entirely different memory area, throws its arms up in desperation and simply returns a shabby NULL. It only uses a new memory area in case the values get *much* larger, i.e. at least 131060 bytes.
This is a BUG. (IMHO) What else should it be ?
I already contacted Ulrich Drepper about it, and I'll hopefully get a positive reply soon.