Wenn Sie meine Bibliothek auf LD_PRELOAD setzen, erzeugen einige Prozesse Ladefehler

Lesezeit: 3 Minuten

Benutzeravatar von nakiya
Nakiya

Ich erhalte die folgende Fehlermeldung, wenn ich versuche, ein Skript auszuführen, für das ich nur Ausführungszugriff habe:

uname: symbol lookup error: /home/dumindara/random/sotest/a.out: undefined symbol: dlsym

Dies ist, nachdem ich eingestellt habe LD_PRELOAD Umgebungsvariable zu /home/dumindara/random/sotest/a.out.

a.out hat eine Prüfung malloc Funktion und Anrufe dlsym im Inneren.

Beim Laufen habe ich dieses Problem nicht ls. Die meisten Prozesse geben diesen Fehler aus. Warum passiert das und was kann ich tun, damit es funktioniert?

  • Im Allgemeinen ist es eine gute Idee, LD_PRELOAD nur für a.out zu setzen, anstatt die Shell-Umgebung zu ändern. In den meisten UNIX-Shells können Sie Folgendes eingeben: LD_PRELOAD=xyz ./a.out. Ansonsten versuchen ( LD_PRELOAD=xyz; ./a.out ).

    – Toni Delroy

    8. Dezember 2010 um 8:08 Uhr

  • @Tony: Ich denke, dass a.out in diesem Fall trotz seines schlecht gewählten Namens ein gemeinsames Objekt ist. Das OP versucht anscheinend, sich zu überschreiben malloc() mit ihrer eigenen Version und dann zum echten Malloc durchgehen.

    – thkala

    8. Dezember 2010 um 8:25 Uhr


  • @tkhala: ah, guter Fang … wäre eher so LD_PRELOAD=`pwd`/a.out program_to_test Dann….

    – Toni Delroy

    8. Dezember 2010 um 8:52 Uhr


Ich kann die akzeptierte Antwort nicht kommentieren, aber es ist erwähnenswert, dass man hier auf das Problem stoßen kann, dass libdl.so.2 nicht richtig verlinkt ist, wenn -ldl wird vor dem Kompilierungsbefehl verwendet (vorausgesetzt, dass das Linken und Kompilieren durch denselben Befehl ausgeführt wird; dies ist möglich, da LD_PRELOAD-Bibliotheken normalerweise auf einer Quelldatei basieren).

Rufen Sie also gcc mit an -ldl Am Ende:

gcc -shared -fPIC fakeuname.c -o libfakeuname.so -ldl

In meinem Fall haben -ldl vorne führte zu einem Fehler wie in Frage:

uname: symbol lookup error: ./libfakehostname.so: undefined symbol: dlsym

  • ja daumen hoch!!! Die Antwort von thkala hat mir immer noch einen Fehler gegeben, aber Ihr “-ldl” am Ende hat alles gelöst.

    – Peter Teoh

    16. Oktober 2015 um 10:19 Uhr

Benutzeravatar von thkala
thkala

Ich gehe davon aus, dass Ihre a.out-Datei ein gemeinsam genutztes Objekt und keine ausführbare Datei ist, und mache weiter …

dlsym() ist eine Funktion aus der libdl-Bibliothek, die sich auf modernen Linux-Systemen normalerweise im gemeinsam genutzten Objekt libdl.so.2 befindet.

Ich wage die Vermutung, dass Ihr gemeinsames a.out-Objekt nicht mit libdl verknüpft ist. Das bedeutet, dass, wenn Sie eine einfache Binärdatei wie uname vorab laden, die nicht viele andere Bibliotheken einzieht, libdl.so.2 möglicherweise nicht eingezogen wird und Sie einen undefinierten Symbolfehler erhalten.

Wenn Sie es andererseits in eine Binärdatei vorab laden, die mit libdl.so.2 verknüpft ist und schließlich hineingezogen wird, funktioniert Ihr gemeinsam genutztes Objekt einwandfrei.

Ich würde mich erkundigen ldd ob Ihr eigenes gemeinsam genutztes Objekt ordnungsgemäß gegen libdl gelinkt ist, und auch welche Bibliotheken wann direkt oder indirekt hereingezogen werden uname Und ls laufen.

BEARBEITEN:

Das habe ich gerade bestätigt. Die Möglichkeit, diesen Fehler zu beheben, besteht darin, Ihr gemeinsam genutztes Objekt mit libdl zu verknüpfen. Hinzufügen -ldl zu seinen LDFLAGS sollte es tun.

  • Beachten Sie, dass -ldl möglicherweise vor den anderen .o-Dateien stehen muss, zB “gcc -ldl -shared foo.o bar.o -o baz.so”.

    – Herr Fooz

    8. Mai 2012 um 16:34 Uhr

  • Wie zufällig in der Antwort unten erwähnt wurde, -ldl sollte eigentlich am ende gehen gcc Zeile, wenn das Linken und Kompilieren zusammen erfolgt. Ich habe die Erklärung dazu gelesen gcc erstellt eine Liste von Symbolen aus Dateien und sucht sie dann aus irgendeinem Grund in Bibliotheken, die nach ihren Namen genannt werden.

    – Marischa

    1. Oktober 2019 um 0:37 Uhr

1444110cookie-checkWenn Sie meine Bibliothek auf LD_PRELOAD setzen, erzeugen einige Prozesse Ladefehler

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy