Ticket #3183 (reopened bug)

Opened 16 months ago

Last modified 2 months ago

Memory leak using realloc functionality.

Reported by: Jixt Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc: olive@…
Blocked By: Platform: x86
Blocking:

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

memory.c Download (0.5 KB) - added by Jixt 16 months ago.
Memory leak example
memory_part2.c Download (0.5 KB) - added by Jixt 16 months ago.
screenshot_kernel_memory.jpeg Download (267.3 KB) - added by karmak 15 months ago.
ProcessController showing RAM usage

Change History

Changed 16 months ago by Jixt

Memory leak example

Changed 16 months ago by mmlr

  • status changed from new to closed
  • resolution set to invalid

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".

Changed 16 months ago by Jixt

Changed 16 months ago by Jixt

  • status changed from closed to reopened
  • platform changed from All to x86
  • resolution invalid deleted

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.

Changed 16 months ago by karmak

  • cc olive@… added

Changed 15 months ago by karmak

ProcessController showing RAM usage

Changed 2 months ago by korli

  • status changed from reopened to closed
  • resolution set to fixed

I tested and this seems to be fixed.

Changed 2 months ago by Jixt

  • status changed from closed to reopened
  • resolution fixed deleted

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).

Changed 2 months ago by korli

  • status changed from reopened to closed
  • resolution set to fixed

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

Changed 2 months ago by Jixt

  • status changed from closed to reopened
  • resolution fixed deleted

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.

Changed 2 months ago by korli

  • version changed from R1/pre-alpha1 to R1/Development
Note: See TracTickets for help on using tickets.