3. Was soll ich denn jetzt tun?

Was soll ich denn jetzt tun?

  • ?

    Schonmal valgrind probiert?
    Du verwendest wahrscheinlich viele rohe Pointer, da passieren leicht Fehler und UB. Mit Valgrind machst du recht schnell den Fehler ausfindig.

    0

  • Ja ist schon ein wenig was.
    Ich hantiere extrem viel mit Iteratoren herum, denn ich benutze einen Cursor der durch das Programm hüpft, das geben ich auch an Lambdas und andere Funktionen weiter.
    Ich schau mal ob ich es reduzieren kann. Normalerweise brauche ich nie mehr als 50 Zeilen posten, aber da wird schwierig.
    Schreib gleich nochmal...

    0
  • ?

    Tim06TR schrieb:

    Ich hantiere extrem viel mit Iteratoren herum

    Dann: -D_GLIBCXX_DEBUG

    0

  • pointee schrieb:

    Tim06TR schrieb:

    Ich hantiere extrem viel mit Iteratoren herum

    Dann: -D_GLIBCXX_DEBUG

    Ah vielen Dank für den Tipp. Jetzt bekomme ich zumindest einen vernünftigen Hinweis.

    Kopie aus Console:

    Enter number: 6
    77
    d:\mingw\include\c++\4.8.0\bits\basic_string.h:828: std::basic_string<_CharT, _T
    raits, _Alloc>::const_reference std::basic_string<_CharT, _Traits, _Alloc>::oper
    ator[](std::basic_string<_CharT, _Traits, _Alloc>::size_type) const [with _CharT
    = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::b
    asic_string<_CharT, _Traits, _Alloc>::const_reference = const char&; std::basic_
    string<_CharT, _Traits, _Alloc>::size_type = unsigned int]: Assertion '__pos <=
    size()' failed.

    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.

    Process returned 3 (0x3) execution time : 1.047 s
    Press any key to continue.

    ahmm...

    0
  • ?

    std::string blub;

    blub[12] = 'x';

    0
  • ?

    Tim06TR schrieb:

    ahmm...

    Jetzt kannst du mit gdb anrücken, der fängt die Assertion ab und du kannst einen schönen Backtrace erstellen.

    0

  • Ich habe den Fehler jetzt auf eine Funktion festgenagelt.

    EDIT: Ich schreib sie neu. Dann optimier ich die gleich...

    0
  • ?

    Tim06TR schrieb:

    Ich habe den Fehler jetzt auf eine Funktion festgenagelt.

    EDIT: Ich schreib sie neu. Dann optimier ich die gleich...

    Was is der Fehler nu?

    0

  • Habe mich vertan. Das war es doch nicht.
    Ich lande komischerweise nun bei meinem Matheparser.

    Es kann doch auch nicht normal sein, dass wenn ich nen string auf die Watchlist setze, dass der mich plötzlich in "std::string::size()" wirft?

    EDIT: + Der Debugger und das Programm verabschieden sich ohne ein mucks zu machen sobald wenn ich über die Stelle springen will.

    [Inferior 1 (process 4380) exited with code 03]
    Debugger finished with status 0

    0
  • C
    Mod

    Tim06TR schrieb:

    Habe mich vertan. Das war es doch nicht.
    Ich lande komischerweise nun bei meinem Matheparser.

    Es kann doch auch nicht normal sein, dass wenn ich nen string auf die Watchlist setze, dass der mich plötzlich in "std::string::size()" wirft?

    Ist das ein Frage oder eine Feststellung? und für wen?

    0
  • ?

    Hast du Lust den Quellcode hochzuladen, würde mich gerade mal interessieren.

    0

  • Sekunde dann kopiere ich das kurz richtig zusammen.

    0

  • 1. Ich habe mir nicht übermäßig viel Zeit genommen das Programm sauber zu strukturieren, außer in manchen einzelnen Sourcedateien, die ziemlich sauber sind.
    Im ScriptInterpreter code ist auch ein bisschen was an code redundanz in den Funktionen.

    Die Scriptdatei habe ich in den Ordner gelegt. Zum Testen hatte ich den festen Pfad in der Main angegeben.
    http://81.169.156.131:81/TEMPORARY/Code.zip
    Ich habs mit Codeblocks geschrieben.

    Falls ich was vergessen haben sollte, dann ergänze ich es sofort.

    EDIT: Den Matheparser habe ich eigentlich auch von oben bis unten auf Herz und Nieren getestet. Der läuft, wenn allein gestartet auch ganz problemlos.

    0
  • Mod

    Minimalbeispiel! Portabel!

    So guckt sich das doch niemand an.

    0

  • Ich habe doch keine Ahnung, wo ich suchen muss.
    Normalerweise kann ich alle Probleme sofort lösen. Aber ich kann nicht sonderlich gut debuggen, wenn er nicht an die Problemstelle springt, sondern bye bye sagt.

    EDIT: Und out hatte danach gefragt also hab ich es kurz geuppt.
    Ich such weiter.

    0
  • ?

    Hui 386 Fehler bekomm ich grad, mal schauen:D

    0

  • Erkenntnis: Skripvariablen dürfen keine einstellige Namen haben. Das komische ist nur, dass der Mathe Parser alleine keine Fehler produziert (Wenn ich ihn in einem eigenen Programm teste). Allerdings im Script Parser eingebaut geht irgendwas schief, obwohl es der selbe Code ist. Wahrscheinlich stellt sich nachdem ich das hier abgeschickt hab raus, dass ich wieder mal in irgendeiner Zeile was verzwuckelt habe, was "zufällig" funktioniert.

    Tut mir leid, dass ich diesen wirklich informationslosen Thread aufgemacht habe. Aber das mit dem Debugger hat mich doch ein wenig aufgeregt... (und tut es immernoch, denn mit dem gdb komme ich auf keinen grünen Zweig, das Einzige was ich damit "normal" kann ist Haltepunkte benutzen und normalerweise auch in den Call Stack gucken wenn was schief geht).

    Ich muss mein OS updaten und wieder zu Microsofts IDE wechseln...

    EDIT: Ich stelle den MatheParser jetzt auch auf iteratoren um, das war überfällig

    0

  • Ok ich habe aber doch noch ein Frage:
    EDIT: ohne debugger ist das anstrengend, aber ich habe es gefunden.

    Vor der folgenden Zeile wurde nicht geprüft, ob Characters.length() größer als (j+start) ist.

    still_true &= (OperatorSet[i].oc[j] == Characters[j+start]);

    Das hätte aber vorher schon schief gehen müssen. Es sei denn es war im vorher egal über den Rand heraus zu lesen.

    0
  • ?

    Hatte ich dann Recht. 🙂

    Tim06TR schrieb:

    Das hätte aber vorher schon schief gehen müssen. Es sei denn es war im vorher egal über den Rand heraus zu lesen.

    stackoverflow schrieb:

    In 100% of the cases I've seen or heard of, where a C or C++ program runs fine in the debugger but fails when run outside, the cause has been writing past the end of a function local array. (The debugger puts more on the stack, so you're less likely to overwrite something important.)

    0

  • out schrieb:

    stackoverflow schrieb:

    In 100% of the cases I've seen or heard of, where a C or C++ program runs fine in the debugger but fails when run outside, the cause has been writing past the end of a function local array. (The debugger puts more on the stack, so you're less likely to overwrite something important.)

    Lol.
    "Runs fine" ist gut. Der Debugger prüft schliesslich beim Verlassen der Funktion ob die Guard-Bytes vor und hinter den Arrays noch OK sind.
    Sobald man da reinschreibt sollte es schnalzen. (OK, nicht sobald man reinschreibt, aber sobald die Funktion der das Array gehört "return" macht.)

    Und der Herr der das schrieb scheint nicht gerade viel Erfahrung mit fehlerhaften Programmen zu haben. Ein Fall den ich vergleichbar oft hatte wie Probleme mit Arrays waren nicht initialisierte Variablen.
    Ein nicht initialisierter bool ist im Debug immer true (bei MSVC und vermutlich auch den meisten anderen Debuggern/Runtime-Libs).
    Im Release ist er dann ... naja was er halt zufällig ist.

    Auch ein schöner Fehler ist das Lesen ausserhalb der Arraygrenzen. Gerne auch bei Heap-Arrays. Das besonders "tolle" dabei ist dass der Fehler im Release auch oft so-gut-wie nicht reproduzierber ist, weil meistens hinter nem Array immer noch Speicher "da" ist -- die Fälle wo das Array genau auf ner Page-Granze endet sind ja eher selten.

    Sowas findet man dann nur mit Glück oder wirklich guten Debugging-Tools. Also nicht den MSVC Debugger sondern so Geschütze ala BoundsChecker, Intel Inspector etc. Die kosten dann $$$ und machen das Programm auch so richtig schön lahm 🤡

    0
Anmelden zum Antworten