Opened 12 months ago
Last modified 5 weeks ago
#18663 new bug
[package_daemon] high memory usage after package activation
Reported by: | diver | Owned by: | bonefish |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Servers/package_daemon | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev57380 x86_64 on VMware Fusion.
package_daemon is using more than 100MB after installing golang
Change History (10)
comment:1 by , 11 months ago
comment:2 by , 4 months ago
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
comment:4 by , 4 months ago
Version: | R1/beta4 → R1/Development |
---|
comment:6 by , 4 months ago
According to /bin/leak_analyser.sh one need to first generate leaks file like this:
LD_PRELOAD=libroot_debug.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
comment:8 by , 3 months ago
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.
Only that package, not other transactions? Anything notable in syslog?