#18724 closed bug (fixed)

Unlinking files by the process does not free up space

Reported by: olegkapitonov Owned by: nobody
Priority: normal Milestone: R1/beta5
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

The problem is mainly occurs when using the Falkon browser.

  1. This browser uses RAM FS to store temporary files. When it is running, RAMFS is quickly filled to capacity, it is not released when the browser process is closed. At the same time, there are no files, but the space is occupied.
  1. If you unmount RAMFS, then Falcon starts writing the same files to the shared_memory folder on the system BeFS disk, and the same thing happens! The free space on the disk is running out, there are no files, the space is not freed up even when rebooting.
  1. The checkfs utility identifies indirect blocks that can be freed and returns space.

Running under strace gives the following sequence of system calls:

https://pastebin.com/0hZtDp4r

Attachments (3)

screenshot64.png (43.9 KB ) - added by kim1963 11 months ago.
screenshot65.png (18.4 KB ) - added by kim1963 11 months ago.
screenshot66.png (159.2 KB ) - added by kim1963 11 months ago.

Download all attachments as: .zip

Change History (7)

by kim1963, 11 months ago

Attachment: screenshot64.png added

by kim1963, 11 months ago

Attachment: screenshot65.png added

by kim1963, 11 months ago

Attachment: screenshot66.png added

comment:1 by AlienSoldier, 11 months ago

Got here from this tread: https://discuss.haiku-os.org/t/cleaning-system-resources-cache-memory/14401/16

I can attest i get this also from using Falkon. It may also explain other problem with other app but Falkon take the cake to trigger the problem. I experience it on 32 bit, so all flavor seem touched.

When shit hit the fan, i usually have 1 core in proces controler that is trough the roof and it is the kernel "low ressource manager". It continue to act that way even if i quit or kill falkon. Often i will also have only the mouse that i can move and it will move sporadiclly at that point. Only a computer reset solve that.

I barely can work more than 1 hour before having this happen. Lot of Gmail communication by email seem to cause it faster.

Last edited 11 months ago by AlienSoldier (previous) (diff)

comment:2 by olegkapitonov, 11 months ago

It seems that the problem is here, in the VFS layer of the kernel https://github.com/haiku/haiku/blob/fffd9d7dd4fa068fd0ec7700598248575fe2a692/src/system/kernel/fs/fd.cpp#L217

The reference count of the file descriptor (ref_count) should be equal to 1 here when closing the file, then the descriptor will be freed, and his vnode will be freed (because the file already unlinked by the Falkon). But in fact, ref_count == 2 here, with Falcon (with any other application everything is as it should be - ref_count=1 here). I think that somewhere a reference to this descriptor is created and mistakenly not released.

I added a hack - resetting ref_count to 1 when closing a file, here https://github.com/haiku/haiku/blob/fffd9d7dd4fa068fd0ec7700598248575fe2a692/src/system/kernel/fs/fd.cpp#L271

descriptor->ref_count = 1

Now the descriptor and his vnode are correctly released and the space is no more leaking! Falcon works fine, consumes much less memory when working, and completely frees up memory when closed! But this hack doesn't work well - the kernel randomly crashes.

comment:3 by diver, 11 months ago

Component: - GeneralSystem/Kernel

comment:4 by waddlesplash, 11 months ago

Milestone: UnscheduledR1/beta5
Resolution: fixed
Status: newclosed

Fixed merged in hrev57501.

A FD/vnode leak was what I'd guessed, but I didn't get around to investigating before X512 did, it seems. Thanks!

Note: See TracTickets for help on using tickets.