[package_daemon] high memory usage after package activation

[diver]

This is hrev57380 x86_64 on VMware Fusion.

package_daemon is using more than 100MB after installing golang

[waddlesplash]

Only that package, not other transactions? Anything notable in syslog?

[diver]

Activating any large package (with many files) triggers this, just tried with a few otheres. Nothing worthy in syslog, just the usual

KERN: package_daemon: [36844112:  1706] Volume::_PackagesEntryCreated("openjdk17_jre-17.0.7.3-2-x86_64.hpkg")
KERN: package_daemon: [40074625:  1706] CommitTransactionHandler::_ChangePackageActivation(): activating 1, deactivating 0 packages
KERN: unknown: [40075614:  1706] Volume::_ChangeActivation(): 1 new packages, 0 old packages
KERN: unknown: [40079733:  1706] package "openjdk17_jre-17.0.7.3-2-x86_64.hpkg" activated

[diver]

Rebooting cuts down memory usage.

[waddlesplash]

Can you try and capture a leak_analyser trace of package_daemon?

[diver]

IIUC, before using leak_analyser.sh one need to first generate leaks file like this:

LD_PRELOAD=libroot_guarded.so MALLOC_DEBUG=es50 /system/servers/package_daemon > file

However, it crashes package_daemon:

Debug information for team /boot/system/servers/package_daemon (2264):
CPU(s): 1x Intel Core™ i7-3635QM
Memory: 1,022.88 MiB total, 507.72 MiB used
Haiku revision: hrev57823 Jul 15 2024 06:31:09 (x86_64)

Active Threads:
	thread 2265: team 2264 debug task 
	thread 2264: package_daemon (main)
		state: Call (thread 2264 tried accessing address 0x6009f3efe0 which is not allocated (base: 0x6009f3efa0, size: 88, alignment: 16, allocated by thread: 2264, freed by thread: 2264))

		Frame		IP			Function Name
		-----------------------------------------------
		00000000	0xf7bd7d9e77	_kern_debugger + 0x7 
			Disassembly:
				_kern_debugger:
				0x000000f7bd7d9e70:   48c7c0eb000000  mov $0xeb, %rax
				0x000000f7bd7d9e77:             0f05  syscall  <--

		0x7fadc4c2dbd0	0xf7bd862b8d	panic(char const*, ...) + 0xad 
		0x7fadc4c2dc30	0xf7bd8632d9	guarded_heap_segfault_handler(int, __siginfo_t*, void*) + 0x149 
		0x7fadc4c2dc40	0x7ff96329323c	commpage_signal_handler + 0x2c 
		0x7fadc4c2e180	0xf7bd8565fd	strcasecmp + 0x2d 
		0x7fadc4c2e1c0	0x1e705f826b	getrn + 0x9b 
		0x7fadc4c2e200	0x1e705f8670	OPENSSL_LH_delete + 0x20 
		0x7fadc4c2e250	0x1e706012f9	OBJ_NAME_remove + 0x59 
		0x7fadc4c2e290	0x1e705f884a	OPENSSL_LH_doall + 0x4a 
		0x7fadc4c2e2b0	0x1e706014f3	OBJ_NAME_cleanup + 0x43 
		0x7fadc4c2e2c0	0x1e705ed879	evp_cleanup_int + 0x9 
		0x7fadc4c2e2f0	0x1e705f5f79	OPENSSL_cleanup + 0xf9 
		0x7fadc4c2e340	0xf7bd851319	__cxa_finalize + 0x159 
		0x7fadc4c2e360	0xf7bd8514d2	exit + 0x12 
		0x7fadc4c2e380	0x20ac7351045	/boot/system/servers/package_daemon + 0x1e045 
		0x7fadc4c2e3c0	0x64c3de3c93	runtime_loader + 0x113 
		00000000	0x7ff963293258	commpage_thread_exit + 0 

[jackburton]

IIRC it's a known problem with openssl

[diver]

After update to openssl3 it doesn't crash anymore. However, after stopping package_daemon with launch_roster and starting it again with:

LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=es50 /system/servers/package_daemon > file

Nothing is ever being written to the file. Interestingly, in one Haiku install (VMware Fusion) dragging even a small hpkg file to /system/packages makes Haiku go out of memory within 30 seconds. While on another install (also VMware but on linux) memory usage doesn't go above 150MB even with libroot_debug.

[waddlesplash]

Is it related to installed packages perhaps?

[diver]

Still an issue as of hrev58228.