Re: Problems with hfsprogs on G5 Power Macs
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.
Cheers,
Frank
Reply to: