Ticket #1660 (closed bug: fixed)

Opened 13 months ago

Last modified 10 months ago

registrar eats RAM while unzipping

Reported by: shatty Owned by: bonefish
Priority: high Milestone: R1/alpha1
Component: Servers/registrar Version: R1 development
Cc: Blocked By:
Platform: x86 Blocking:

Description

I created a zip file of the haiku sources and added it to my haiku image. After starting my haiku image in vmware, I tried to unzip the zip file. As the file unzipped, the registrar consumed more and more memory until eventually haiku crashed.

I noticed that if I unzip part of my large zip file, it will consume memory and not free it when the unzip is finished. (assuming the unzip succeeds)

I tried killing the registrar and restarting it. It said: "REG: Registrar::ReadToRun(): Failed to init messaging service (that's by design when running under R5): Invalid Argument"

After doing this, I was able to unzip the file without the registrar consuming any memory.

Change History

Changed 13 months ago by shatty

correction: it seems like the unzip didn't work after restarting the registrar

Changed 13 months ago by bonefish

Killing and restarting the registrar is not really an option in a running system. Running applications will definitely lose inter-app communication, clipboard, MIME DB support, message runners. Not sure what effect it would have on new applications (unzip would be one, BTW).

Anyway, the only thing I can think of ATM, which might cause the registrar to consume memory when unzipping something is the messaging service, which delivers node monitoring and query notification messages. It buffers a rather comforable amount of up to 10000 messages or 50 MB per existing full port.

Other than that there may be a leak in update_mime_info(), which is apparently called by unzip on each file, if the archive was not created under BeOS.

Changed 10 months ago by bonefish

  • priority changed from normal to high
  • status changed from new to assigned
  • milestone changed from R1 to R1/alpha1

OK, I can reproduce the problem. I strongly suspect a leak in the registrar-side update_mime_info() code.

Changed 10 months ago by bonefish

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

Fixed in r24604.

Note: See TracTickets for help on using tickets.