Opened 6 months ago

Last modified 3 months ago

#15123 new bug

KDL on unpacking LibreOffice tarball

Reported by: diver Owned by: waddlesplash
Priority: normal Milestone: Unscheduled
Component: Drivers/Disk/NVMe Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

hrev53209 x86_64 in VMware Fusion.

Kernel panics when I try to build LO using haikuporter libreoffice. Sometimes it goes through without crashing but unpacked source code is incomplete (missing many folders).

Attachments (4)

kdl.png (110.6 KB ) - added by diver 6 months ago.
kdl2.png (151.4 KB ) - added by diver 6 months ago.
kdl3.png (138.7 KB ) - added by diver 6 months ago.
kdl4.png (286.6 KB ) - added by diver 4 months ago.

Download all attachments as: .zip

Change History (19)

by diver, 6 months ago

Attachment: kdl.png added

comment:1 by diver, 6 months ago

Another crash:

by diver, 6 months ago

Attachment: kdl2.png added

comment:2 by diver, 6 months ago

After reboot checksum of a tarball is wrong, so it looks like it gets corrupted. Could it be related to hrev53159? My /data partition is NVMe virtual disk.

comment:3 by diver, 6 months ago

Yet another crash:

by diver, 6 months ago

Attachment: kdl3.png added

comment:4 by diver, 6 months ago

checkfs /data after freezes Haiku while checking.

comment:5 by diver, 6 months ago

When I switched NVME to IDE in VM settings and reformatted the volume to BFS the crashes went away.

comment:6 by waddlesplash, 6 months ago

Looks like some kind of disk corruption so that's not surprising. Next time this happens please see if it occurs on IDE first, instead of just reformatting without even retesting.

comment:7 by waddlesplash, 6 months ago

I also note that the NVMe driver is not designed for non-NVMe latencies. I.e., using the NVMe driver on a drive that is really backed by a spinning disk will lead to *worse* CPU usage and access times than using IDE.

comment:8 by pulkomandy, 6 months ago

Summary: [kenel] panics on unpacking LibreOffice tarballKDL on unpacking LibreOffice tarball

comment:9 by diver, 6 months ago

VMware NVMe disk image in on a (non-NVMe) Samsung SSD EVO 860 1TB here.

Well I switched back this image in VM settings from IDE to NVMe, reformatted it and tried to unpack libreoffice translation tarball and again it wasn't unpacked completely. Running checkfs crashed to KDL with the same back trace as in the description (which was continuable).

I'm guessing this is something with nvme driver as I can't reproduce it with ata one. Or perhaps BFS driver doesn't play well with it.

wget https://github.com/LibreOffice/translations/archive/libreoffice-6.2.5.1.tar.gz
tar xzfv libreoffice-6.2.5.1.tar.gz

After unpacking check translations-libreoffice-6.2.5.1/source there should be 125 folders. If there are less it is possible that bfs has just been corrupted.

comment:10 by diver, 4 months ago

Component: System/KernelDrivers/Disk/NVMe
Owner: changed from nobody to waddlesplash

comment:11 by waddlesplash, 4 months ago

Can you reproduce these KDLs at all? Getting a syslog from such a KDL would be nice...

comment:12 by diver, 4 months ago

hrev53404 x86_64.

  • Freshly created 10GB NVMe disk in VMware mounted as /data.
  • Started building libreoffice off it and Ctrl+C after a few minutes.
  • Started checkfs /data and got a KDL.
Last edited 4 months ago by diver (previous) (diff)

comment:13 by diver, 4 months ago

Nothing in KDL syslog about nvme at all.

by diver, 4 months ago

Attachment: kdl4.png added

comment:14 by waddlesplash, 3 months ago

hrev53416 adds some better overflow checking; so please retest after that.

comment:15 by waddlesplash, 3 months ago

Diver reports this: https://imgur.com/a/yCYt2nL

So, it appears there is somehow object_cache corruption. Guess it's time I try to reproduce this under the guarded heap.

Note: See TracTickets for help on using tickets.