4. Stack corruption

Stack corruption

  • D

    Danke für die Info!

    So ich habe den Test mal eingebaut und ich bekomme wirklich einige Fehler a

    warning: format ‘%d’ expects type ‘int’, but argument 10 has type ‘const char *’
    warning: too many arguments for format
    warning: format ‘%E’ expects type ‘double’, but argument 10 has type ‘char *’

    Baue die alle mal aus aber ich habe nicht das Gefühl das es mein initiales Problem mit dem Stack lösen wird.

    0

  • Meinst du nicht, dass du bevor du dich diffizilen dynamischen Problemen in Multithreadumgebungen widmest, erstmal die groben Bugs die der Compiler dir schon mitteilt, beseitigen solltest?
    Armv6/Linux wird doch durch ein valgrind supported, oder was meinst du damit, dass du nichts dazu gefunden hast?
    http://sourceforge.net/mailarchive/forum.php?thread_name=201010211806.40304.jseward%40acm.org&forum_name=valgrind-announce

    0
  • ?

    Er versteht die Asserts nicht.
    Er versteht die Warnings nicht.
    Also ich bin der Meinung, er ist in einer Multithreading-Umgebung so gut auf gehoben, dass er sich nicht mehr um solche Nebensächlichkeiten kümmern muss.

    0
  • ?

    @TS
    Der Tip vom Wutz Valgrind ist nur was für Weicheier.
    Ignorieren, genauso wie die Warnings.

    0
  • D

    @Wutz
    Danke für den Hinweiß. Scheinbar bin ich echt blind den in der Announce und auf der Homepage finde ich nur infos zu Armv7 und nicht Armv6. Werde da aber gerne noch mal weiter suchen.

    @noergel
    Nicht wirklich hilfreich!
    Klar habe ich Warnings beseitigt und auch versucht raus zu finden warum der Assert kommt. Scheint ein Bug in meiner libmudflap Version zu sein.
    In der nächsten Version haben sie da einiges geändert.
    Bin leider auf eine gcc Version festgenagelt. Aber mal sehen ob ich die libmudflap alleine hochziehen kann.

    0
  • Mod

    Klar. Wenn der Debugger einen Fehler anzeigt, dann ist der Fehler bestimmt im Debugger 🙄 .

    0
  • ?

    Dann nehm ich alles zurück

    0
  • D

    SeppJ schrieb:

    Klar. Wenn der Debugger einen Fehler anzeigt, dann ist der Fehler bestimmt im Debugger 🙄 .

    So habe ich es natürlich nicht gemeint!

    Wenn ich so eine Meldung bekomme, dann suche ich natürlich als erstes danach was sie mir sagen soll:
    mf-runtime.c: 1164: __mf_register: Assertion `rc==0' failed.

    Finde dazu nicht sehr viel nur das es dazu einen fix bzw patch für die lib gab.

    0
  • ?

    Da ist Mudflap beim Thread-Locking durcheinander gekommen. Eigentlich sollte so etwas nicht passieren; wenn du allerdings vorher schon über tausend Speicherzugriffsfehler hast, kann an der Stelle niemand mehr für definiertes Verhalten garantieren. Räum den Kram erstmal auf, bevor du dich damit herumschlägst.

    0
  • D

    Hat etwas gedauert aber ich habe nun eine neuere gcc Version gebaut und damit beendet sich mein Program nicht mit dem Assert.
    Leider tut es nun nicht mehr das was es immer gemacht hat.
    Bleibt irgendwann einfach stehen.
    Wie geschrieben sind die paar vsnprintf Fehler draußen.
    Waren nur wenige Aufrufe die aber immer wieder gemacht wurden. Daher die hohe Anzahl.
    Habe jetzt nur den Sprung von gcc 4.3.3 auf 4.3.6 gemacht.
    Sollte ich noch etwas Zeit haben, mache ich noch einen Test mit einer recht aktuellen Version.
    Hoffe nur das es dann keine Probleme gibt das das system und alle anderen libs mit der 4.3.3 übersetzt wurden.

    0
  • Mod

    Deine Probleme sind ganz sicher keine Compilerprobleme! Auch der inzwischen etwas ältere GCC 4.3 ist schon sehr sehr standardkonform. Dein Programm ist schlicht und einfach voller Fehler, das kann man sogar über das Internet hinweg merken. Wieso merkst du es nicht?

    0
  • D

    Das nicht der Compiler dafür verantwortlich ist das mein Programm einen Fehler hat steht außer frage. Darum geht es ja auch nicht.
    Ihr habt mir nur etwas Hoffnung gemacht das ich den gcc dazu verwenden kann den Fehler zu finden oder wenigstens ein zu kreisen.

    Mudflap hat mir zwar geholfen einen anderen Fehler zu finden aber das eigentliche Problem ist mir noch unbekannt und ungelöst.

    Im Coredump ist der Callstack oft defekt oder irgend ein Pointer ist überschrieben. Oft ist ein Pointer der vorher z.B. auf das Next Element in einer Liste gezeigt hat auf einmal 0x65 und damit kann ich natürlich nicht mehr auf den Pointer zugreifen. Frage mich auch warum immer 0x65.

    Meine Vermutung ist das irgend jemand über seine grenzen Schreibt oder einfach irgendwo in den Stack schreibt. Vielleicht liege ich auch ganz falsch.

    Ich danke euch auf jeden Fall für die teilweise sehr interessanten und auch guten Tipps.

    0
  • D

    Ich wollte die Sachen noch mal zum Abschluss bringen.
    Der Bug ist durch mühselige Handarbeit doch noch gefunden worden.

    An einer Stelle wurde für den Zugriff auf ein Array ein falsches Define benutzt welches *weit* über die Grenzen irgendwo die 0x65 hingeschrieben hat.
    Gefunden haben wir es in dem wir geschaut hatten warum es immer 0x65 ist und wo die her kommt. Als wir die Zahl dann gegen 0x66 ausgetauscht hatten und dann im Speicher eine 0x66 stand, wussten wir das es was mit dem Define zu tun hat.
    Alle Stellen untersucht und dann das Array gefunden.

    Echt schwer zu findender Bug.

    Wollte es hier nur noch mal erwähnen.

    0
Anmelden zum Antworten