befreit dlclose auch alle funktionspointer?

[schoppenhauer]

Hallo.

Eine Frage: Wenn ich mit dlopen() eine library öffne, dann ein paar funktionen mit dlsym() hole, und dann mit dlclose() die library wieder schließe, kann ich dann immernoch auf die funktionen zugreifen, die ich mit dlsym() geladen habe, oder werden die funktionen auch zerstört, sprich, ich krieg ne segfault oder sowas wenn ich versuche, sie aufzurufen?

[anda_skoa]

Aus der manpage von dlclose unter Linux

Although a dlclose() operation is not required to remove structures from an address space, neither is an implementation prohibited from doing so.

Auf gut Deutsch: implementationsabhängig, besser annehmen, dass die Pointer nicht mehr gelten

Ciao,
_

[schoppenhauer]

Hm. Genaugenommen will ich ja eigentlich, dass sie nicht mehr gelten. Ich hab leider sehr hohen Speicherverbrauch und versuch grad den zu minimieren, eine Weise auf die ich das versuche ist, alle Funktionen, die ich auf absehbare Zeit nicht brauche, zu befreien. Wie kann ich sihcer gehen, dass kein Speicher mehr verbruacht wird?

[peschmae]

Ich hätte jetzt angenommen (oh, das wolltest du sicher gar nicht hören, annehmen kannst du ja selber genau so gut) dass das OS den Speicher halt nach Bedarf frei gibt - d.h. z.B. die Funktionen noch ne Weile rumhängen lässt wenns für den Speicherplatz gerade keine sonstige nützliche Verwendung hat, in der Annahme dass du ja möglicherweise bald wieder darauf zugreifen willst.

Die Existenz des RTLD_NODELETE suggeriert für mich aber zumindest auf Linux schon dass das Zeugs entfernt wird.

Ausserdem:

dlclose
The function dlclose() decrements the reference count on the dynamic
library handle handle. If the reference count drops to zero and no
other loaded libraries use symbols in it, then the dynamic library is
unloaded.

... immer noch auf Linux - Debian mit Glibc 2.6

MfG Peschmä

[schoppenhauer]

Ich hätte jetzt angenommen (oh, das wolltest du sicher gar nicht hören, annehmen kannst du ja selber genau so gut) dass das OS den Speicher halt nach Bedarf frei gibt - d.h. z.B. die Funktionen noch ne Weile rumhängen lässt wenns für den Speicherplatz gerade keine sonstige nützliche Verwendung hat, in der Annahme dass du ja möglicherweise bald wieder darauf zugreifen willst.

Hm. Ich zweifle an. Also was du meinst wäre entweder Garbage Collecting, was sicher nicht implementiert ist, oder aber du meinst, dass niemand den Speicher überschreibt und man nach manchen free()-Aufrufen noch auf Rambereiche zugreifen kann, ohne dass ein Programm segfaultet. Deswegen sind sie aber nicht reserviert und können jederzeit anderweitig vergeben werden. Meine Frage war aber, ob der Speicher reserviert bleibt. Genau das will ich ja nicht. Ich hab ernsthaft Speicherprobleme, und da wäre eben ein Ansatz, Speicher zu sparen, den ich nicht unbedingt brauch.

Die Existenz des RTLD_NODELETE suggeriert für mich aber zumindest auf Linux schon dass das Zeugs entfernt wird.

Nunja. Ich hoffe mal. Aber... Die Frage ist ja... Kann man irgendwie anderweitig sichergehen, dass der Speicher freigegeben wird? Sprich: Kann ich nicht z.B. einfach free(funktionspointer) machen, und dann dlclose?

[RHBaum]

Deswegen sind sie aber nicht reserviert und können jederzeit anderweitig vergeben werden.

richtig, es ist aber nicht definiert, wann die .so "ueberschrieben" wird ....

Meine Frage war aber, ob der Speicher reserviert bleibt.

denau die frage beantwortest dir doch selber .... wenn das letzte dlclose durch ist, ist das BS in der lage, die shm ausm speicher zu removen. Und wenn dem BS der RAM knapp wird, wirds das sicher auch tun ....

Ueber was reden wir bei der shared lib eigentlich ?
Das einzige was ne .so / dll zwischen prozessen sharen kann, ist der "codeteil" Sind deine .so wirklich so gross, das es da den ram zumuellt ?

wesentlich mehr verheizen miest die variablen und der dyn speicher der innerhalb der so / dll angezogen wird.
da die prozessintern sind, also prozessinternen speicher sowieso verwenden, sind ihre gueltigkeit eh durch das dlopen / dlclose begrenzt .... was wahrscheinlich (je nach implementation) mit nem new/delete zu vergleichen ist .... bei dlopen wird der "stack" und der bereich fuer die gloablen variablen angelegt, bei nem dlclose kann er ausm speichermanger entfernt werden .... also bei bedarf wirds das BS definitiv tun ...

ob in der so mit new angelegte speicherbereiche bei nem dlclose auch automatisch deleted werden, wirst das BS zu konsultieren muessen. unsauber isses auf alle faelle ...
Unter windows kannst sowieso nur speicher innerhalb der selben dll holen und freigeben .... speicher ausserhalb der anlegenden dll in dem main binary oder ner anderen dll freigeben wollen, haut dir eh alles um die ohren ....
also geh ich davon aus, dass windows bei nem freelib das an den speichermanager durchgibt und der auch den in der dll reservierten dyn speicher freigibt .....
Bei sauberer programmierung sollte das eh kein thema sein ....

Ob das linux auxh so macht, keine ahnung, anzunehmen isses.

Ciao ...