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.
