#3183 closed bug (fixed)
Memory leak using realloc functionality.
Reported by: | Jixt | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta2 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | olive@… | |
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
I've made a little program in C which first allocates memory, then fills it up. After that it reallocates memory and fills it up with extra data.
This program causes a memory leak in Haiku.
Attachments (3)
Change History (14)
by , 16 years ago
comment:1 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
There's a bug in your test. You do never reset the offset, but always increase it. This causes an ever larger realloc to be triggered which explains the memory consumption. If you reset the offset at the beginning of the while the momory consumption remains is "constant".
by , 16 years ago
Attachment: | memory_part2.c added |
---|
comment:2 by , 16 years ago
Platform: | All → x86 |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
There was indeed a bug in my test. But I have a new test. This one runs perfectly on OSX and Linux (Fedora 9) with no memory increase at all. In Haiku it is running slow and memory keeps increasing untill the test fails.
Hope this test is better.
comment:3 by , 16 years ago
Cc: | added |
---|
by , 16 years ago
Attachment: | screenshot_kernel_memory.jpeg added |
---|
ProcessController showing RAM usage
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I tested and this seems to be fixed.
comment:5 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I've tested it again and I see it is not fixed. There is no crash anymore, but CPU hits 90-100% and memory is not freed up immediately. Memory usage goes to maximum and stays like that until the test program is closed(ActivityMonitor is a good application to look at the CPU & Memory usage). This means it is not fixed.
I looked at the source code and I see you are using parts of 'hoard' (scalable memory allocator (malloc replacement) for multithreaded applications). These parts are from a decade ago. I suggest to take a look at '/haiku/trunk/src/system/libroot/posix/malloc' to see if the problem can be fixed over there.
Maybe this issue isn't big for you (which I understand), but if this is fixed it would speed up multithreaded applications. The kernel should release memory immediately when an application doesn't need it anymore. So other applications can use the freed up memory immediately. This is done in other OS's like Linux, BSD (OSX), ...
Please take a look at it.
Btw.
I've tested it on R1 alpha1 from 14 september 2009 on VMWare fusion (dual core).
comment:6 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Could you please try on a current revision before reopening ? R1 alpha1 is now very old.
comment:7 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Now I've tested it on most current nightly build 34990 (gcc4 version) & the problem is still not fixed. Please use the example attached to this ticket and run it on the latest build. There is no crash anymore, but CPU hits 90-100% and memory usage goes to max. When the example program is closed, all goes back to normal.
On other OS's, memory is freed up immediately and memory usage stays normal and doesn't hit the roof.
Please take a look at it.
comment:8 by , 15 years ago
Version: | R1/pre-alpha1 → R1/Development |
---|
comment:9 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | reopened → assigned |
comment:10 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
The test has been running on my system for over 5 minutes now, and memory usage seems to be holding pretty constant. So, this seems to be finally fixed.
comment:11 by , 5 years ago
Milestone: | R1 → R1/beta2 |
---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Memory leak example