leak vermeiden bei gethostbyaddr()
Stefan Fleiter
meiner einer will ein bischen mit sockets spielen und da führte der Weg erst
einmal über die _gethostbyaddr()_ Methode die ja einen Pointer auf ein
dynamisch angelegtes struct hostent zurückgibt.
Wer kümmert sich darum den Speicher frei zu geben?
[ ] ich
[ ] die Glibc selber irgendie
[ ] niemand
[ ] die Heinzelmännchen wenn alle schlafen
Danke schonmal,
Stefan
--
Linux User #123357 (http://counter.li.org/)
Fixed sendmail on www.linux.org.uk - that is I installed exim on it.
Sendmail kindly erased /etc/aliases when it was removed. That was nice
of it. -- Alan Cox
Matthias Andree
> meiner einer will ein bischen mit sockets spielen und da führte der Weg erst
> einmal über die _gethostbyaddr()_ Methode die ja einen Pointer auf ein
> dynamisch angelegtes struct hostent zurückgibt.
dynamisch? info libc ("Node: Host Names") sagt mir für glibc 2.1.3 was
anderes:
" You can use `gethostbyname', `gethostbyname2' or `gethostbyaddr' to
search the hosts database for information about a particular host. The
information is returned in a statically-allocated structure; you must
copy the information if you need to save it across calls. You can also
use `getaddrinfo' and `getnameinfo' to obtain this information."
Wenn Dir das nicht schmeckt, oder sich glibc 2.2 anders benimmt, sieh'
Dir mal die gethostby*_r an. Gibt's nicht überall, wo's die gibt, hast
Du aber Kontrolle über den Speicher -- den mußt Du dieser Funktion
nämlich geben.
--
Matthias Andree
"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." - Benjamin Franklin
Anselm Lingnau
> meiner einer will ein bischen mit sockets spielen und da führte der Weg erst
> einmal über die _gethostbyaddr()_ Methode die ja einen Pointer auf ein
> dynamisch angelegtes struct hostent zurückgibt.
Wie kommst Du denn da drauf? Zumindest in meiner Manpage steht
NOTES
The functions gethostbyname() and gethostbyaddr() may
return pointers to static data, which may be overwritten
by later calls.
In anderen Worten, der Zeiger zeigt auf Speicher, der der Bibliothek
gehört, und man läßt ihn am besten ganz in Frieden. Wenn man den
Inhalt kopieren will, muß man ihn gründlich kopieren, da mehr Zeiger
drinstehen.
In C programmiert man sowas übrigens nur, wenn man nicht anders kann.
Sprachen wie Tcl, Perl oder Python machen einem das Leben mit Sockets
-- und insbesondere das »Spielen« -- *viel* leichter.
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
Giving money and power to government is like giving whiskey and car keys to
teenage boys. -- P. J. O'Rourke
Florian Weimer
> meiner einer will ein bischen mit sockets spielen und da führte der Weg erst
> einmal über die _gethostbyaddr()_ Methode die ja einen Pointer auf ein
> dynamisch angelegtes struct hostent zurückgibt.
>
> Wer kümmert sich darum den Speicher frei zu geben?
Das ist implementationsabhängig.
Ernst Pfannenschmidt
"Matthias Andree" schrieb im Newsbeitrag
news:m3bsjow...@emma1.emma.line.org...
>
> " You can use `gethostbyname', `gethostbyname2' or `gethostbyaddr' to
> search the hosts database for information about a particular host. The
> information is returned in a statically-allocated structure; you must
> copy the information if you need to save it across calls. You can also
> use `getaddrinfo' and `getnameinfo' to obtain this information."
>
> Wenn Dir das nicht schmeckt, oder sich glibc 2.2 anders benimmt, sieh'
> Dir mal die gethostby*_r an. Gibt's nicht überall, wo's die gibt, hast
> Du aber Kontrolle über den Speicher -- den mußt Du dieser Funktion
> nämlich geben.
>
Die Beschreibung ist eigentlich eindeutig, der Speicher gehört der Lib.
Unter Windows (sorry, für diese Unwort hier) wird in der Doku noch
erwähnt, das jeder thread dafür einen eigenen Speicherbereich erhält.
Ist das unter Unix auch so? Oder muß eine Anwendung mit mehreren
Threads diesen Aufruf durch ein Mutex schützen?
Ernst
Stefan Fleiter
>> _gethostbyaddr()_ Methode die ja einen Pointer auf ein dynamisch angelegtes
>> struct hostent zurückgibt.
> Wie kommst Du denn da drauf? Zumindest in meiner Manpage steht
> NOTES
> The functions gethostbyname() and gethostbyaddr() may
> return pointers to static data, which may be overwritten
> by later calls.
Tja, in meiner auch, aber nur in der englischen, ich weiß irgendwie jetzt
garnicht mehr ob ich die deutschen nicht einfach löschen sollte.
Aber ein 'export MANOPT="-L C"' tuts auch erstmal.
Merken: HTML und übersetzte Dokumentation meiden.
> In anderen Worten, der Zeiger zeigt auf Speicher, der der Bibliothek
> gehört, und man läßt ihn am besten ganz in Frieden.
Er wird also automatisch beim #include beansprucht und erst beim
Programmende wieder frei gegeben, ist das richtig?
> In C programmiert man sowas übrigens nur, wenn man nicht anders kann.
> Sprachen wie Tcl, Perl oder Python machen einem das Leben mit Sockets
> -- und insbesondere das »Spielen« -- *viel* leichter.
Ist klar, aber einserseits will ich meine C-Kenntnisse verbessern und
andererseits brauche ich auch noch ein Projekt für "Parallele
Programmierung". Ich denke das passt dann ganz gut zusammen. :-)
Danke und Grüße,
Stefan
Stefan Fleiter
>> die _gethostbyaddr()_ Methode die ja einen Pointer auf ein dynamisch
>> angelegtes struct hostent zurückgibt.
> dynamisch? info libc ("Node: Host Names") sagt mir für glibc 2.1.3 was
> anderes:
[..]
> The information is returned in a statically-allocated structure; you must
> copy the information if you need to save it across calls.
[..]
Oh, ich glaube ich sollte auf die html-Version der libc Doku lieber
verzichten, die info-Version scheint besser zu sein.
Was solls, es gibt ja pinfo ;-)
> Wenn Dir das nicht schmeckt, oder sich glibc 2.2 anders benimmt,
Nein, da hat sich nichts geändert. Sehe ich das jetzt richtig, daß die
'statically-allocated structure' den Speicher zwar verbaucht, aber bis zum
Programmende nicht freigegeben werden kann?
> sieh' Dir mal die gethostby*_r an. Gibt's nicht überall, wo's die gibt,
> hast Du aber Kontrolle über den Speicher -- den mußt Du dieser Funktion
> nämlich geben.
Und sie ist Multi-Threading fähig, ich glaube das werde ich brauchen.
Dank und Grüße,
Stefan
Felix von Leitner
> Wenn Dir das nicht schmeckt, oder sich glibc 2.2 anders benimmt, sieh'
> Dir mal die gethostby*_r an. Gibt's nicht überall, wo's die gibt, hast
> Du aber Kontrolle über den Speicher -- den mußt Du dieser Funktion
> nämlich geben.
Ich habe den Eindruck, daß die Funktion, wenn es sie gibt, nicht
standardisiert ist. Kann mal jemand gerade unter einem Solaris gucken?
Unter Linux ist das API jedenfalls so unglaublich absurd, daß ich es
nicht einmal meinen speziellen Freunden von Sun zutraue. Die haben zwar
einen massiven Hirnschaden, aber es ist noch Reste von Krusten von
Hirnsubstanz übrig.
Felix
Florian Weimer
> Ist das unter Unix auch so? Oder muß eine Anwendung mit mehreren
> Threads diesen Aufruf durch ein Mutex schützen?
Das hängt von der Implementation ab. Der Schutz durch einen Mutex ist
jedenfalls nicht hinreichend, da Du nicht wissen kannst, welche
Funktionen hinter den Kulissen gethostbyaddr() aufrufen.
Andreas Spengler
> Er wird also automatisch beim #include beansprucht und erst beim
> Programmende wieder frei gegeben, ist das richtig?
Wohl eher beim Aufruf der Funktion...
Andreas
--
"Please enter a 45-digit prime number to activate your copy of Windows XP"
D. Rock
(aus Solaris 8)
Aufruf:
struct hostent *gethostbyaddr_r(const char *addr, int
length, int type, struct hostent *result, char *buffer, int
buflen, int *h_errnop);
- und weiter hinten -
WARNINGS
The reentrant interfaces gethostbyname_r(),
gethostbyaddr_r(), and gethostent_r() are included in this
release on an uncommitted basis only, and are subject to
change or removal in future minor releases.
--
Daniel
Ullrich von Bassewitz
> standardisiert ist. Kann mal jemand gerade unter einem Solaris gucken?
Korrekt. Bei den .*_r Funktionen laeuft man immer in Gefahr, dass sie auf
verschiedenen Plattformen unterschiedlich deklariert sind. Das ist
insbesondere bei den gethostby*_r Funktionen so. Insofern tauscht man hier den
Teufel gegen den Belzebub ein: Thread safe und keine Probleme mit
Ueberschreiben des statischen Speichers, aber dafuer unportabel.
Gruss
Uz
--
Ullrich von Bassewitz u...@musoftware.de
Matthias Andree
> Die Beschreibung ist eigentlich eindeutig, der Speicher gehört der Lib.
> Unter Windows (sorry, für diese Unwort hier) wird in der Doku noch
> erwähnt, das jeder thread dafür einen eigenen Speicherbereich erhält.
"The lookup functions above all have one in common: they are not
reentrant and therefore unusable in multi-threaded applications."
Man nehme gethostbyaddr_r.
> Ist das unter Unix auch so? Oder muß eine Anwendung mit mehreren
> Threads diesen Aufruf durch ein Mutex schützen?
Ob das sinnvoll wäre, sei mal dahingestellt...
Matthias Andree
> Merken: HTML und übersetzte Dokumentation meiden.
Kommt drauf an, wenn Dein HTML on-the-fly aus .info erzeugt wird, ist's
ja egal. Übersetzte Dokumentation neigt zu Unvollständigkeit und
Überalterung.
> > In anderen Worten, der Zeiger zeigt auf Speicher, der der Bibliothek
> > gehört, und man läßt ihn am besten ganz in Frieden.
>
> Er wird also automatisch beim #include beansprucht und erst beim
> Programmende wieder frei gegeben, ist das richtig?
Er wird wohl beim Linken beansprucht und dürfte sowas sein wie static
struct hostent meinhostent. Details im glibc-Quelltext.
Stefan Fleiter
> Er wird wohl beim Linken beansprucht und dürfte sowas sein wie static
> struct hostent meinhostent. Details im glibc-Quelltext.
Danke, so genau _will_ ich das garnicht wissen.
Da gibt es wesentlich angenehmer zu lesende Quelltexte, wie z.B. die von
leafnode ;-)
Grüße,
Stefan
Matthias Andree
Matthias Andree
Was bleibt? DNS-Client und /etc/hosts-Parser selbst hacken? Oder einfach
"fork() ist billig" und über Pipe oder Socket mit einem
single-threaded-Programm leben, das sich alle paar Stunden
sicherheitshalber selbst durch exec ersetzt?
Stefan Fleiter
>> Danke, so genau _will_ ich das garnicht wissen. Da gibt es wesentlich
>> angenehmer zu lesende Quelltexte, wie z.B. die von leafnode ;-)
> Au Backe. ;-)
Tja, wenn die nur ein "bischen" mehr dokumentiert wären, dann wäre es noch
besser.
Aber ich glaube das ist hier nicht mehr ganz topic, also f'up2 /me.
Grüße,
Stefan