registrar eats RAM while unzipping

[shatty]

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.

[shatty]

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

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

[bonefish]

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

[bonefish]

Fixed in hrev24604.