Ich verfolge seit gestern einen lästigen Bug, der nur im Release Modus auftritt (d.h. wenn Zeug wegoptimiert wird).

Ich habe folgende Klasse (Code ist vollständig):

extern std::atomic<unsigned int> taskIDCounter; //wird in ner cpp auf 0 initialisiert

class Task
{
public:
    Task() : started(false), unfinishedTasks(1), taskID(++taskIDCounter), parentID(0) {};
    Task(unsigned int parentID_) : started(false), unfinishedTasks(1), taskID(++taskIDCounter), parentID(parentID_)/*, taken(0)*/ {};
    virtual ~Task() = 0 {};

    virtual void execute() final
    {
        this->doActualWork();
        unfinishedTasks--;
    }

    virtual void doActualWork() = 0;
public:
    unsigned int taskID;    //ID of this task
    unsigned int parentID;  //ID of the parent of this task
    bool started;
    std::atomic<unsigned int> unfinishedTasks; //Number of child tasks that are still unfinished
    std::vector<unsigned int> dependencies; //list of IDs of all tasks that this task depends on

};

Der entsprechende Bug tritt nicht auf, wenn ich die Klasse mit #pragma optimize("",off) besähe, so dass der Compiler Optimierungen bei der Klasse nicht anwendet. Das riecht natürlich erstmal nach UB, aber irgendwie erkenne ich bei der Klasse nichts (die Tut ja auch nix außerordentlich komplexes).

Gibt's hier etwas, das UB auslösen könnte?

Task() : started(false), unfinishedTasks(1), taskID(++taskIDCounter), parentID(0) {}; 
    Task(unsigned int parentID_) : started(false), unfinishedTasks(1), taskID(++taskIDCounter), parentID(parentID_)/*, taken(0)*/ {};

Wieso kein Default-Argument? Oder delegierende Konstruktoren (C++11)?

virtual void execute() final
    {
        this->doActualWork();
        unfinishedTasks--;
    }

... Wieso zum Teufel ist die Funktion virtuell, wenn sie in einer (nicht erbenden) Basisklasse schon als final deklariert wird...?

die Tut ja auch nix außerordentlich komplexes

Den ganzen Code haste uns ja laut eigener Aussage gar nicht gezeigt.

virtual ~Task() = 0 {};

Ok, das kann nur Pseudo-Code sein...

die Tut ja auch nix außerordentlich komplexes

Den ganzen Code haste uns ja laut eigener Aussage gar nicht gezeigt.

Doch, das ist tatsächlich der ganze Code. Ihr seht zwar nicht, wie er benutzt wird, aber der Fehler ist auf diese Klasse reduzierbar.

Sone schrieb:

~Edit: Anfangs nehme ich an, du zeigst uns den echten Code.~

Task() : started(false), unfinishedTasks(1), taskID(++taskIDCounter), parentID(0) {}; 
    Task(unsigned int parentID_) : started(false), unfinishedTasks(1), taskID(++taskIDCounter), parentID(parentID_)/*, taken(0)*/ {};

Wieso kein Default-Argument? Oder delegierende Konstruktoren (C++11)?

Hast Recht, Default-Argument wäre besser.

virtual void execute() final
    {
        this->doActualWork();
        unfinishedTasks--;
    }

... Wieso zum Teufel ist die Funktion virtuell, wenn sie in einer (nicht erbenden) Basisklasse schon als final deklariert wird...?

Ups, das ist ein überbleibsel aus ner Zeit, als Task von ner anderen Klasse geerbt hat. Danke für den Hinweis (ändert nichts am Bug).

void execute(){
    assert(this);
    assert(this->doActualWork);
    assert(unfinishedTasks);
    assert(started); //vielleicht nicht wichtig

    this->doActualWork(); 
    unfinishedTasks--; 
}

Vielleicht wird ein Pointer falsch gecastet und deswegen greift this->doActualWork daneben. Das könnte den Unterschied bei Release und Debug erklären.

Ich sehe keinen Fehler, aber ich würde ein paar asserts einbauen:

void execute(){
    assert(this);
    assert(this->doActualWork);
    assert(unfinishedTasks);
    assert(started); //vielleicht nicht wichtig
    
    this->doActualWork(); 
    unfinishedTasks--; 
}

Vielleicht wird ein Pointer falsch gecastet und deswegen greift this->doActualWork daneben. Das könnte den Unterschied bei Release und Debug erklären.

Ich vermute eher nen Compiler-Bug. Wenn ich die Klasse dupliziere (namen ändere, extra dateien dafür, etc.) und dann in nem minimalen Beispiel verwende, existiert der Bug nicht. Wenn ich im gleichen minimalen Beispiel die originale Task Klasse verwende, tritt der Bug auch auf. Lustigerweise: Wenn ich dann im normalen Code (also nicht minimalbeispiel), die Verwendung von der Task Klasse auf die duplizierte Klasse umstelle, tritt der Bug auch auf - auch im minimalen Beispiel. Und ebenso tritt der Bug mit der originalklasse im Minimalbeispiel (im "Haupt-Code" schon) nicht auf, wenn ich im nicht-minimal-beispiel-code die duplizierte Klasse, und im Minimalbeispielcode die originale Klasse verwende.

D.h. in der Benutzung außerhalb des minimalen Beispiels der Task Klasse muss irgendwas passieren, dass dem Compiler sagt: Das hier kannst du wegoptimieren, und dann krachts irgendwo. Das ist aber aufgrund der Natur des Bugs noch verwirrender, weil in der auslösenden Stelle nur Zeiger rumgeschoben werden. Konkret:

manni66 schrieb:

Und was ist der Bug?

Wenn dich Details wirklich interessieren (sollte für das Beispiel aber nicht relevant sein): http://stackoverflow.com/questions/18550883/cds-library-michael-deque-causes-crash-when-pushing-back-derived-type-of-custom

Im Prinzip mach ich ein push_back in einen Container von irgendeiner library (nicht STL), wobei der Container aber nur einen Zeiger auf Task* als Typ T hat und ich einen Zeiger auf einen abgeleiteten typen push_back()en will. Und da gibts nen Crash. Konkret stell ich fest, dass der Bug da auftritt, weil ich direkt davor und direkt danach ein cout<<"hallo"<<std::endl; mache und nur das cout vor dem push_back() ankommt bevor der Crash passiert.

verschwindet der Fehler, wenn du aus dem std::atomic irgendwas anderes machst?

Nö, leider nicht.

edit: aha, jetzt da du std::atomic erwähnst... ich hab das ganze Projekt noch mal neu kompiliert, und eine neue Warnung entdeckt. Anscheinend modifiziert ne Template-Spezialisierung für 64 bit unsigned ints in xatomic.h (ein VS2012-Header) ebp ohne vorher ein backup auf den Stack zu schieben und danach wieder zu poppen. Ich glaub die verwendete Bibliothek benutzt ein atomic des Typs, bei dem das gemacht wird, was den Crash verursachen könnte. Muss mal bisschen nachforschen, brb.

virtual ~Task() = 0 {};

Ok, das kann nur Pseudo-Code sein...

Wieso das?

Sone schrieb:

virtual ~Task() = 0 {};

Ok, das kann nur Pseudo-Code sein...

Wieso das?

Weil das kein gültiges Standard-C++ ist. Oder es ist eine Implementations-Erweiterung von VC++...

§10.4/2 schrieb:

A function declaration cannot provide both a pure-specifier and a definition

Sone schrieb:

virtual ~Task() = 0 {};

Ok, das kann nur Pseudo-Code sein...

Wieso das?

Man kann pure virtual functions nur außerhalb der Klassendefinition definieren.

Man kann pure virtual functions nur außerhalb der Klassendefinition definieren.

Das weiß er doch - würde mich schwer wundern wenn nicht.

Nathan schrieb:

Man kann pure virtual functions nur außerhalb der Klassendefinition definieren.

Das weiß er doch - würde mich schwer wundern wenn nicht.

Tachyon fragte, wieso das nur Pseudocode sein kann, ich gab einen Grund.
Wieso meinst du, dass er das dann schon weiß, wenn er doch fragt?
Du hast ihm doch auch geantwortet.

Sone schrieb:

Nathan schrieb:

Man kann pure virtual functions nur außerhalb der Klassendefinition definieren.

Das weiß er doch - würde mich schwer wundern wenn nicht.

Tachyon fragte, wieso das nur Pseudocode sein kann, ich gab einen Grund.
Wieso meinst du, dass er das dann schon weiß, wenn er doch fragt?
Du hast ihm doch auch geantwortet.

Stimmt, tut mir Leid. Tachyon sollte das aber wissen, der Kerl ist schon viel länger dabei als ich oder du.

Was den Körper von Destruktoren von abstrakten Klassen angeht: Ist erlaubt.

Klar, aber nicht bei der Deklaration. Dass sie definiert werden müssen ist klar.

Nathan schrieb:

Sone schrieb:

Nathan schrieb:

Man kann pure virtual functions nur außerhalb der Klassendefinition definieren.

Das weiß er doch - würde mich schwer wundern wenn nicht.

Tachyon fragte, wieso das nur Pseudocode sein kann, ich gab einen Grund.
Wieso meinst du, dass er das dann schon weiß, wenn er doch fragt?
Du hast ihm doch auch geantwortet.

Stimmt, tut mir Leid. Tachyon sollte das aber wissen, der Kerl ist schon viel länger dabei als ich oder du.

Was den Körper von Destruktoren von abstrakten Klassen angeht: Ist erlaubt.

Klar, aber nicht bei der Deklaration. Dass sie definiert werden müssen ist klar.

Achso, dann hab ich falsch verstanden worum es geht, sorry

[[...]Tachyon sollte das aber wissen, der Kerl ist schon viel länger dabei als ich oder du.[...]

Ach ja, da war was. Ich habe schlicht die Definition überlesen...