Seltsamer Fehler bei vollem Speicher

otze

genau.

Ich finde es eigentlich total gruselig, dass cerr überhaupt alokiert. Das heißt, dass es mit dieser Implementierung des C++ Standards keine ausfallsichere Fehlerausgabe gibt. ätzend. Würde ich fast unte rdie Kategorie "bug" einordnen.

Ethon

otze schrieb:

genau.

Ich finde es eigentlich total gruselig, dass cerr überhaupt alokiert. Das heißt, dass es mit dieser Implementierung des C++ Standards keine ausfallsichere Fehlerausgabe gibt. ätzend. Würde ich fast unte rdie Kategorie "bug" einordnen.

Afaik gibt es sogar bool operator==(char const*) für std::string, die den char* erst einen String kopieren anstatt direkt strcmp aufzurufen. Keine Ahnung wie man auf so ne Idee kommt.

SeppJ

otze schrieb:

genau.

Ich finde es eigentlich total gruselig, dass cerr überhaupt alokiert. Das heißt, dass es mit dieser Implementierung des C++ Standards keine ausfallsichere Fehlerausgabe gibt. ätzend. Würde ich fast unte rdie Kategorie "bug" einordnen.

Das scheint nicht das cerr-Objekt zu sein, sondern der Operator <<.

plizzz

Ethon schrieb:

Ich meinte dass bei der Ausgabe konvertiert wird.

Könnte a.) an einer affigen Implementierung liegen oder b.) daran, dass aus irgendeinem Grund kein operator<< für const char* verfügbar ist und der für std::string genommen wird, inklusive Konvertierung.

Versuch mal das hier:
inline void mem_test(void *pointer, const char *function_name)
    {
        if(!pointer)
        {
            char const* msg = "ERROR: memory allocation failed in function ";
            std::cerr.write(msg, strlen(msg));
            std::cerr.write(function_name, strlen(function_name));
            std::cerr.put('\n');
            std::cerr.flush();
            
            exit(EXIT_FAILURE);
        }
    }

Das funktioniert leider auch nicht. Ist auch nicht allzu wichtig an sich (die Methode mit dem reservierten Speicher funktioniert, auch wenn sie nicht allzu schön ist), aber irgendwie schon interessant zu wissen, was da genau passiert.

otze

SeppJ schrieb:

otze schrieb:

genau.

Ich finde es eigentlich total gruselig, dass cerr überhaupt alokiert. Das heißt, dass es mit dieser Implementierung des C++ Standards keine ausfallsichere Fehlerausgabe gibt. ätzend. Würde ich fast unte rdie Kategorie "bug" einordnen.

Das scheint nicht das cerr-Objekt zu sein, sondern der Operator <<.

mit dem letzten Post hätten wir das jetzt ausgeschlossen.

pyhax

vlt das char const * str = "ERROR: ...." ? Allokiert das Speicher?

SeppJ

pyhax schrieb:

vlt das char const * str = "ERROR: ...." ? Allokiert das Speicher?

So ungefähr sizeof(char*). Auf dem Stack. Außerdem noch zwei weitere Zeiger für die Funktionsparameter und ein paar weitere Verwaltungsdaten. Wenn auf dem Stack nicht mal mehr 50-100 Byte frei sind, hat man natürlich ein Problem. Ich weiß jetzt nicht genau, was der Threadersteller für ein System hat und selbst wenn, dann wüsste ich nicht, wie dieses genau arbeitet. Aber da der Heap von Unten wächst und der Stack von Oben, kann durchaus sein, dass dies nicht mehr funktioniert, sofern wirklich alles bis auf's letzte Byte voll ist. Oder gibt es Systeme, in denen Speicher für den Stack im Voraus reserviert ist?

hustbaer

SeppJ schrieb:

Oder gibt es Systeme, in denen Speicher für den Stack im Voraus reserviert ist?

Ich kenne eigentlich nur solche Systeme.
Bzw. zumindest der Adressraum ist reserviert.
Und wenn der Adressraum des Stack nicht mehr mit Speicher hinterlegt werden kann, dann bekommt man keinen std::bad_alloc. Was auch immer dann passiert, das OS behandelt den Fall selbst.

Es ist nicht davon auszugehen, dass ganz zu Programmbeginn angelegter Speicher in der Nähe des Stacks liegt, und die Freigabe dürfte ja hier nur dann passieren, wenn der Speicher bereits voll ist.

Ich habe den Streambuffer von std::cerr im Verdacht, möchte aber nicht ausschließen, dass die Ursache noch tiefer liegt - wo kein Speicher mehr ist, kann viel daneben gehen. Vielleicht wäre es einen Versuch wert, statt std::cerr mal puts bzw. fputs zu bemühen.

hustbaer

Ich würde auch eher auf den Streambuffer tippen, als auf den Ausgabeoperator.
Mit dem Debugger Reinsteppen könnte Klarheit bringen.

Wenn man ganz sicher gehen will: selbst Ausgabefunktionen mit der native OS API (win32, ...) programmieren.