Pytanie Dlaczego nie przesyła dalej mojej zmiennej środowiskowej?


Pracuję nad poprawką dla FFmpeg i muszę debugować mój kod. Ładuję bibliotekę zewnętrzną, a żeby przetestować różne wersje bibliotek, mam je w różnych folderach. Aby wybrać, którego chcę użyć, używam DYLD_LIBRARY_PATH=/path/to/lib/dir ./ffmpeg i to działa dobrze. Ale kiedy próbuję tego wewnątrz lldb, zawiesza się mówiąc dyld: Library not loaded i Reason: image not found. To działało do pracy z pre-Xcode 7.1, ale niedawno uaktualniłem go i przestało działać.


Oto moja MVCE:

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

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

Uruchomienie tego programu w następujący sposób daje wynik:

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

To wygląda dobrze. Ale kiedy próbuję użyć lldb, to zawiedzie:

$ 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)

Próba ustawienia zmiennej środowiskowej wewnątrz lldb działa:

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) 

Wersja lldb (pochodzi z Xcode 7.1):

$ lldb --version
lldb-340.4.110

Pytanie: Czy jest to zamierzona nowa "funkcja", czy też jest to nowy błąd w lldb (czy też jestem całkowicie szalony i to nigdy nie działało)? Jestem całkiem pozytywny lldb używany do przekazania DYLD_LIBRARY_PATH zmienna środowiskowa, więc dlaczego to już nie jest?


Edycja: To jest na OS X 10.11.1.


14
2017-11-07 19:58


pochodzenie


Zatwardziały tutaj Jason Molenda (który wydaje się być jednym z programistów Lldb). - Martin R


Odpowiedzi:


Jeśli jest to na El Capitan (OS X 10.11), to prawie na pewno efekt uboczny System Integrity Protection. Od Przewodnik po ochronie integralności systemu: Zabezpieczenia programu Runtime artykuł:

Gdy proces jest uruchamiany, jądro sprawdza, czy główny   plik wykonywalny jest chroniony na dysku lub jest podpisany za pomocą specjalnego systemu   uprawnienia. Jeśli którakolwiek z nich jest prawdziwa, ustawiana jest flaga oznaczająca to   jest chroniony przed modyfikacją. ...

... Dowolny dynamiczny linker (dyld)   zmienne środowiskowe, takie jak DYLD_LIBRARY_PATH, są oczyszczane, kiedy   uruchamianie chronionych procesów.

Wszystko w / usr / bin jest chronione w ten sposób. Dlatego po wywołaniu / usr / bin / lldb wszystkie zmienne środowiskowe DYLD_ * zostaną wyczyszczone.

Powinien działać, aby uruchomić lldb z poziomu Xcode.app lub narzędzi wiersza poleceń, na przykład:

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

Nie wierzę, że kopia lldb jest chroniona. / usr / bin / lldb jest tak naprawdę tylko trampoliną, która wykonuje wersję w Xcode lub Command Line Tools, więc ostatecznie działasz tak samo. Ale / usr / bin / lldb jest chroniony, więc zmienne środowiskowe DYLD_ * są usuwane podczas działania tego.

W przeciwnym razie będziesz musiał ustawić zmienną środowiskową wewnątrz lldb, jak pokazuje Greg Clayton w tym wątku, który łączyłeś. Możesz też wyłączyć Ochronę integralności systemu, mimo że służy to celowi.


23
2017-11-08 01:30



Tak, to jest na OS X 10.11.1. To interesujące. Dzięki za jasne wyjaśnienie! - Cornstalks
Dzięki. To rozwiązuje mój problem (na El Capitan). Stworzyłem alias alias lldb=/Applications/Xcode.app/Contents/Developer/usr/bin/lldb złagodzić pisanie. - Tzunghsing David Wong