Posts Tagged ‘Debug’

Mittwoch, 18. Dezember 2013

Schwer zu eruierende LaTeX-Kompilationsfehler debuggen

Link zu diesem Artikel

Kürzlich konnte ich ein Dokument eines aktuellen LaTeX-Projektes nicht mehr kompilieren. pdflatex brach immer mit der folgenden Fehlermeldung ab:

...
! Missing \endcsname inserted.
 
\protect 
l.75 \printbibliography[heading=none]
...

Welcher der über 300 Einträge in der Bibliographie verursachte das Problem? Erst das manuelle Eingrenzen durch radikales Löschen (natürlich mit Sicherheitskopie der .bib-Datei) von Bibliographie-Einträgen brachte schlussendlich den verantwortlichen Eintrag zu Tage: Auf Grund der Overfull \hbox-Meldungen in der Log-Datei wusste ich, zwischen welchen zwei Einträgen das Problem bestand, nicht aber, welcher der circa 30 Einträge effektiv das Problem war. Nach der Löschaktion war der Eintrag isoliert. Meine Analyse ergab, dass ich in JabRef in das Feld Language den Wert Französisch eingetragen hatte, welches beim Abspeichern der Bibliographie zu Franz{\“o}sisch wird. Offenbar mag das Paket biblatex solche Sonderzeichen in diesem Feld gar nicht und bricht stumm ab …

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. Dezember 2013

syslog-ng motzt über nicht konforme Konfigurationssyntax

Link zu diesem Artikel

Bei den gelegentlichen apt-get dist-upgrades auf meinem Linux-Server motzt syslog-ng bei jedem Neustart des Services über eine inkompatible Syntax von /etc/syslog-ng.conf:

WARNING: Configuration file format is too old, syslog-ng is running in compatibility mode Please update it to use the syslog-ng 3.5 format at your time of convinience, compatibility mode can operate less efficiently in some cases. To upgrade the configuration, please review the warnings about incompatible changes printed by syslog-ng, and once completed change the @version header at the top of the configuration file.;

Wie löst man dieses Problem? Ich bin folgendermassen vorgegangen:

  1. Zuerst passe ich die Zeichenkette in /etc/syslog-ng.conf an. Anstelle der Version 3.3 trage ich dort frech wie ich bin einfach probehalber mal folgendes ein:

    @version: 3.5
...

  2. Als nächstes prüfe ich, dass syslog-ng mit den restlichen Angaben in der Konfigurationsdatei einverstanden ist — sprich in der Datei keine Syntax-Fehler vorhanden sind:

    # syslog-ng --syntax-only

    Wird hier keine Meldung gemacht, ist alles in bester Ordnung.

  3. Schlussendlich startet man syslog-ng neu:

    /etc/init.d/syslog-ng restart

Und gut is!

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 7. Oktober 2013

Ein PHP-Script so geschwätzig wie möglich machen

Link zu diesem Artikel

<?php
	ini_set('error_reporting',E_ALL);
	ini_set('display_errors',1);

	...
?>

Tags: , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Freitag, 30. August 2013

Google Chrome unter die Haube schauen (und JSON lesbar ausgeben)

Link zu diesem Artikel

Hierzu haben die Google-Entwickler folgende URI erdacht:

chrome://net-internals/

Über diese Benutzeroberfläche lassen sich Daten auch im JSON-Format exportieren. Damit diese JSON-Daten auch für Menschen (einigermassen) lesbar werden, nimmt man Python zu Hilfe. Im nachfolgenden Beispiel gehen wir davon aus, dass der JSON-Dump in der Datei dump.json abgelegt ist:

python -mjson.tool < dump.json > dump-pretty.json

Tags: , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Freitag, 30. August 2013

urllib unter Python 3 Debug-Meldungen entlocken

Link zu diesem Artikel

Im Grunde ganz simpel – vorausgesetzt, man weiss wie (angelehnt an how to debug a urllib.urlopen in python!, wo aber noch mit urllib unter Python 2 gearbeitet wird):

import urllib.request
import http.client

http.client.debuglevel = 1
http.client.HTTPConnection.debuglevel = 1

url = 'http://www.eMeidi.com/?action=hack'
headers = {}

Request = urllib.request.Request(url,None,headers)
response = urllib.request.urlopen(Request)	
html = response.read()

Dies produziert Ausgaben in folgender Form:

send: b'GET http://www.eMeidi.com/?action=hack HTTP/1.1\r\nAccept-Encoding: iden
tity\r\nHost: www.eMeidi.com\r\nUser-Agent: Python-urllib/3.3\r\nConnection: clo
se\r\n\r\n'
reply: 'HTTP/1.0 407 Proxy Authentication Required\r\n'
header: Date header: Proxy-Authenticate header: Proxy-Connection header: Content
-Type header: Content-Length

Tags: , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 18. November 2012

Wieso Mac OS X aus seinem Schlaf aufwacht

Link zu diesem Artikel

$ syslog | grep -i "Wake reason"

Quelle: Determine Why Your Mac Wakes Up From Sleep

Tags: , , , ,
Labels: Apple

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 2. Juli 2009

lprng debuggen

Link zu diesem Artikel

Gerade habe ich eine Stunde mit debuggen von LPRng verbracht, bis ich schlussendlich feststellen musste, dass das angebliche Druckerproblem mit einem Kaltstart des Druckers (!) gelöst werden konnte.

Dennoch ist es für die Nachwelt sicherlich von Interesse, wie man LPRng im speziellen und Druckerprobleme unter Linux im allgemeinen debuggt.

lprng ausschalten

Damit man ungestörten Zugriff auf den Parallelport hat, schaltet man kurzerhand den von Debian automatisch geladenen Druckserver aus:

# /etc/init.d/lprng stop

Module überprüfen

Anschliessend überprüfen wir grundlegend, ob die Parallelporttreiber geladen wurden:

$ lsmod | grep lp
lp                     11076  0 
parport                34280  2 lp,parport_pc

Berechtigungen des Parallelports

$ ls -l /dev/lp0
crw-rw---- 1 root lp 6, 0 2009-07-02 13:07 /dev/lp0

Sieht gut aus. Falls der Port nicht existiert, legt man in anhand einer anderen auf diesem Blog publizierten Anleitung an.

Auf Parallelport drucken

# cat sample.ps > /dev/lp0

ACHTUNG: Drucker, die kein Postscript sprechen (würde ich nie mehr in meinem Leben anschaffen!), werden seitenweise kryptische Codes ausdrucken. Eine Beispieldatei im Postscript-Format findet sich unter samplec.ps

In meinem Fall beendete sich dieser Befehl auch nach 20 Sekunden nicht, weshalb ich ihn mit Ctrl+C von Hand abbrechen musste (ansonsten hat man nach 1-2 Sekunden wieder freie Hand, sofern die Postscript-Datei nicht gerade 50 MB gross ist …). Hier ging mir plötzlich ein Lichtlein auf, dass das Problem wohl nicht am Druckserver selber zu suchen war, sondern irgendwo an oder zwischen dem Drucker und dem Server lag.

lprng debuggen

Wenn bis hierhin alles geklappt hat, muss das Problem wirklich an lprng liegen. Deshalb starten wir den Druckserver im Debug-Modus:

# lpd -F -D1 >&/tmp/lprng.debug &

Ich habe Werte für D von 1, 2 und 9 ausprobiert, hat alles geklappt. In /tmp/lprng.debug werden alle Statusmeldungen akribisch aufgelistet. Anhand dieser ist es im Zusammenspiel mit Google möglich, andere Leidensgenossen zu finden und eventuell sogar die Lösung des Problems präsentiert zu erhalten.

Tags: , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 7. September 2007

ktrace und kdump (strace unter Mac OS X)

Link zu diesem Artikel

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

Keine Kommentare | neuen Kommentar verfassen

Newer Entries »