valgrind

BlackPepper

Aber warum meckert mir valgrind unter anderem immer diese Zeile an.

fprintf(stderr,"Info:");

Sie stammt aus einer eigenen lib die gleichermaßen von C Programmen aber auch von CPP eingebunden wird. An dieser Zeile ist eingentlich nichts auszusetzten.

Grüße M. Incani

CStoll schrieb:

Frei übersetzt: "bedingter Sprung basiert auf nicht-initialisierten Werten". Sowas könnte vorkommen, wenn du den Wert einer Variablen verwendest, bevor sie initialisiert wurde:
int val;
while(val>100)
{
  cout<<"Bitte Wert eingeben";
  cin>>val;
}
Hier kannst du nicht vorhersagen, welchen Wert 'val' beim ersten Schleifendurchlauf haben wird - also ist das Ergebnis undefiniert.

BlackPepper schrieb:

Aber warum meckert mir valgrind unter anderem immer diese Zeile an.
fprintf(stderr,"Info:");
Sie stammt aus einer eigenen lib die gleichermaßen von C Programmen aber auch von CPP eingebunden wird. An dieser Zeile ist eingentlich nichts auszusetzten.

fprintf hat eine Ellipse als letzten Parameter und der ist bei dir leer.

Zu deinen anderen Problemfällen, kann das ganze auch an statics liegen die erst später initialisiert werden. (oder zum Beispiel argv = NULL)

BlackPepper

Gator schrieb:

BlackPepper schrieb:
Aber warum meckert mir valgrind unter anderem immer diese Zeile an.
fprintf(stderr,"Info:");
Sie stammt aus einer eigenen lib die gleichermaßen von C Programmen aber auch von CPP eingebunden wird. An dieser Zeile ist eingentlich nichts auszusetzten.
fprintf hat eine Ellipse als letzten Parameter und der ist bei dir leer.

Oh Ha!!! Und warum sollte das ein Problem sein?

Gator schrieb:

Zu deinen anderen Problemfällen, kann das ganze auch an statics liegen die erst später initialisiert werden. (oder zum Beispiel argv = NULL)

Meinst Du mit static

static int x = 0;

Und warum meckert mir Valgrind das an? Das hat doch nichts mit Speicherfehlern zu tun, oder?

Grüße M. Incani

BlackPepper schrieb:

Gator schrieb:
BlackPepper schrieb:
Aber warum meckert mir valgrind unter anderem immer diese Zeile an.
fprintf(stderr,"Info:");
Sie stammt aus einer eigenen lib die gleichermaßen von C Programmen aber auch von CPP eingebunden wird. An dieser Zeile ist eingentlich nichts auszusetzten.
fprintf hat eine Ellipse als letzten Parameter und der ist bei dir leer.
Oh Ha!!! Und warum sollte das ein Problem sein?

Unter Umständen (!?), weil da beim Aufruf dieser Funktion keine NULL in der Stackframe steht sondern ein Pointer ins Nirvana!

BlackPepper schrieb:

Gator schrieb:

"]
Zu deinen anderen Problemfällen, kann das ganze auch an statics liegen die erst später initialisiert werden. (oder zum Beispiel argv = NULL)

Meinst Du mit static
static int x = 0;
Und warum meckert mir Valgrind das an? Das hat doch nichts mit Speicherfehlern zu tun, oder?
Grüße M. Incani

Ja zum einen das. Du weisst ja sicher eh', das einige glibc Funktionen nicht threadsafe sind. (gettime(), etc..)

Zum Anderen, hab ich auch an sowas gedacht:

static int i;

if(1==1) // Immer wahr aber valgrind kann das net wissen. (nonoptimized debug)
i = 1;

pointer += (int)i;

BlackPepper

Gator schrieb:

BlackPepper schrieb:
Gator schrieb:
BlackPepper schrieb:
Aber warum meckert mir valgrind unter anderem immer diese Zeile an.
fprintf(stderr,"Info:");
Sie stammt aus einer eigenen lib die gleichermaßen von C Programmen aber auch von CPP eingebunden wird. An dieser Zeile ist eingentlich nichts auszusetzten.
fprintf hat eine Ellipse als letzten Parameter und der ist bei dir leer.
Oh Ha!!! Und warum sollte das ein Problem sein?
Unter Umständen (!?), weil da beim Aufruf dieser Funktion keine NULL in der Stackframe steht sondern ein Pointer ins Nirvana!

Also schreibe ich wohl besser

fprintf(stderr,"Info:", NULL);

Gator schrieb:

BlackPepper schrieb:
Gator schrieb:

"]
Zu deinen anderen Problemfällen, kann das ganze auch an statics liegen die erst später initialisiert werden. (oder zum Beispiel argv = NULL)

Meinst Du mit static
static int x = 0;
Und warum meckert mir Valgrind das an? Das hat doch nichts mit Speicherfehlern zu tun, oder?
Grüße M. Incani
Ja zum einen das. Du weisst ja sicher eh', das einige glibc Funktionen nicht threadsafe sind. (gettime(), etc..)

Zum Anderen, hab ich auch an sowas gedacht:

static int i;

if(1==1) // Immer wahr aber valgrind kann das net wissen. (nonoptimized debug)
i = 1;

pointer += (int)i;

Das hier leuchtet ein. Trotzdem scheint die Fehlermeldung "Conditional jump or move ..." in meinen Augen oft keine Ursache zu haben.

Grüße M. Incani

LordJaxom

Gator schrieb:

Unter Umständen (!?), weil da beim Aufruf dieser Funktion keine NULL in der Stackframe steht sondern ein Pointer ins Nirvana!

Hä?

Wenn Du bei der Ellipse keine Parameter übergibst landen auch keine auf dem Stack (wenn die Maschine einen Stack hat :D) - und wenn fprintf keine Formatkennungen im Formatstring findet, holt es sich auch nichts vom Stack, von daher - kein Problem.

BlackPepper

Kleine Zusatzbemerkung, Valgrind beanstandet mir sehr oft die Aufrufe aus den Standardlibs, also aufrufe wie open, write, close, nanosleep und viele andere.

Auch Dinde wie new, delete, cout, usw werden beanstandet. Wie stelle ich das ab?

Grüße M. Incani

LordJaxom schrieb:

Gator schrieb:

Unter Umständen (!?), weil da beim Aufruf dieser Funktion keine NULL in der Stackframe steht sondern ein Pointer ins Nirvana!

Hä?

Wenn Du bei der Ellipse keine Parameter übergibst landen auch keine auf dem Stack (wenn die Maschine einen Stack hat :D) - und wenn fprintf keine Formatkennungen im Formatstring findet, holt es sich auch nichts vom Stack, von daher - kein Problem.

Du hast recht. Jedenfalls semantisch. Nur hat die Signatur der Funktion immer einen Ellipsis Parameter, egal ob da jetzt was drinnen steht oder nicht. Beim Aufruf der Funktion zur Laufzeit wird da trotzdem ein Platz freigehalten, egal ob jetzt auf dem Stack oder wenn du willst in einem Register. Die aufgerufene Funktion kann ja nicht wissen das du nichts übergibst. In der Stackframe wird das also trotzdem gespeichert. Obgleich, wird der Inhalt der Ellipsisparameterliste sowieso nicht über die Stackframe übergeben, sonder über einen pointer "rechts" vom STACKPOINTER bzw. auf dem heap -> hence: va_start).

BlackPepper schrieb:

Kleine Zusatzbemerkung, Valgrind beanstandet mir sehr oft die Aufrufe aus den Standardlibs, also aufrufe wie open, write, close, nanosleep und viele andere.

Auch Dinde wie new, delete, cout, usw werden beanstandet. Wie stelle ich das ab?

Grüße M. Incani

http://valgrind.org/

BlackPepper

Gator schrieb:

BlackPepper schrieb:

Kleine Zusatzbemerkung, Valgrind beanstandet mir sehr oft die Aufrufe aus den Standardlibs, also aufrufe wie open, write, close, nanosleep und viele andere.

Auch Dinde wie new, delete, cout, usw werden beanstandet. Wie stelle ich das ab?

Grüße M. Incani

http://valgrind.org/

Hallo Gator,

ich wäre nicht hier, wenn ich nicht schon auf deren Homepage gekuckt hätte. Wenn Du weißt, daß es auf der Homepage einen Hinweis gibt, wäre ich Dir dankbar, wenn Du mir sagen könntest wo. Oder was ich machen muß.

Grüße, M. Incani

ghorst

du musst einfach die fehler, die du nicht haben willst, in eine suppressions-datei kopieren und mittels valgrind --suppressions=meinedatei angeben. allerdings sollten die warnungen für funktionen aus den standardlibs in der standardsuppressionsdatei drin stehen und gar nicht auftauchen. schau mal nach, ob die standarddatei ($PREFIX/lib/valgrind/default.supp) leer ist oder ob sie vllt für eine andere version der glibc und deiner c++libs ist.

zum erzeugen der unterdrückungen solltest du valgrind --gen-suppressions=yes oder --gen-suppressions=all benutzen. letzteres natürlich nur, wenn du weißt, dass keine fehler mehr in deinem code enthalten sind.
(schau aber auch mal in die man-page für nähere erklärungen der beiden kommandozeilenoptionen.)