Opened 11 years ago

Closed 9 months ago

#3183 closed bug (fixed)

Memory leak using realloc functionality.

Reported by: Jixt Owned by: nobody
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc: olive@…
Blocked By: Blocking:
Has a Patch: no 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)

memory.c (522 bytes ) - added by Jixt 11 years ago.
Memory leak example
memory_part2.c (549 bytes ) - added by Jixt 11 years ago.
screenshot_kernel_memory.jpeg (267.3 KB ) - added by karmak 11 years ago.
ProcessController showing RAM usage

Download all attachments as: .zip

Change History (13)

by Jixt, 11 years ago

Attachment: memory.c added

Memory leak example

comment:1 by mmlr, 11 years ago

Resolution: invalid
Status: newclosed

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 Jixt, 11 years ago

Attachment: memory_part2.c added

comment:2 by Jixt, 11 years ago

Platform: Allx86
Resolution: invalid
Status: closedreopened

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 karmak, 11 years ago

Cc: olive@… added

by karmak, 11 years ago

ProcessController showing RAM usage

comment:4 by korli, 10 years ago

Resolution: fixed
Status: reopenedclosed

I tested and this seems to be fixed.

comment:5 by Jixt, 10 years ago

Resolution: fixed
Status: closedreopened

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 korli, 10 years ago

Resolution: fixed
Status: reopenedclosed

Could you please try on a current revision before reopening ? R1 alpha1 is now very old.

comment:7 by Jixt, 10 years ago

Resolution: fixed
Status: closedreopened

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 korli, 10 years ago

Version: R1/pre-alpha1R1/Development

comment:9 by axeld, 2 years ago

Owner: changed from axeld to nobody
Status: reopenedassigned

comment:10 by waddlesplash, 9 months ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.