Opened 17 years ago
Closed 17 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: | ||
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 by , 17 years ago
comment:2 by , 17 years ago
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 by , 17 years ago
Milestone: | R1 → R1/alpha1 |
---|---|
Priority: | normal → high |
Status: | new → assigned |
OK, I can reproduce the problem. I strongly suspect a leak in the registrar-side update_mime_info() code.
correction: it seems like the unzip didn't work after restarting the registrar