Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Memory Leak feststellen
5 views
Skip to first unread message
Heinz-Mario Frühbeis
Mar 19, 2013, 5:08:33 PM3/19/13
to
Hallo zusammen!
Wie kann man denn am Besten, oder am Einfachsten ein Memory Leak
feststellen?
valgrind habe ich ersuchmaschint, aber wie setzt man das korreckt ein?
Des weiteren frage ich mich, ob ein Leak nicht per "Systemï¿œberwachung"
von LM14-KDE feststellbar ist?
Mit Gruￜ
Heinz-Mario Frï¿œhbeis
Wie kann man denn am Besten, oder am Einfachsten ein Memory Leak
feststellen?
valgrind habe ich ersuchmaschint, aber wie setzt man das korreckt ein?
Des weiteren frage ich mich, ob ein Leak nicht per "Systemï¿œberwachung"
von LM14-KDE feststellbar ist?
Mit Gruￜ
Heinz-Mario Frï¿œhbeis
Rainer Weikusat
Mar 19, 2013, 5:11:40 PM3/19/13
to
Heinz-Mario Fr�hbeis <Earl...@web.de> writes:
> Wie kann man denn am Besten, oder am Einfachsten ein Memory Leak
> feststellen?
>
> valgrind habe ich ersuchmaschint, aber wie setzt man das korreckt
> ein?
valgind --leak-check=full name-of-the-program argument ... 2>&1 | tee -i log
> Wie kann man denn am Besten, oder am Einfachsten ein Memory Leak
> feststellen?
>
> valgrind habe ich ersuchmaschint, aber wie setzt man das korreckt
> ein?
Damit bekommst Du eine Ausgabe auf dem Bildschirm und in einem File
names 'log' im aktuellen Verzeichnis und kannst den Testlauf mit ^C
abbrechen, sobald das sinnvoll scheint, ohne die Ausgabedatei zu
demolieren.
NB: Die Ausgabe richtig zu interpretieren ist 'ein andere Baustelle'
und nicht trivial.
Rainer Weikusat
Mar 19, 2013, 5:12:22 PM3/19/13
to
Heinz-Mario Fr�hbeis <Earl...@web.de> writes:
> Wie kann man denn am Besten, oder am Einfachsten ein Memory Leak
> feststellen?
>
> valgrind habe ich ersuchmaschint, aber wie setzt man das korreckt
> ein?
valgrind --leak-check=full name-of-the-program argument ... 2>&1 | tee -i log
> feststellen?
>
> valgrind habe ich ersuchmaschint, aber wie setzt man das korreckt
> ein?
Christian Kellermann
Mar 19, 2013, 5:20:35 PM3/19/13
to
Rainer Weikusat <rwei...@mssgmbh.com> writes:
Wenn das binary mit debug symbolen gebaut worden ist, gibt die
Zeilennummer jedoch meist einen recht guten Hinweis.
Liebe Grüße,
Christian
Zeilennummer jedoch meist einen recht guten Hinweis.
Liebe Grüße,
Christian
Heinz-Mario Frühbeis
Mar 20, 2013, 4:48:08 AM3/20/13
to
Das Programm heißt "IDA" und "main" ist int main(){}.
Muss ich dann "valgrind --leak-check=full IDA" in die Konsole eingeben?
Und wann?
Bezgl. debug symbolen: Muss ich dann das build auf "debug" setzen und
gut is'?
Mit Gruß
Heinz-Mario Frühbeis
Rainer Weikusat
Mar 20, 2013, 4:35:33 PM3/20/13
to
Heinz-Mario Fr�hbeis <Earl...@web.de> writes:
>>> Heinz-Mario Fr�hbeis <Earl...@web.de> writes:
[...]
>>>> valgrind habe ich ersuchmaschint, aber wie setzt man das korreckt
>>>> ein?
>>>
>>> valgrind --leak-check=full name-of-the-program argument ... 2>&1 | tee -i log
>>> NB: Die Ausgabe richtig zu interpretieren ist 'ein andere Baustelle'
>>> und nicht trivial.
>>
>> Wenn das binary mit debug symbolen gebaut worden ist, gibt die
>> Zeilennummer jedoch meist einen recht guten Hinweis.
> Bei "valgrind --leak-check=full name-of-the-program" f�ngt es ja schon an.
> Das Programm hei�t "IDA" und "main" ist int main(){}.
> Muss ich dann "valgrind --leak-check=full IDA" in die Konsole eingeben?
> Und wann?
Du musst das Programm via Terminal(-fenster) starten, um valgrind so
> Und wann?
benutzen zu koennen. Falls der Name der Programmdatei IDA ist und sie
im aktuellen Verzeichnis liegt, wird das normalerweise[*]
./IDA ...
sein, also
valgrind ... ./IDA ...
[*] Aus Sicherheitsgruenden ist . (das aktuelle Verzeichnis)
ueblicherweise nicht im Pfad (PATH-Umgebungsvariable).
> Bezgl. debug symbolen: Muss ich dann das build auf "debug" setzen und
> gut is'?
Interfaces[TM].
Heinz-Mario Frühbeis
Mar 20, 2013, 5:06:28 PM3/20/13
to
> [*] Aus Sicherheitsgruenden ist . (das aktuelle Verzeichnis)
> ueblicherweise nicht im Pfad (PATH-Umgebungsvariable).
nicht einordnen kann.
Im Internet habe ich zwar mal was davon gelesen, aber auch da konnte ich
mir nichts spezifisches drunter vorstellen.
Soweit ich mir einen "Reim" machen kann:
Mein Programm liegt z. Z. in "/home/Benutzer/Entwicklung/IDA", dann
m��te das doch reichen, oder?
Oder soll ich vllt das erstellte Programm in ein noch anderes
Verzeichnis kopieren (z. Bsp. "/home/Benutzer/Entwicklung/IDA/Test"und
von da aus ein Terminal starten und "valgrind ... ./IDA ..." starten?
>> Bezgl. debug symbolen: Muss ich dann das build auf "debug" setzen und
>> gut is'?
>
> Wahrscheinlich. Ich benutze keine Graesslich Umstaendlichen
> Interfaces[TM].
>
komme ich mit dem QT-Creator *einfach ganz gut zurecht.
Wenn ich mal "valgrind" gestartet habe, dann werde ich ja sehen, was zu
lesen ist, und dann kann ich ja noch ausprobieren.
Mit Gru�
Heinz-Mario Fr�hbeis
Juergen Ilse
Mar 20, 2013, 6:55:54 PM3/20/13
to
Hallo,
Heinz-Mario Frï¿œhbeis <Earl...@web.de> wrote:
> Am 20.03.2013 21:35, schrieb Rainer Weikusat:
>> [*] Aus Sicherheitsgruenden ist . (das aktuelle Verzeichnis)
>> ueblicherweise nicht im Pfad (PATH-Umgebungsvariable).
> Und hier hadere ich wieder, weil ich "aus Sicherheitsgrï¿œnden" ï¿œberhaupt
> nicht einordnen kann.
Stell dir vor, ein wenig liebenswerter Mitbenutzer deines Systems wuerde
(unter seinem eigenen Account) die Befehle:
echo 'rm -rf $HOME' > /tmp/ls-l
chmod a+rx /tmp/ls-l
eingeben. Wenn du dann mit "cd /tmp" in dieses Berzeichnis wechselst und
dir den Verzeichnisinhalt ansehen moechtest und dir dabei ein kleiner
Tippfehler unterlaeuft: du laesst bei "ls -l" versehentlich das Leerzeichen
web, was wuerde passieren, wenn du "." im PATH haettest und was wuerde
passieren, wenn das nicht der Fall waere? Proviere es *nicht* aus, wenn
du Wer auf deine Daten legst ...
Wenn vielleicht sogar "." vor den ueblichen Systemverzeichnissen /bin
und /usr/bin im PAZJ liegt, braucht es noch nicht einmal einen Tippfehler
deinerseits, wenn jener unliebsame Mitbenutzer sein boeses Script unter
demNamen "ls" statt "ls-l" in /tmp angelegt haette.
> Im Internet habe ich zwar mal was davon gelesen, aber auch da konnte ich
> mir nichts spezifisches drunter vorstellen.
> Soweit ich mir einen "Reim" machen kann:
> Mein Programm liegt z. Z. in "/home/Benutzer/Entwicklung/IDA", dann
> mￜￜte das doch reichen, oder?
Die unix-sgell sucht Programme ohne Pfadangabe *nur* in den Verzeichnissen,
die in $PATH aufgelistet sind. Steht das altuelle Verzeichnis *nicht* in
$PATH drin, kann man Programme aus dem aktuellen Verzeichnis nur aufrufen,
wenn man nicht nur ihren Namen sondern den Pfad zur Prohrammdatei angibt.
Da "." *immer* fuer das gerade aktuelle Verzeichnis steht, genuegt fuer
den Aufruf des Programms "IDA" aus dem gerade aktuellen Verzeichnis ein
simples "./IDA", waehrend "IDA" nicht genuegt solange "." nicht in
$PATH steht. Das ist ein grundsaetzlich anderes Verhalten als bei DOS
und Windows, wo voeￜￜig unabhaengig vom gesetzten Such-Pfad *immer*
*zuerst* im aktuellen Verzeichnis gesucht wird.
> Oder soll ich vllt das erstellte Programm in ein noch anderes
> Verzeichnis kopieren (z. Bsp. "/home/Benutzer/Entwicklung/IDA/Test"und
> von da aus ein Terminal starten und "valgrind ... ./IDA ..." starten?
???
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Heinz-Mario Frï¿œhbeis <Earl...@web.de> wrote:
> Am 20.03.2013 21:35, schrieb Rainer Weikusat:
>> [*] Aus Sicherheitsgruenden ist . (das aktuelle Verzeichnis)
>> ueblicherweise nicht im Pfad (PATH-Umgebungsvariable).
> nicht einordnen kann.
Stell dir vor, ein wenig liebenswerter Mitbenutzer deines Systems wuerde
(unter seinem eigenen Account) die Befehle:
echo 'rm -rf $HOME' > /tmp/ls-l
chmod a+rx /tmp/ls-l
eingeben. Wenn du dann mit "cd /tmp" in dieses Berzeichnis wechselst und
dir den Verzeichnisinhalt ansehen moechtest und dir dabei ein kleiner
Tippfehler unterlaeuft: du laesst bei "ls -l" versehentlich das Leerzeichen
web, was wuerde passieren, wenn du "." im PATH haettest und was wuerde
passieren, wenn das nicht der Fall waere? Proviere es *nicht* aus, wenn
du Wer auf deine Daten legst ...
Wenn vielleicht sogar "." vor den ueblichen Systemverzeichnissen /bin
und /usr/bin im PAZJ liegt, braucht es noch nicht einmal einen Tippfehler
deinerseits, wenn jener unliebsame Mitbenutzer sein boeses Script unter
demNamen "ls" statt "ls-l" in /tmp angelegt haette.
> Im Internet habe ich zwar mal was davon gelesen, aber auch da konnte ich
> mir nichts spezifisches drunter vorstellen.
> Soweit ich mir einen "Reim" machen kann:
> Mein Programm liegt z. Z. in "/home/Benutzer/Entwicklung/IDA", dann
Die unix-sgell sucht Programme ohne Pfadangabe *nur* in den Verzeichnissen,
die in $PATH aufgelistet sind. Steht das altuelle Verzeichnis *nicht* in
$PATH drin, kann man Programme aus dem aktuellen Verzeichnis nur aufrufen,
wenn man nicht nur ihren Namen sondern den Pfad zur Prohrammdatei angibt.
Da "." *immer* fuer das gerade aktuelle Verzeichnis steht, genuegt fuer
den Aufruf des Programms "IDA" aus dem gerade aktuellen Verzeichnis ein
simples "./IDA", waehrend "IDA" nicht genuegt solange "." nicht in
$PATH steht. Das ist ein grundsaetzlich anderes Verhalten als bei DOS
und Windows, wo voeￜￜig unabhaengig vom gesetzten Such-Pfad *immer*
*zuerst* im aktuellen Verzeichnis gesucht wird.
> Oder soll ich vllt das erstellte Programm in ein noch anderes
> Verzeichnis kopieren (z. Bsp. "/home/Benutzer/Entwicklung/IDA/Test"und
> von da aus ein Terminal starten und "valgrind ... ./IDA ..." starten?
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
0 new messages