Re: Problems with hfsprogs on G5 Power Macs
On 08/01/2019 09:40, Frank Scheiner wrote:
> On 1/7/19 22:13, John Paul Adrian Glaubitz wrote:
>> On 1/7/19 10:09 PM, Frank Scheiner wrote:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0000000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffffffd3a8,
>>> fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
>>> 883 hfs_endian.c: No such file or directory.
>>
>> I think the debugging process would be more verbose if the
>> debugging was done in-tree of the hfsprogress source code.
>
> Oh, overlooked that part yesterday evening. Did that now:
>
> ```root@powermac-g5:~/hfsprogs/hfsprogs-332.25# gdb --args ./fsck_hfs.tproj/fsck_hfs
> -d /dev/sda2
> GNU gdb (Debian 8.2-1) 8.2
> [...]
> Reading symbols from ./fsck_hfs.tproj/fsck_hfs...done.
> (gdb) run
> Starting program: /root/hfsprogs/hfsprogs-332.25/fsck_hfs.tproj/fsck_hfs -d /dev/sda2
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".
> ** /dev/sda2
> Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
> ** Checking HFS volume.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffffffd2f8,
> fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
> 883 nextRecord = (char *)src->buffer + srcOffs[i-1];
> (gdb) bt
> #0 0x0000000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffffffd2f8,
> fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
> #1 0x0000000100032f1c in hfs_swap_BTNode (src=0x7fffffffd2f8, fcb=0x100081898,
> direction=kSwapBTNodeBigToHost) at hfs_endian.c:307
> #2 0x000000010003a478 in GetNode (btreePtr=0x100081bc8, nodeNum=1,
> nodePtr=0x7fffffffd2f8) at BTreeNodeOps.c:147
> #3 0x000000010003beb8 in SearchTree (btreePtr=0x100081bc8, searchKey=0x7fffffffd5ac,
> treePathTable=0x7fffffffd428, nodeNum=0x7fffffffd3dc, nodePtr=0x7fffffffd408,
> returnIndex=0x7fffffffd3d8) at BTreeTreeOps.c:231
> #4 0x0000000100036e20 in BTSearchRecord (filePtr=0x100081898,
> searchIterator=0x7fffffffd590, heuristicHint=4294967295, record=0x7fffffffd578,
> recordLen=0x7fffffffd866, resultIterator=0x100081c80) at BTree.c:761
> #5 0x0000000100043214 in SearchBTreeRecord (fcb=0x100081898, key=0x7fffffffd880,
> hint=0, foundKey=0x7fffffffd88c, data=0x7fffffffd898, dataSize=0x7fffffffd866,
> newHint=0x7fffffffd86c) at SBTree.c:93
> #6 0x0000000100013320 in CheckFileExtents (GPtr=0x7fffffffdfa0, fileNumber=4,
> forkType=0 '\000', attrname=0x0, extents=0x100081938, blocksUsed=0x7fffffffd980)
> at SVerify1.c:3103
> #7 0x000000010000f07c in CreateCatalogBTreeControlBlock (GPtr=0x7fffffffdfa0) at
> SVerify1.c:1095
> #8 0x000000010000b98c in ScavCtrl (GPtr=0x7fffffffdfa0, ScavOp=2,
> ScavRes=0x7fffffffdf8c) at SControl.c:395
> #9 0x000000010000b228 in CheckHFS (fsReadRef=3, fsWriteRef=4, checkLevel=2,
> repairLevel=2, logLevel=3, guiControl=0, lostAndFoundMode=0, canWrite=1,
> modified=0x100072384 <fsmodified>) at SControl.c:145
> #10 0x0000000100007b78 in checkfilesys (filesys=0x7ffffffffdcc "/dev/sda2") at
> fsck_hfs.c:323
> #11 0x000000010000787c in main (argc=0, argv=0x7ffffffffa90) at fsck_hfs.c:217
> (gdb) p src
> $1 = (BlockDescriptor *) 0x7fffffffd2f8
> (gdb) p srcDesc
> $2 = (BTNodeDescriptor *) 0x7ffff5c91200
> (gdb) p srcOffs
> $3 = (uint16_t *) 0x7ffff5c913fe
> (gdb) p sizeof(uint16_t)
> $4 = 2
> (gdb) p sizeof(BlockDescriptor)
> $5 = 32
> (gdb) p sizeof(BTNodeDescriptor)
> $6 = 14
> ```
>
> Good to know, saves me from looking up that line next time.
>
> Not sure, but at least the (uint16_t *) cast looks odd on a 48 bit address, but
> wouldn't that also look odd on a 32 bit address on a G4? But maybe it can be used
> there (on e.g. G4s) in a specific way but not on G5s.
Do you see the fsck error on all filesystems or just /dev/sda4? I'd be interested to
do a side-by-side comparison with the same filesystem image on my local G4 mini vs.
your G5 to help work out what is happening, if it's something you can make available?
ATB,
Mark.
Reply to: