xbps-remove memory leakage

[xeroxslayer]

Description of the bug

It has a memory leak if certain conditions are met (eats up CPU and mem). I think a certain package update triggers the issue... or it may be just random, I don't know to be honest. It has happened on a number occasions now to just dismiss it as a random bit flip or something similar. And it has been happening for about a year now.

To be honest, I wouldn't have noticed it if I didn't ran old hardware on spinning drives with a little RAM (4GB to 8GB), but since I do, the memory leak became fairly evident. CPU goes to 100% on all cores and mem usage just keeps rising very fast (all memory is eaten up in a matter of 10, 20 seconds maybe). Of course, the system is unresponsive then. This might not be the case if you're running Void on an SSD and newer hardware, since it'll throw mem in swap fairly fast, so the system most probably will be responsive, just a bit sluggish.

I suspect a kernel update might be the event that triggers this behavior, but as I said, I'm not certain, I'll have to investigate further.

Also, if you stop the process (Ctrl + C) and run the command again, this doesn't happen. Basically, what I am certain of is that this happens only the first run of xbps-remove after an update.

The hardware setups I've noticed this mem leak was these 2.

CPU: Intel Core i7 930
MB: Intel DX58SO
RAM: 6GB (Tripple channel, 3 x 2GB DDR3 DIMMs)
HDD: 500GB (Spinning drive)

CPU: Intel Core2 Quad Q9550
MB: JW Technology JW-IG41M-HD
RAM: 4GB (Dual channel, 2 x 2GB DDR2 DIMMs)
HDD: 250GB (Spinning drive)

Steps to reproduce

1. Update (xbps-install -Suv). It's also preferable that the update also updates the kernel (see above for reason).
2. Reboot.
3. Trigger cleanup (xbps-remove -ROov).

CPU should hit the roof for about a second or so, and then drop and HDD/SSD usage should go up after that (doing the actual cleanup). That's the normal behavior. When the memory leak happens, the CPU usage never drops and mem usage just keeps rising till the system becomes unresponsive... and then you just have to restart the rig manually.

[Duncaen]

Maybe upload your /var/db/xbps/pkgdb-0.38.plist file, otherwise its hard to reproduce it without knowing what packages you have installed. Also would be useful to know when it happens in xbps-remove, like at the start, after accepting something, and/or is it reproducible with just one of the flags instead of combining all of them, like just -o.

[xeroxslayer]

Sorry for the late reply.

I can't seem to be able to find out how to reproduce it because it happens very rarely. It happened about a week ago after another update. The trouble is, I have to use just one flag and use that and wait for it to happen, maybe a year will pass before it happens again. I don't update very frequently, once every week or so.

But yes, it does happen at the beginning, just after the command starts processing. I usually just use xbps-remove -ROov to clean up everything after an update.

IDK if this is worth persuing. It's very hard to reproduce. There is definitely a leak, but it happens so rarely, I don't think it's such a big problem even if it does happen every now and then.

[Anachron]

Maybe write an alias like xbps-remove with strace to a timestamp file and then upload it when it happens again?

[xeroxslayer]

OK, that is an option, I can do that. I'll just run xbps-remove with strace each time, I can do that, it's not a problem.