2015-11-07 18 views
14

Ich arbeite an einem Patch für FFmpeg und muss meinen Code debuggen. Ich lade eine externe Bibliothek, und um verschiedene Bibliotheksversionen zu testen, habe ich sie in verschiedenen Ordnern. Um auszuwählen, welchen ich verwenden möchte, habe ich DYLD_LIBRARY_PATH=/path/to/lib/dir ./ffmpeg verwendet und das funktioniert in Ordnung. Aber wenn ich es innerhalb lldb versuche, stürzt es ab und sagt dyld: Library not loaded und Reason: image not found. Dies funktioniert früher als Xcode 7.1, aber ich habe gerade erst ein Upgrade durchgeführt und es funktioniert nicht mehr.Warum leitet lldb meine Umgebungsvariable nicht weiter?


Hier ist meine MVCE:

#include <stdio.h> 
#include <stdlib.h> 

int main() { 
    char* str = getenv("DYLD_LIBRARY_PATH"); 
    if (str) puts(str); 
    else  puts("(null)"); 
    return 0; 
} 

Das Ausführen dieses Programms wie folgt erzeugt die Ausgabe:

$ ./a.out 
(null) 
$ DYLD_LIBRARY_PATH=/tmp ./a.out 
/tmp 

das in Ordnung aussieht. Aber wenn ich versuche zu verwenden LLDB es fehlschlägt:

$ DYLD_LIBRARY_PATH=/tmp lldb ./a.out 
(lldb) target create "./a.out" 
Current executable set to './a.out' (x86_64). 
(lldb) run 
Process 54255 launched: './a.out' (x86_64) 
(null) 
Process 54255 exited with status = 0 (0x00000000) 

Der Versuch, die Umgebungsvariable zu setzen innen LLDB funktioniert:

lldb ./a.out 
(lldb) target create "./a.out" 
Current executable set to './a.out' (x86_64). 
(lldb) env DYLD_LIBRARY_PATH=/tmp 
(lldb) run 
Process 54331 launched: './a.out' (x86_64) 
/tmp 
Process 54331 exited with status = 0 (0x00000000) 

LLDB Version (es ist von Xcode 7.1):

$ lldb --version 
lldb-340.4.110 

Frage: Ist dies ein beabsichtigtes neues "Feature", oder ist das ein neuer Fehler in lldb (oder bin ich total verrückt und das hat nie funktioniert)? Ich bin ziemlich positiv lldb verwendet, um die Umgebungsvariable DYLD_LIBRARY_PATH weiterzuleiten, also wie kommt es, dass es nicht mehr ist?


Bearbeiten: Dies ist unter OS X 10.11.1.

+1

Bestätigt [hier] (https://www.mail-archive.com/[email protected]/msg00779.html) von Jason Molenda (der einer der lldb-Entwickler zu sein scheint). –

Antwort

23

Wenn dies auf El Capitan (OS X 10.11) ist, dann ist es fast sicher ein Nebeneffekt des Systemintegritätsschutzes. Vom System Integrity Protection Guide: Runtime Protections Artikel:

Wenn ein Prozess gestartet wird, um zu sehen, überprüft der Kernel, ob die Haupt ausführbaren Datei auf Festplatte gesichert ist oder mit einem speziellen System Berechtigung unterzeichnet. Wenn beides wahr ist, wird ein Flag gesetzt, um anzuzeigen, dass es gegen Änderungen geschützt ist. ...

... Jeder dynamischer Linker (dyld) Umgebungsvariablen, wie DYLD_LIBRARY_PATH, wird gelöscht, wenn Abschuss Prozesse geschützt.

Alles in/usr/bin ist auf diese Weise geschützt. Wenn Sie also/usr/bin/lldb aufrufen, werden alle DYLD_ * -Umgebungsvariablen gelöscht.

Es sollte LLDB aus Xcode.app oder die Kommandozeilen-Tools, wie so laufen arbeiten:

DYLD_LIBRARY_PATH=whatever /Applications/Xcode.app/Contents/Developer/usr/bin/lldb <whatever else> 

Ich glaube nicht, dass Kopie LLDB geschützt ist./usr/bin/lldb ist eigentlich nur ein Trampolin, das die Version in Xcode oder den Befehlszeilentools ausführt, so dass Sie letztendlich dasselbe ausführen. Aber/usr/bin/lldb ist geschützt, damit die DYLD_ * -Umgebungsvariablen bei der Ausführung gelöscht werden.

Andernfalls müssen Sie die Umgebungsvariable in lldb festlegen, wie von Greg Clayton in dem von Ihnen verknüpften Thread angezeigt. Oder Sie können den Systemintegritätsschutz deaktivieren, obwohl dies einem guten Zweck dient.

+0

Ja, das ist auf OS X 10.11.1. Das ist interessant. Danke für die klare Erklärung! – Cornstalks

+2

Danke. Das löst auch mein Problem (auf El Capitan). Ich habe einen Alias ​​'alias lldb =/Applications/Xcode.app/Inhalt/Entwickler/usr/bin/lldb' erstellt, um die Eingabe zu erleichtern. –

Verwandte Themen