ich habe ein shared object erstellt, und mittels dlopen geladen. Danach habe ich mit dlsym versucht eine funktion zu laden, die mir einen zeiger auf eine klasse zurückgibt, welche ich mit static_cast zu casten versucht habe.

Wenn ich jetzt versuche, eine methode aus dieser gecasteten classe zu laden, bekomme ich die fehlermeldung "Speicherzugriffsfehler".

Kann mir jemand sagen, wo ich einen fehler gemacht habe?

Danke!

Hier der source der klasse, welche das plugin lädt:

#include <iostream>
#include <dlfcn.h>
#include "testplugin/testplugin.h"

int main()
{
	void *handle = dlopen("libtestplugin.so", RTLD_NOW);

	if (!handle)
		return 0;

	void *pluginInstance = dlsym(handle, "createClassInstance");

	if (!pluginInstance)
	{
		dlclose(handle);
		return 0;
	}

	TestPlugin *tp = static_cast<TestPlugin *>(pluginInstance);

	if (tp)
		tp->printTestMessage();

	dlclose(handle);

	return 0;
}

Header des plugins:

#ifndef TESTPLUGIN_H_
#define TESTPLUGIN_H_

class TestPlugin
{
	public:
		TestPlugin();
		virtual ~TestPlugin();

		void printTestMessage();
};

extern "C" TestPlugin *createClassInstance();

#endif /* TESTPLUGIN_H_ */

Source des Plugins:

#include "testplugin.h"
#include <iostream>

TestPlugin::TestPlugin()
{

}

void TestPlugin::printTestMessage()
{
	std::cout << "Plugin geladen!" << std::endl;
}

TestPlugin::~TestPlugin()
{
}

extern "C" TestPlugin *createClassInstance()
{
	return new TestPlugin;
}

Das KANN gut gehen, muss aber nicht. D.h. unter Umständen funktioniert es, unter Umständen reicht aber auch schon irgend eine Compileroption, die bei Plug-In und Hauptprogramm anders gesetzt ist, um dir die seltsamsten Effekte zu bescheren. Von unterschiedlichen Compilerversionen ganz zu schweigen...

Das Problem liegt darin, dass diese nur für den Export von C-Funktionen gedacht sind, du aber C++-Objekte verwendest.

Was wäre eine alternative für dlopen, damit das mit c++ objekten funktioniert?

Dein Problem hat eine simple Ursache:
dlsym ruft deine Funktion nicht auf, sondern gibt lediglich einen Funktionszeiger zurück.
Deine "plugInstance" ist also kein Zeiger auf ein Objekt deiner Klasse sondern eben ein Funktionszeiger.

So wäre es also fast richtig:

typedef TestPlugin * (*createClassInstancePtr)();

// ...

createClassInstancePtr createClassInstance = (createClassInstancePtr)dlsym(handle, "createClassInstance");
TestPlugin * instance = createClassInstance();

fast, weil der Standard nicht garantiert, dass ein Funktionszeiger genauso groß ist wie ein Objektzeiger (z.B. void*, int*, TestPlugin* ...).
dlsym stellt eine Inkompatibilität zwischen POSIX und ANSI dar und wurde auch schon mehrfach im Netz diskutiert.

Korrekt wäre also, in dein Shared Object sowas zu packen:

// für plugin und programm sichtbar
// z.B. in einem Header
struct exported_functions
{
    TestPlugin * (*createClassInstance)();
};

// nur im Plugin
// global!
exported_functions public_interface = 
{
    &createClassInstance // Zeiger auf deine Funktion
};

// und das kommt in das Programm:
exported_functions * functions = static_cast<exported_functions*>(dlsym(handle, "public_interface"));
TestPlugin * instance = functions->createClassInstance();

Nur so gehst du dem Problem der Zeigergröße aus dem Weg.

Eventuell musst du die globale Instanz der exported_functions Struktur noch in einen extern "C"-Block stecken, da bin ich mir gerade nicht sicher :p
Einfach ausprobieren, wie es functioniert

Steini79, hör nicht auf Donggger.

Dein Problem hat eine simple Ursache:
dlsym ruft deine Funktion nicht auf, sondern gibt lediglich einen Funktionszeiger zurück.

Richtig, einen Funktionszeiger, kein Objekt. Weil Bibliotheken nun mal nicht für Objekte vorgesehen sind - deswegen hat MS ja das unselige COM/DCOM erfunden.

Und warum genau soll er jetzt nicht auf mich hören? Willst du ihn lieber weiter in die falsche Richtung laufen lassen, bis ihm seine Objekte über die C-Schnittstelle irgendwann viel, viel später um die Ohren fliegen?

Danke für deine hilfe, ich werde mir das genauer ansehen.

@Donggger

Ich nehme mir beide argumentationen zu herzen, gibt es dann eine alternative zu dlopen/dlsym?

Ich nehme mir beide argumentationen zu herzen, gibt es dann eine alternative zu dlopen/dlsym?

dlopen/dlsym passt schon. Du musst nur dein Interface aendern.

Statt
foo->bar()
schreibst du ab jetzt
bar(foo);

Sprich: du machst dein Interface einfach Kompatibel zur verwendeten technology. Das bedeutet lustigerweise naemlich auch gleich, dass ich mit so ziemlich jeder Sprache dein shared object nutzen kann, nicht nur mit C++.

Und das ganze ist sowieso nur Syntax um die es geht - die Funktionalitaet bleibt eh gleich.

Das Shared Object exportiert eine create Funktion die einen void* returned. Intern macht sie natuerlich new Foo(), liefert das Foo Objekt aber nur als void* raus. Oft versteckt man den void* hinter einem typedef, damits besser aussieht.

Wenn du nun foo->bar() aufrufen willst, dann exportiert das shared object eine Funktion bar die einen void* nimmt (als this Zeiger) und so implementiert ist:
static_cast<Foo*>(foo)->bar();

so hast du auch weiter die komplette polymorphie erhalten die du in deinem C++ Code hast.

Das KANN gut gehen, muss aber nicht. D.h. unter Umständen funktioniert es, unter Umständen reicht aber auch schon irgend eine Compileroption, die bei Plug-In und Hauptprogramm anders gesetzt ist, um dir die seltsamsten Effekte zu bescheren. Von unterschiedlichen Compilerversionen ganz zu schweigen...

Und warum genau soll er jetzt nicht auf mich hören? Willst du ihn lieber weiter in die falsche Richtung laufen lassen, bis ihm seine Objekte über die C-Schnittstelle irgendwann viel, viel später um die Ohren fliegen?

Die Berichte von auf Grund von unterschiedlichen Compiler-Switches explodierten Programmen sind stark übertrieben.

Es gibt andere Dinge die schon weniger egal sind, wie z.B. die Sache mit unterschiedlichen CRT Versionen, Heap etc.
Lässt sich aber auch alles regeln.

Es gibt Fälle wo C-Interfaces angesagt sind, und es gibt Fälle wo C++ Interfaces angesagt bzw. zumindest vollkommen OK sind. Die Grundsätzliche "C++ Interfaces sind pöse" Panikmache kann ich nicht ganz nachvollziehen.

Die Grundsätzliche "C++ Interfaces sind pöse" Panikmache kann ich nicht ganz nachvollziehen.

Na dann schreib' mal eine DLL mit Visual Studio die Objekte nutzt. Und viel Spaß dann mit dem Support für deine Kunden, die eine Applikation mit MingW compilieren und denen deine DLL bei jedem Zugriff um die Ohren fliegt.

Oder auch viel Spaß mit denen, die zwar Visual Studio verwenden, aber einen Debug-Build verwenden wollen. Erkläre denen mal, dass du keinen Debug-Build deiner DLL auslieferst und sie deswegen ihre Applikation auch nur als Release-Build debuggen können.

Es gibt Fälle wo C-Interfaces angesagt sind, und es gibt Fälle wo C++ Interfaces angesagt bzw. zumindest vollkommen OK sind. Die Grundsätzliche "C++ Interfaces sind pöse" Panikmache kann ich nicht ganz nachvollziehen.

@Donggger

Der vollständigkeit halber würde ich auch gerne deine argumentation verstehen, dazu müsste ich aber wissen, wie du die sache mit anstatt mit dlopen/dlsym lösen würdest?

dazu müsste ich aber wissen, wie du die sache mit anstatt mit dlopen/dlsym lösen würdest?

Den Ersatz für dlopen()/dlsym() den du suchst, gibt es nicht. Wenn es um Shared Libraries geht, kannst du nur diese Funktionen verwenden und du kannst dir nur C-Funktionspointer mit C-Datentypen als Parameter zurückgeben lassen.

Der springende Punkt ist: Shared Libraries sind genau dafür gedacht, für Objekte waren sie nie vorgesehen. Wenn du wirklich Objekte über ausgelagerte Programmkomponenten ziehen willst und eine saubere Lösung suchst, darfst du generell keine Shared Library verwenden, sondern müsstest dich beim COM-Interface (nicht zu verwechseln mit der seriellen Schnittstelle) bedienen. Und das gibt es nur bei Windows.

Wenn du wirklich Objekte über ausgelagerte Programmkomponenten ziehen willst und eine saubere Lösung suchst, darfst du generell keine Shared Library verwenden, sondern müsstest dich beim COM-Interface (nicht zu verwechseln mit der seriellen Schnittstelle) bedienen. Und das gibt es nur bei Windows.

Schwachsinn. Das geht mit dem Posix-Interface wunderbar und wohldefiniert.

Das selbe kann man auch schön mit GCC unter Linux/BSD/... machen. Wird auch gemacht. Funktioniert auch gut.

Es ist natürlich nicht so flexibel wie ein reines C-Interface, weil es eben gewisse Restrictions bezüglich verwendbarer Compiler etc. bedeutet, aber wie schon gesagt: es ist nichts "unsauberes" daran.

Donggger schrieb:

Wenn du wirklich Objekte über ausgelagerte Programmkomponenten ziehen willst und eine saubere Lösung suchst, darfst du generell keine Shared Library verwenden, sondern müsstest dich beim COM-Interface (nicht zu verwechseln mit der seriellen Schnittstelle) bedienen. Und das gibt es nur bei Windows.

Schwachsinn. Das geht mit dem Posix-Interface wunderbar und wohldefiniert.

Welches Posix-Interface meinst du

Welches Posix-Interface meinst du

Na das, von dem wir (fast) die ganze Zeit reden: dlopen, dlssym, ...

hustbaer schrieb:

Welches Posix-Interface meinst du

Na das, von dem wir (fast) die ganze Zeit reden: dlopen, dlssym, ...

Heißt das, unter Windows gibt es keine sichere/saubere/... Lösung?

Donggger schrieb:

Wenn du wirklich Objekte über ausgelagerte Programmkomponenten ziehen willst und eine saubere Lösung suchst, darfst du generell keine Shared Library verwenden, sondern müsstest dich beim COM-Interface (nicht zu verwechseln mit der seriellen Schnittstelle) bedienen. Und das gibt es nur bei Windows.

Schwachsinn. Das geht mit dem Posix-Interface wunderbar und wohldefiniert.

Nope. Geht leider nicht so einfach. Weil wenn du zB den gcc verwendest und ich den llvm dann tut das ganz dicke aua machen wenn wir versuchen C++ Objekte zu sharen

Aber insofern hast du recht, es ist wohldefiniert was passiert: naemlich ein PENG BUMM BAENG.

C++ Objekte ueber Modulgrenzen hinweg sharen ist deshalb doof, weil C++ keine definierte ABI hat. Da gibt es viele Fallstricke deshalb ratet man davon ab.

Wo es Sinn machen kann ist innerhalb eines Projektes - wenn man das Buildenvironment kontrolliert.

C++ Objekte ueber Modulgrenzen hinweg sharen ist deshalb doof, weil C++ keine definierte ABI hat. Da gibt es viele Fallstricke deshalb ratet man davon ab.

Wo es Sinn machen kann ist innerhalb eines Projektes - wenn man das Buildenvironment kontrolliert.

Das Build-Environment kann man auch toll für Plugins kontrollieren. z.B. indem man es vorschreibt, evtl. sogar gleich passende Makefiles/Solution-Files mitliefert.

Ich verstehe einfach nicht wieso manche immer meinen, dass etwas was sie für ihr Projekt nicht brauchen/brauchen können (bzw. einfach nicht *wollen*), auch ganz allgemein eine schlechte Idee sein muss.

Es gibt einige Projekte die recht erfolgreich Plugins mit C++ Schnittstelle verwenden. Als ein Beispiel wäre foobar2000 zu nennen.

Shade Of Mine schrieb:

Nope. Geht leider nicht so einfach. Weil wenn du zB den gcc verwendest und ich den llvm dann tut das ganz dicke aua machen wenn wir versuchen C++ Objekte zu sharen

S.o.: nimm halt einfach nicht LLVM sondern das was das Programm vorschreibt. Mir ist vollkommen klar was du meinst, aber gleichzeitig vollkommen unklar wieso das ein generelles Problem sein sollte.

hustbaer schrieb:

Welches Posix-Interface meinst du

Na das, von dem wir (fast) die ganze Zeit reden: dlopen, dlssym, ...

dlopen, dlssym etc. tragen jetzt weder besonders viel dazu bei dass es geht, noch arbeiten sie irgendwie dagegen.
Damit kann man halt Zeiger per Namen aus nem SO rausholen, mehr nicht. (EDIT: und das SO vorher erstmal laden natürlich /EDIT)

Ob man problemlos mit C++ Interfaces arbeiten kann oder nicht, wird davon nicht wirklich beeinflusst - da sind andere Dinge wichtig.

Daher dachte ich du meinst vielleicht die Itanium C++ ABI - die aber mit Posix rein gar nix zu tun hat. Weil ich mir aber nicht sicher war, dachte ich mir ich frag lieber mal nach...

S.o.: nimm halt einfach nicht LLVM sondern das was das Programm vorschreibt. Mir ist vollkommen klar was du meinst, aber gleichzeitig vollkommen unklar wieso das ein generelles Problem sein sollte.

Ein Problem per se ist es nicht. Aber es sind sehr wenige Situationen wo C++ Interfaces hier Sinn machen. Denn C++ Interfaces verlangen, dass man das Build Environment kontrollieren kann. Wenn man das kann, super - dann ists kein Problem.

Nur oft kann man das nicht. Deshalb lieber C++ in Shared Objects mit vorsicht behandeln. Wenn man aber natuerlich weiss was man tut, ists kein Problem.

@hutzlwutzl
Unter Windows gibt es DLLs statt Shared Objects und die Funktionen LoadLibrary/GetProcAddress statt dlopen/dlsym.
Wobei Windows DLLs und Linux/... Shared Objects einige Dinge etwas anders regeln.