Freitag, 7. September 2007, 16:53 Uhr

ktrace und kdump (strace unter Mac OS X)

Das unter GNU/Linux so nützliche Tool strace findet sich leider nicht unter Mac OS X. Glücklicherweise haben die Macher Darwin aber ktrace mitgegeben, welches die identische Aufgabe erfüllt.

Informationen dazu erhielt ich über eine Dokumentationsseite von Kaspersky sowie über eine vorzügliche Präsentation von den „Kollegen“ in Zürich.

Heute habe ich dieses Tool auf der Arbeit benutzt, um auf einem widerspenstigen PowerMac G5 1.6GHz die Applikation Software Update zu debuggen. Jedes Mal, wenn man diese Applikation über das Apfel-Menu aufrief, verbreiterte sich das freie Plätzchen im Dock für einige Hundertstelsekunden, ohne dass aber das Icon erschien. Das Programm konnte aus irgendeinem Grund nicht geladen werden.

Es war wieder einmal der Zeitpunkt gekommen, an dem ich mein geballtes Mac/Unix-Fachwissen anwenden konnte *höhö*

fs_usage

Zuerst einmal durfte sich fs_usage profilieren, indem es mir aufzeigen sollte, was die Applikation beim Start so alles an Dateien aufrief (fs_usage = „Zugriffe auf des Dateisystems“):

[dkf38-222:~] mario% sudo fs_usage | grep pdat
16:19:35  getattrlist     /System/Library/CoreServices/Software Update.app                                  0.000048   Dock        
16:19:35  lstat           /System/Library/CoreServices/Software Update.app                                  0.000031   Dock        
16:19:35  stat            /System/Library/CoreServices/Software Update.app/Contents                         0.000016   Dock        
16:19:35  open            /System/Library/CoreServices/Software Update.app/Contents/Info-macos.plist        0.000039   Dock        
16:19:35  open            /System/Library/CoreServices/Software Update.app/Contents/Info.plist              0.000018   Dock        
16:19:35  open            /System/Library/CoreServices/Software Update.app/Contents/Resources               0.000020   Dock        
16:19:35  open            Services/Software Update.app/Contents/Resources/English.lproj/InfoPlist.strings   0.000033   Dock  
16:19:35  lstat           /System/Library/CoreServices/Software Update.app                                  0.000012   Dock
16:19:35  getattrlist     /.vol/234881034/22761/Contents/Resources/Software Update.icns                     0.000019   Dock

Hmmm – irgendwie nicht das Gelbe vom Ei.

ktrace und kdump

Bevor ich ktrace anwenden konnte, musste ich zuerst das Executable innerhalb des .app-Ordners ausfindig machen (.app-Bundles – dafür sollten die seligen NeXT-Entwickler den think eMeidi Liftetime Achievement-Award erhalten):

/System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update

Mit dieser Erkenntnis ausgerüstet, konnte ich mit der Brechstange ktrace hinter den Prozess:

[dkf38-222:~] mario% sudo ktrace /System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update

Nichts geschah. Häh? Erst nach reichlichen Überlegungen und Konsultationen von Web-Sites bemerkte ich die nun in ~ liegende ktrace.out, deren man nun mit kdump die Geheimnisse entlocken musste:

[dkf38-222:~] mario% sudo kdump
   668 ktrace   RET   ktrace 0
   668 ktrace   CALL  execve(0xbffffdff,0xbffffd7c,0xbffffd84)
   668 ktrace   NAMI  "./Software Update"
   668 ktrace   RET   execve -1 errno 8 Exec format error
   668 ktrace   CALL  execve(0x9012bf18,0xbffff730,0xbffffd84)
   668 ktrace   NAMI  "/bin/sh"
   668 ktrace   NAMI  "/usr/lib/dyld"
   668 sh       RET   execve 0
   668 sh       CALL  open(0x152c,0,0)
   668 sh       NAMI  "/usr/lib/libncurses.5.dylib"
   668 sh       RET   open 4
   668 sh       CALL  fstat(0x4,0xbffffaf0)
   668 sh       RET   fstat 0
   668 sh       CALL  load_shared_file(0x152c,0x98000,0x441d8,0xbffff900,0x4,0xbffff890,0xbffff904)
   668 sh       NAMI  "/usr/lib/libncurses.5.dylib"
   668 sh       RET   load_shared_file 0
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  open(0x1560,0,0)
   668 sh       NAMI  "/usr/lib/libSystem.B.dylib"
   668 sh       RET   open 4
   668 sh       CALL  fstat(0x4,0xbffffaf0)
   668 sh       RET   fstat 0
   668 sh       CALL  load_shared_file(0x1560,0x98000,0x1ac500,0xbffff900,0x4,0xbffff890,0xbffff904)
   668 sh       NAMI  "/usr/lib/libSystem.B.dylib"
   668 sh       RET   load_shared_file 0
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  open(0x900006e8,0,0)
   668 sh       NAMI  "/usr/lib/system/libmathCommon.A.dylib"
   668 sh       RET   open 4
   668 sh       CALL  fstat(0x4,0xbffffa80)
   668 sh       RET   fstat 0
   668 sh       CALL  load_shared_file(0x900006e8,0x98000,0x6ac4,0xbffff890,0x3,0xbffff820,0xbffff894)
   668 sh       NAMI  "/usr/lib/system/libmathCommon.A.dylib"
   668 sh       RET   load_shared_file 0
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  __sysctl(0xbffffc98,0x2,0xbffffca0,0xbffffca4,0,0)
   668 sh       RET   __sysctl 0
   668 sh       CALL  sigprocmask(0x1,0,0x93a34)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  open(0x797b4,0x6,0x20000000)
   668 sh       NAMI  "/dev/tty"
   668 sh       RET   open 4
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  getuid
   668 sh       RET   getuid 0
   668 sh       CALL  getgid
   668 sh       RET   getgid 0
   668 sh       CALL  getuid
   668 sh       RET   getuid 0
   668 sh       CALL  getgid
   668 sh       RET   getgid 0
   668 sh       CALL  sigprocmask(0x1,0,0x93724)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  fstat(0x2,0xbffff960)
   668 sh       RET   fstat 0
   668 sh       CALL  fstat(0x1,0xbffff960)
   668 sh       RET   fstat 0
   668 sh       CALL  sigaction(0x14,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x14,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x2,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x2,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x3,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x3,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigprocmask(0x1,0,0x94128)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  sigaction(0x3,0xbffff910,0xbffff980)
   668 sh       RET   sigaction 0
   668 sh       CALL  __sysctl(0xbffffa20,0x2,0xbffffa80,0xbffffa28,0,0)
   668 sh       RET   __sysctl 0
   668 sh       CALL  stat(0x100ef0,0xbffff8b0)
   668 sh       NAMI  "/System/Library/CoreServices/Software Update.app/Contents/MacOS"
   668 sh       RET   stat 0
   668 sh       CALL  stat(0x79f24,0xbffff910)
   668 sh       NAMI  "."
   668 sh       RET   stat 0
   668 sh       CALL  getpid
   668 sh       RET   getpid 668/0x29c
   668 sh       CALL  getpid
   668 sh       RET   getpid 668/0x29c
   668 sh       CALL  stat(0x79f24,0xbffff8d0)
   668 sh       NAMI  "."
   668 sh       RET   stat 0
   668 sh       CALL  stat(0x1016a0,0xbffff7c0)
   668 sh       NAMI  "/bin/sh"
   668 sh       RET   stat 0
   668 sh       CALL  stat(0x1016a0,0xbffff7d0)
   668 sh       NAMI  "/bin/sh"
   668 sh       RET   stat 0
   668 sh       CALL  getpgrp
   668 sh       RET   getpgrp 668/0x29c
   668 sh       CALL  sigaction(0x14,0xbffff950,0xbffff9c0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigprocmask(0x1,0,0x93a34)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  open(0x101de0,0,0x1)
   668 sh       NAMI  "./Software Update"
   668 sh       RET   open 4
   668 sh       CALL  ioctl(0x4,FIODTYPE,0xbffffa60)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device
   668 sh       CALL  ioctl(0x4,TIOCGETA,0xbffffa30)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device
   668 sh       CALL  lseek(0x4,0,0,0x1)
   668 sh       RET   lseek 0
   668 sh       CALL  read(0x4,0xbffffac0,0x50)
   668 sh       GIO   fd 4 read 0 bytes
       ""
   668 sh       RET   read 0
   668 sh       CALL  lseek(0x4,0,0,0)
   668 sh       RET   lseek 0
   668 sh       CALL  getrlimit(0x8,0xbffff9f0)
   668 sh       RET   getrlimit 0
   668 sh       CALL  dup2(0x4,0xff)
   668 sh       RET   dup2 255/0xff
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  fcntl(0xff,0x2,0x1)
   668 sh       RET   fcntl 0
   668 sh       CALL  fcntl(0xff,0x3,0)
   668 sh       RET   fcntl 0
   668 sh       CALL  fstat(0xff,0xbffffad0)
   668 sh       RET   fstat 0
   668 sh       CALL  lseek(0xff,0,0,0x1)
   668 sh       RET   lseek 0
   668 sh       CALL  sigprocmask(0x1,0,0x93a34)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  read(0xff,0x100180,0x1)
   668 sh       GIO   fd 255 read 0 bytes
       ""
   668 sh       RET   read 0
   668 sh       CALL  exit(0)

Hmmm. Nachdem ich mich in die Prozeduren eingelesen hatte, fielen mir folgende Zeilen auf:

668 sh       CALL  ioctl(0x4,FIODTYPE,0xbffffa60)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device
   668 sh       CALL  ioctl(0x4,TIOCGETA,0xbffffa30)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device

Eine Google-Suche nach „ioctl -1 errno 25 Inappropriate ioctl for device“ ergab zwar einige Treffer, doch ich konnte mir keinen Reim daraus machen.

Netzwerk-Einstellungen?

Durch einige gefundene Seiten sensibilisiert erachtete ich nun Netzwerk-Troubles als Ursache. Was liegt da näher, als die Netzwerkeinstellungen zurückzusetzen?

Würde die Maschine unter Windows arbeiten, wären hierzu viele komische Klicks und wohl ein Abstecher in den Registry-Dschungel nötig. Unter Mac OS X hingegen beschränkte sich der Aufwand auf ein simples:

sudo rm /Library/Preferences/SystemConfiguration/preferences.plist

Beim nächsten Zugriff auf die Netzwerkeinstellunge via Apfel-Menu > Location fand ich eine jungfräuliche Netzwerkkonfiguration vor. Leider hat auch dies nichts gebracht.

tcpdump

Nun, der Feierabend rückte unaufweigerlich näher, doch ein cooles Tool wollte ich noch ausprobieren: tcpdump. Fantastisch, was nach dem Aufruf dieses Tools alles über die Shell flimmert – in einem Unternehmens-LAN hört die TCP-Party wohl nie auf *smile*

Leider gab auch dies keine Aufschlüsse über das Problem. Immerhin weiss ich jetzt, dass IP-Adressen, die mit 224.0. beginnen, ganz besondere (Multicast-)Adressen sind …

Tags: , ,
Labels: Linux

Kommentar erfassen