Re: Problems with hfsprogs on G5 Power Macs
On 07/01/2019 19:57, Frank Scheiner wrote:
> On 1/7/19 13:10, John Paul Adrian Glaubitz wrote:
>> On 1/7/19 1:09 PM, Frank Scheiner wrote:
>>>> $ gdb --args /path/to/hfsprogs --param1 --param2
>>>>
>>>> The "--args" argument to gdb is necessary so that gdb calls the binary with
>>>> "--param1 --param2".
>>>
>>> Thanks, I'll give that a try and report the results.
>>
>> Oh, and once it crashes, type "bt" <ENTER> to get a backtrace.
>
> Ok, this is the complete output:
>
> ```
> root@powermac-g5:~# file /sbin/fsck.hfs
> /sbin/fsck.hfs: symbolic link to fsck.hfsplus
>
> root@powermac-g5:~# file /sbin/fsck.hfsplus
> /sbin/fsck.hfsplus: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco 7500,
> version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for GNU/Linux
> 3.2.0, BuildID[sha1]=a41108e28eba5c98a491785bf86e7e8ecf2c6691, with debug_info, not
> stripped
>
> root@powermac-g5:~# gdb --args /sbin/fsck.hfs -d /dev/sda2
> GNU gdb (Debian 8.2-1) 8.2
> [...]
> Reading symbols from /sbin/fsck.hfs...done.
> (gdb) run
> Starting program: /sbin/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=0x7fffffffd378,
> fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
> 883 hfs_endian.c: No such file or directory.
> (gdb) bt
> #0 0x0000000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffffffd378,
> fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
> #1 0x0000000100032f1c in hfs_swap_BTNode (src=0x7fffffffd378, fcb=0x100081898,
> direction=kSwapBTNodeBigToHost) at hfs_endian.c:307
> #2 0x000000010003a478 in GetNode (btreePtr=0x100081bc8, nodeNum=1,
> nodePtr=0x7fffffffd378) at BTreeNodeOps.c:147
> #3 0x000000010003beb8 in SearchTree (btreePtr=0x100081bc8, searchKey=0x7fffffffd62c,
> treePathTable=0x7fffffffd4a8, nodeNum=0x7fffffffd45c, nodePtr=0x7fffffffd488,
> returnIndex=0x7fffffffd458) at BTreeTreeOps.c:231
> #4 0x0000000100036e20 in BTSearchRecord (filePtr=0x100081898,
> searchIterator=0x7fffffffd610, heuristicHint=4294967295, record=0x7fffffffd5f8,
> recordLen=0x7fffffffd8e6, resultIterator=0x100081c80) at BTree.c:761
> #5 0x0000000100043214 in SearchBTreeRecord (fcb=0x100081898, key=0x7fffffffd900,
> hint=0, foundKey=0x7fffffffd90c, data=0x7fffffffd918, dataSize=0x7fffffffd8e6,
> newHint=0x7fffffffd8ec) at SBTree.c:93
> #6 0x0000000100013320 in CheckFileExtents (GPtr=0x7fffffffe020, fileNumber=4,
> forkType=0 '\000', attrname=0x0, extents=0x100081938, blocksUsed=0x7fffffffda00)
> at SVerify1.c:3103
> #7 0x000000010000f07c in CreateCatalogBTreeControlBlock (GPtr=0x7fffffffe020) at
> SVerify1.c:1095
> #8 0x000000010000b98c in ScavCtrl (GPtr=0x7fffffffe020, ScavOp=2,
> ScavRes=0x7fffffffe00c) 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=0x7ffffffffe2c "/dev/sda2") at
> fsck_hfs.c:323
> #11 0x000000010000787c in main (argc=0, argv=0x7ffffffffb10) at fsck_hfs.c:217
Interesting. So line 883 appears to be:
nextRecord = (char *)src->buffer + srcOffs[i-1];
Certainly there is some interesting pointer arithmetic going on there (and if i == 0
then you're reading something before src->buffer). Can you try the following commands
in gdb:
p src
p srcDesc
p srcOffs
p sizeof(UInt16)
ATB,
Mark.
Reply to: