PackageVolumeInfo template usage results in crash on non-PM TARFS initrd

[kallisti5]

No idea what the solution is. In theory we should fall through the "apparently not packaged" if, but don't make it there.

In src/system/boot/loader/vfs.cpp

        BReference<PackageVolumeInfo> packageVolumeInfoReference(
            new(std::nothrow) PackageVolumeInfo);

In src/system/boot/loader/vfs.cpp

status_t
BootVolume::_SetTo(Directory* rootDirectory,
    PackageVolumeInfo* packageVolumeInfo,
    PackageVolumeState* packageVolumeState)
{
    TRACE(("QUACK2.0\n"));
    Unset();

    TRACE(("QUACK2.1\n"));
    if (rootDirectory == NULL)
        return B_BAD_VALUE;

    fRootDirectory = rootDirectory;
    fRootDirectory->Acquire();

    TRACE(("QUACK2.2\n"));
    // find the system directory
    Node* systemNode = fRootDirectory->Lookup("system", true);
    if (systemNode == NULL || !S_ISDIR(systemNode->Type())) {
        if (systemNode != NULL)
            systemNode->Release();
        Unset();
        return B_ENTRY_NOT_FOUND;
    }
    TRACE(("QUACK2.3\n"));

    fSystemDirectory = static_cast<Directory*>(systemNode);

    TRACE(("QUACK2.4\n"));

    if (packageVolumeInfo == NULL) {
        TRACE(("QUACK2.5.1\n"));
        // get a package volume info 
        BReference<PackageVolumeInfo> packageVolumeInfoReference(
            new(std::nothrow) PackageVolumeInfo);
        TRACE(("QUACK2.5.2\n"));
        status_t error = packageVolumeInfoReference->SetTo(fSystemDirectory,
            "packages");
        TRACE(("QUACK2.5.3\n"));
        if (error != B_OK) {
            // apparently not packaged
            return B_OK;
        }

        fPackageVolumeInfo = packageVolumeInfoReference.Detach();
    } else {
        TRACE(("QUACK2.6.1\n"));
        fPackageVolumeInfo = packageVolumeInfo;
        fPackageVolumeInfo->AcquireReference();
        TRACE(("QUACK2.6.2\n"));
    }

Result:

tarfs: "system/add-ons/kernel/boot/silicon_image_3112", 0 bytes
tarfs: "system/add-ons/kernel/boot/legacy_sata", 0 bytes
tarfs: "system/add-ons/kernel/boot/it8211", 0 bytes
tarfs: "system/add-ons/kernel/boot/uhci", 0 bytes
tarfs: "system/add-ons/kernel/boot/ohci", 0 bytes
tarfs: "system/add-ons/kernel/boot/ehci", 0 bytes
tarfs: "system/add-ons/kernel/boot/scsi_cd", 0 bytes
tarfs: "system/add-ons/kernel/boot/scsi_disk", 0 bytes
tarfs: "system/add-ons/kernel/boot/usb_disk", 0 bytes
tarfs: "system/add-ons/kernel/boot/norflash", 0 bytes
tarfs: "system/add-ons/kernel/boot/intel", 0 bytes
tarfs: "system/add-ons/kernel/boot/session", 0 bytes
tarfs: "system/add-ons/kernel/boot/attribute_overlay", 0 bytes
tarfs: "system/add-ons/kernel/boot/bfs", 0 bytes
tarfs: "system/add-ons/kernel/boot/iso9660", 0 bytes
tarfs: "system/add-ons/kernel/boot/packagefs", 0 bytes
tarfs: "system/add-ons/kernel/boot/write_overlay", 0 bytes
tarfs: "system/kernel_arm", 2165897 bytes
0x8098e1e0::Close()
0x8098e1e0::Release(), fRefCount = 2
0x8098e270::Acquire(), fRefCount = 2
QUACK1
QUACK2.0
QUACK2.1
0x8098e270::Acquire(), fRefCount = 3
QUACK2.2
0x8098e580::Acquire(), fRefCount = 2
QUACK2.3
QUACK2.4
QUACK2.5.1
<LOCKUP>

[kallisti5]

I should note, adding a "return B_OK" just above QUACK2.5.1 results in the loader getting to loading the kernel elf from the tar!

got descriptor 1 for node 0x8098f700
0x8098f700::Open()
0x8098f700::Acquire(), fRefCount = 3
could open node at 0x8098f700
0x8098f700::Release(), fRefCount = 3
load kernel kernel_arm...
elf_load_image(fd = 1, _image = 0x000ce32c)
tarfs: read at 0, 52 bytes, fSize = 2165897
<LOCKUP>

[kallisti5]

Introduced ​http://cgit.haiku-os.org/haiku/commit/src/system/boot/loader/vfs.cpp?id=5c0f8450acfa799aaf13a0e86ba8941212a6bfb3

[bonefish]

Since the PackageVolumeInfo effectively doesn't do anything, apparently the memory allocation causes the lockup. So my bet would be on a bug in the memory allocator or -- more likely -- in the ARM memory management code.

[kallisti5]

Thanks @bonefish.

The issue is that everything mapped looks valid to my eyes. Anyone see anything off? (attached boot with full mmu tracing)

[kallisti5]

mmu trace boot rpi 2

[davidkaroly]

Is this still valid? Looks like something related to the raw u-boot loader which does not exist any more.

[pulkomandy]

It probably was a too small heap size and running out of memory. Marking as not reproducible for now.