[package_daemon] crashes in BString::eq

[diver]

hrev47099 x86_gcc2

Sometimes while building packages using haikuporter job runner thread of pacake_daemon starts to consume a lot of cpu without ever stopping.

I debugged the thread in question and it looks like it stucks comparing something in BString::eq

Restarting package_daemon makes this problem go away.

[diver]

package daemin crashed after running haikuporter which resulted in the following error:

Skipping download of source for FFmpeg
Skipping unpack of FFmpeg
Skipping patchset for FFmpeg
Cleaning up temporary directories ...
Populating source package ...
mount: Device/File/Resource busy
Command '['/bin/bash', '-c', '\n# ignore sigint but stop on every error\ntrap \'\' SIGINT\nset -e\n\nmkdir -p \\\n\tdev \\\n\tboot/system/packages \\\n\tboot/system/cache/tmp \\\n\tboot/system/packages \\\n\tboot/system/settings/etc \\\n\tport \\\n\nln -sfn /boot/system system\nln -sfn /boot/system/bin bin\nln -sfn /boot/system/package-links packages\nln -sfn /boot/system/cache/tmp tmp\nln -sfn /boot/system/settings/etc etc\nln -sfn /boot/system/var var\n\n# remove any packages that may be lying around\nrm -f boot/system/packages/*.hpkg\n\n# link the list of required packages\nfor pkg in $packages; do\n\tln -sfn "$pkg" boot/system/packages/\ndone\n\n# silently unmount if needed, just to be one the safe side\nif [ -e dev/console ]; then\n\tunmount dev\nfi\nif [ -e boot/system/bin ]; then\n\tunmount boot/system\nfi\nif [ "$(echo port/work*)" != port/work\\* ]; then\n\tunmount port\nfi\n\n# if it has been defined, mount the cross-build sysroot\nif [[ -n $crossSysrootDir ]]; then\n\tif [ -e $crossSysrootDir/boot/system/develop ]; then\n\t\tunmount $crossSysrootDir/boot/system\n\tfi\n\t# symlink haiku_cross_devel package into place\n\tmkdir -p $crossSysrootDir/boot/system/packages\n\tcrossDevelPath=/boot/system/develop/cross\n\tln -sfn \\\n\t\t$crossDevelPath/haiku_cross_devel_sysroot_$targetArchitecture.hpkg \\\n\t\t$crossSysrootDir/boot/system/packages/haiku_cross_devel_sysroot.hpkg\n\tmount -t packagefs -p "type system" $crossSysrootDir/boot/system\nfi\n\n# mount dev and system-packagefs\nmount -t bindfs -p "source /dev" dev\nmount -t packagefs -p "type system" boot/system\n\n# bind-mount the port directory to port/\nmount -t bindfs -p "source $portDir" port\n\n']' returned non-zero exit status 1

It failed to unmount /data/haikuports/media-video/ffmpeg/work-7407/boot/system which happens very often here, but doesn't result in package_daemon crash, so it might be just a coincidence.

[diver]

crash in hrev47140

[bonefish]

hrev47189 reworks the package (/file) management logic. It is possible that this issue has also been fixed. Please update, if you encounter the issue again.

[bonefish]

Regarding the failed unmounts, I added an fdinfo call in haikuporter for that case. It should print which programs are still accessing the volume in question. This might help to track the issue down.

[diver]

I can reproduce something similar in hrev47206, but i'm not 100% sure that it's the same issue. When I paste (Alt+v) the same package (I used man-1.6g-4-x86_gcc2.hpkg) several times into /system/packages directory package_daemon starts using 100% cpu.

[ttcoder]

Replying to diver:

I can reproduce something similar in hrev47206, but i'm not 100% sure that it's the same issue. When I paste (Alt+v) the same package (I used man-1.6g-4-x86_gcc2.hpkg) several times into /system/packages directory package_daemon starts using 100% cpu.

Just noticed your comment, diver... I have a "100% cpu" problem in #10819 for what it's worth.

[diver]

Can't reproduce 100% cpu usage from comment:5 in hrev47444.

When failed unmounts occur fdinfo shows either Tracker (usually it's a query window in a background) or kernel_team.

[diver]

Sometimes unmount fails, but fdinfo doesn't seem to print anything at all. I tried 5 times in a row. Renaming work-hrev50860/boot (see attached unmounting failed file) helped to resolve it.

[diver]

Haven't seen it in a while. Assuming fixed.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone