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