ich bin nun schon länger auf der Suche nach einer Erklärung zu folgender Valgrind Meldung:

"Conditional jump or move depends on uninitialised values"

Auch die Orginal Doku sagt nichts zu der Meldung. Zumindest hab ich in den 200 Seiten noch nichts gefunden. Sie kommt immer an Funktionsaufrufen, wie __register_afork, ptmalloc_init, ... aber auch in meinen eigenen Funktionen. Weiß mir jemand etwas sinvolles dazu?

Grüße, M.Incani

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.

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.

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 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

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 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

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.

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

Grüße M. Incani

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).

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 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

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.)