Opened 11 years ago

Closed 11 years ago

#1660 closed bug (fixed)

registrar eats RAM while unzipping

Reported by: shatty Owned by: bonefish
Priority: high Milestone: R1/alpha1
Component: Servers/registrar Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

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 (4)

comment:1 Changed 11 years ago by shatty

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

comment:2 Changed 11 years 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.

comment:3 Changed 11 years ago by bonefish

Milestone: R1R1/alpha1
Priority: normalhigh
Status: newassigned

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

comment:4 Changed 11 years ago by bonefish

Resolution: fixed
Status: assignedclosed

Fixed in hrev24604.

Note: See TracTickets for help on using tickets.