3. Was soll ich denn jetzt tun?

Was soll ich denn jetzt tun?

  • ?

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

    hustbaer schrieb:

    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 🤡

    Alles was du beschrieben hast, kann Valgrind. Valgrind merkt sogar, wenn du von uninitialisierten Variablen liest.

    0

  • Er. Jo 🙂

    Nachdem ich rein unter Windows arbeite, und es leider keinen Valgrind Port für Windows gibt, vergesse ich immer wieder auf Valgrind.

    0

  • Ich habe vorher sehr viel mit dem C++ Builder gearbeitet, aber den verwende ich nicht mehr. Dort hatte ich nie Probleme, da brauchte ich für das beheben solcher Probleme nur 1 Minuten und nicht 3 Stunden.
    Ich bin wahrscheinlich einfach nur unfähig den gdb richtig zu benutzen / installieren etc.
    Ich habe vergessen zu erwähnen, dass ich mingw benutze und auf Windows schreibe.

    0
  • ?

    Tim06TR schrieb:

    Ich habe vergessen zu erwähnen, dass ich mingw benutze und auf Windows schreibe.

    Da gibts nur eins: Installier dir Linux (am besten auf einer freien Partition, sonst in einer VM).
    Linux ist einfach eine bessere IDE als Windows.

    0
Anmelden zum Antworten