Aber das wäre ja kein Problem, wenn das Programm nicht vollkommen normal verlaufen würde, wenn der Debugger dran hängt. Welcher Fehler macht denn sowas?
Versteckt sich vor dem Debugger!
Wie soll ich das denn jetzt finden?

EDIT: GCC 4.8.0 + gdb 7.5

EDIT: Ich glaube das liegt am zusätzlichen delay. Sobald ich eine Pause einbaue läufts normal weiter. Aber ich benutze nichtmal threads oder so.

bei dem das Programm sich "still" verabschiedet.

Beschreib das mal genauer.

Aber das wäre ja kein Problem, wenn das Programm nicht vollkommen normal verlaufen würde, wenn der Debugger dran hängt. Welcher Fehler macht denn sowas?

Könnte allgemein undefiniertes Verhalten sein. Ist aber ungewöhnlich, dass es im Debugger nicht nachvollziehbar ist.

Ist das Programm parallelisiert? Dann wäre meine Wette auf eine Race Condition. Da hast du dann nämlich unterschiedliches Zeitverhalten mit Debugger und ohne, was die Beobachtung perfekt erklärt.

Versteckt sich vor dem Debugger!
Wie soll ich das denn jetzt finden?

Kommt drauf an, was genau '"still" verabschiedet' bedeutet. Allgemeine Ideen: valgrind, core dump, mit dem Debugger an den laufenden Prozess anhängen.

Ich hantiere extrem viel mit Iteratoren herum

Dann: -D_GLIBCXX_DEBUG

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

blub[12] = 'x';

ahmm...

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

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

Ich habe den Fehler jetzt auf eine Funktion festgenagelt.

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

Was is der Fehler nu?

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

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?

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.

So guckt sich das doch niemand an.

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

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

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.

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

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

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.

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