Ich hab ein kleines CLI tool in Swift geschrieben, das ich heute mit einem aktuellen Swift-Build unter Linux zum Laufen gebracht habe. Nichts großes. Ein paar Textdateien werden eingelesen, verarbeitet, verquirrlt und dann wird abschließend auf stdout, also print() Text ausgespuckt. Abgesehen von der stdlib, nur ein paar Foundation-Methoden in NSString und NSXML*, die offensichtlich schon implementiert sind. Nur eine kleine Anpassung war nötig: NSJapaneseEUCStringEncoding ist in corelibs-foundation anscheinend noch nicht implementiert.
Das ganze läuft unter OS X bestens, unter Linux eigentlich auch (sogar leicht performanter...**), allerdings schließt das unter Linux _nach_ dem kompletten Durchlauf mit einem segfault ab.

Die Fehlermeldung(en), die ich bekomme:
- Im Terminal: Speicherzugriffsfehler (Speicherabzug geschrieben)*
- In syslog: xxx[2529]: segfault at 0 ip 00007f54d943e892 sp 00007fff3a855d60 error 4 in libc-2.21.so[7f54d93ba000+1c0000]

Ich gehe von folgenden Annahmen aus:
- Das segfault unter Linux liegt nicht an meinem Code. Sonst sollte das auch unter OS X passieren.
- Das ist kein Fehler der stdlib, sondern von corelibs-foundation.
- Da wird ein free() zuviel aufgerufen.
- Das geschieht in der NSXML*-Implementierung von corelibs-foundation.
- Voodoo.

In Xcode geht's in solche Fällen einfach in den Debugger, und man kann sich den Zustand und den Callstack anschauen. Was nur macht man in so einem Fall dann unter Linux? Welche tools gibt's da?

Hat da jemand Erfahrung und kann weiterhelfen?

* Kann man irgendwie unter Linux (Ubuntu) dem Terminal beibringen Englisch zu sprechen?
** Irgendwann, wenn die Swift-Implementierung von Foundation mal weiter ist, wäre es bestimmt interessant da zu testen, wieviel die Objective-C-Runtime kostet...

Ja super, dieses 'einfach mal' liebe ich. Besonders unter Linux!

Ein export LC_ALL=C in der .bashrc hat mir gerade nicht nur C&P von host zu guest in der VM, sondern auch sonst das keybord layout zerschossen... *grrrr*

Mal sehen, wie ich da wieder rauskomme...

@nusratte
Ja, danke schön; ich bin halt ein Glückspilz... Ähh... Trotzdem... Sorry. Ich hab rumgemault... Hattest ja recht. Den Kleinkram kann man ja normalerweise auch per Google lösen. Kurz um: In dem Punkt hat mir Dein 'mach mal' zwar Sorgen bereitet, letztendlich aber doch geholfen. Jetzt habe ich den Fehler "core dumped" statt "Speichcherabzug geschrieben". Fühlt sich doch gleich viel besser an.

@gritsch
Das ganze lohnt kein zeitaufwendiges Rumgeholze per Test-Apps. Mehr oder weniger habe ich auf dieser Art und Weise ja eigentlich schon das erste Problem lokalisiert, das fehlende EUC-Encoding.

Der Linux-Teil an der Sache ist nur ein Spaßprojekt. Trotzdem würde ich gerne verstehen, wie und mit welchen Mitteln man da solche Probleme untersuchen kann...

Irgendwelche Vorschläge, welchen man dann in dem Fall verwenden könnte..?

Ein Makefile. Das Produziert nur ein Executable.


Das ist wohl die Frage: Wie kann ich unter Linux einem Swift-Binary sagen 'laß Dich debuggen'? Ich hab' da keinen Plan.

Hallo!? Ja klar. Ist da irgendwas an Dir vorbeigelaufen? Sorry, aber ich dachte, Du wüßtest daß Swift inzwischen OS ist...
swift.org/

Beinahe hätte meine Schreibtischplatte die wohl unappetitliche Bekanntschaft mit meiner Stirn gemacht. Dann ist mir aufgefallen... Ach, ist ja auch egal...

Sonst jemand?

Danke. Manchmal sieht man einfach den Wald vor lauter Bäumen nicht. Natürlich.

Mit lldb habe ich einen wunderbaren callstack bekommen. Der bestätigt auch meine Vermutung. Das Speichermanagement der aktuellen NSXML*-Implementierung in corelibs-foundation ist fehlerhaft.

Valgrind habe ich sogar selber schon mal verwendet, aber das ist Urzeiten her, und lldb hat mir ja jetzt gereicht.