Ich habe versucht zu verstehen, warum sich valgrind über "Verwendung von nicht initialisierten Werten der Größe 8" für dieses kleine Testprogramm beschwert, das ucontexts verwendet. Es ist im Grunde ein Programm, das "n_ucs" ucontexts erstellt und sie für "max_switch" -Zeiten umschaltet.
Ich verstehe die "Warnung: Client-Switching-Stacks?" (das ist im Grunde, was das Programm alles), aber ich kann nicht wirklich Sinn für alle "Verwendung von nicht initialisierten Wert der Größe 8"
Ich würde gerne Hilfe bekommen, wenn Valgrind-Fehler falsch-positiv sind oder wenn dieses Programm etwas grundlegend falsches hat. (Ich sehe viele von ihnen auf einem viel größeren Programm, das die gleichen Mechanismen verwendet, aber ich habe es auf das Minimum reduziert, um hier zu veröffentlichen).
Jede Hilfe ist willkommen.
Danke,
Jack
%Vor%kompiliere mit gcc main.c und starte mit ./ a.out 2 2
%Vor%gcc -v
Verwenden von integrierten Spezifikationen. COLLECT_GCC = gcc COLLECT_LTO_WRAPPER = / usr / lib / gcc / x86_64-linux-gnu / 4.8 / lto-wrapper Ziel: x86_64-linux-gnu Konfiguriert mit: ../src/configure -v --with-pkgversion = 'Ubuntu 4.8.2-19ubuntu1' --with-bugurl = Datei: ///usr/share/doc/gcc-4.8/README.Bugs --enable-languages = c, c ++, java, go, d, fortran, objc, obj-c ++ --prefix = / usr --programm-suffix = -4.8 --enable-shared --enable-linker-build-id --libexecdir = / usr / lib --without -included-gettext --enable-threads = posix - mit-gxx-include-dir = / usr / include / c ++ / 4.8 --libdir = / usr / lib --openable-nls --with-sysroot = / - -enable-clocale = gnu --enable-libstdcxx-debug --enable-libstdcxx-time = ja --enable-gnu-eindeutiges-objekt --disable-libmudflap --enable-plugin --with-system-zlib - disable-browser-plugin --enable-java-awtt = gtk --enable-gtk-kairo --with-java-home = / usr / lib / jvm / java-1.5.0-gcj-4.8-amd64 / jre - -enable-java-home - mit-jvm-root-dir = / usr / lib / jvm / java-1.5.0-gcj-4.8-amd64 - mit-jvm-jar-dir = / usr / lib / jvm -exports / java-1.5.0-gcj-4.8-amd64 - mit-arch-directory = amd64 - mit-ecj-jar = / usr / teilen / java / eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --mit-bogen-32 = i686 --mit-abi = m64 --mit-multilib-l ist = m32, m64, mx32 --mit-tune = generisch --enable-checking = release --build = x86_64-linux-gnu --host = x86_64-linux-gnu --target = x86_64-linux-gnu Thread-Modell : posix gcc Version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
ldd --version
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.3) 2.19 Copyright (C) 2014 Free Software Foundation, Inc. Dies ist freie Software; Siehe die Quelle für Kopierbedingungen. Es gibt KEINE garantie; nicht einmal für Handelsüblichkeit oder Eignung für einen bestimmten Zweck. Geschrieben von Roland McGrath und Ulrich Drepper.
Ich verstehe immer noch nicht genau, warum valgrind diese nicht initialisierten Fehler zeigt genau , aber ich gebe mein Bestes, um zu erklären, was ich bis jetzt verstanden habe;
Beim Ausführen und Analysieren des Programms über Valgrind und basierend auf Informationen von man-Seiten von sapcontext (3) und getcontext (3), denke ich, dass es einige Kontext-Swaps nicht erkennen kann tid 0 zu tid 1 und der sapcontext von tid 1 zurück zu tid 0)
Lesen Sie weiter unten als : wer stapelt [Nummer des Anrufs]: Funktionsaufruf
Also, ich denke, Funktionsaufruf-Ablaufverfolgung ist so etwas wie folgt:
main: swapcontext (main, tid 0) - & gt;
main [tid 0's 1. Funkruf]: func () - & gt;
tid 0: swapcontext (tid 0, tid 1) - & gt; { Stapel = & gt; Zeitraum 0 }
tid 1: func () - & gt;
swapcontext (tid 1, tid 0) - & gt; { Stapel = & gt; Zeitraum 1 }
tid 0 [2. Anruf]: func () - & gt;
zurück sofort seit n_switchs = 2 - & gt;
pop tid 0 [2. Aufruf]: func () Stapelrahmen vom Stapel von tid 1 - & gt; {1 Uninitialisierter Zugriff nach valgrind}
tid 0 [2. Anruf]: func () beendet - & gt; prüft uc_link; findet Engine_uc (Hauptkontext) dort eingestellt - & gt;
Ab hier werden die Dinge für mich unklar, aber folgendes scheint die wahrscheinliche Spur zu sein:
setzt sigprocmask zurück - & gt; {2. nicht initialisierter Zugriff} setcontext () s zurück zum Hauptkontext - & gt; {3. Uinitialisierter Zugriff?} { Stack = & gt; Haupt }
Bei der Rückkehr kam der Stapelrahmen für den ersten Anruf von [tid 0] aus den mains Stapel- & gt;
main [tid 0's erster Aufruf]: func () beendet auch wegen n_switchs = 2 - & gt; überprüfe uc_link; findet Engine_uc wieder - & gt; setzt sigprocmask zurück - & gt; {nicht nicht initialisierter Zugriff?}
Bei der Rückkehr wird der Stapelrahmen für main: swapcontext () aus den mains herausgeholt Stapel - & gt;
setcontext () s zurück zum Hauptkontext - & gt; {4. Uninitialisierter Zugriff ?} { Stapel = & gt; Haupt }
wir kommen zurück zu main (), free stuff und beenden
Einige Referenzen:
Hinweis: Ich weiß, dass dies keine vollständige Antwort ist, aber ich wollte nicht so lange im Kommentarbereich posten; also hier gepostet.
Sie müssen Valgrind über die Änderung des Stapels informieren. Lies hier ein Beispiel Ссылка
Dies ist der richtige Code:
%Vor%