Externe Bibliothek buggy?

Skym0sh0

Ich hab das vorhin auch mal getestet nebenbei.
Wenn der Ctor von std::string einen nullptr bekommt fliegt eine Exception, damit kann ich dann was anfangen.

Aber nichtsdestotrotz habe ich hier mal ein wenig geändert:

std::string str() const
	{
		const char * ptr = HandleContent(this->m_handle);
		assert(ptr != nullptr);

		const std::size_t size = this->size();

		std::cout << "\tAdress of ptr: " << std::addressof(ptr) << std::endl;
		std::cout << "\t" << "Size: \"" << size << "\", Ptr: \"" << ptr << "\""<< std::endl;

		return std::string(ptr, size);
	}

Gleicher Fehler, gleiche Ausgabe, bis auf die Adresse des ptr.

Starte ich das Programm nicht aus Eclipse sondern aus der Console, dann steht da was von Speicherzugriffssfehler. Valgrind meint auch irgendwas von Segmentationsfault und dass knapp 345000 Bytes "possibly lost" sind. Aber das ist das erste mal, dass ich mit Valgrind arbeite, daher kann ich da noch nix itnerpretieren...

knivil

Duerfen die Funktionen ueberhaupt aufgerufen werden, wenn der Content ungueltig ist?

std::cout << "\t" << "Size: " << size << ", Ptr: " << ptr << std::endl;

Nun, was passiert hier, wenn ptr ungueltig ist?

Wenn der Ctor von std::string einen nullptr bekommt fliegt eine Exception, damit kann ich dann was anfangen.

Und wenn er nicht 0 ist aber trotzdem Muell?

dann steht da was von Speicherzugriffssfehler

Das passiert beim Dereferenzieren von Pointern. Wieviele Pointer hast du und wo werden sie dereferenziert? Vielelicht liesst du nochmals die Spezifikation zu HandleContent.

Skym0sh0

knivil schrieb:

Duerfen die Funktionen ueberhaupt aufgerufen werden, wenn der Content ungueltig ist?

Laut Doku:

Gibt den Inhalt eines Rückgabepuffers zurück.

Der zurückgegebene Zeiger verweist auf ein Character-Array, das alle in den Rückgabepuffer
geschriebenen Bytes sowie eine abschließende Null-Terminierung enthält. Dieses Array existiert so
lange im Speicher, bis der Rückgabepuffer entweder erneut beschrieben oder freigegeben wird.

Return:
- Bei Übergabe eines gültigen Handles: Zeiger auf den null-terminierten Rückgabepuffer-Inhalt
- Bei Übergabe des ungültigen Wertes NULL: NULL

Parameter:
in : Handle auf einen mit CreateHandle() angelegten
Rückgabepuffer. Dieser Rückgabepuffer darf nicht bereits
freigegeben worden sein.

knivil schrieb:

std::cout << "\t" << "Size: " << size << ", Ptr: " << ptr << std::endl;
Nun, was passiert hier, wenn ptr ungueltig ist?

Dann kommt irgendein Müll da raus. Aber es wird ja explizit nichts ausgegeben, weil der Inhalt von ptr = {'\0'} ist.

knivil schrieb:

Wenn der Ctor von std::string einen nullptr bekommt fliegt eine Exception, damit kann ich dann was anfangen.

Und wenn er nicht 0 ist aber trotzdem Muell?

Du meinst ins sonst wohin zeigt? Tja, dann würde der Müll lesen, tut er aber nicht.

Edit: Das oben ist die gesamte Doku zu dem Rueckgabepuffer (wie er wirklich heisst).
Ich habe selbst keine eigenen Pointer hier reingebracht ausser denen, die ihr im Code seht. Mir wurde (unter anderem hier im Forum) immer gelehrt, richtig C++ zu schreiben mit RAII, Ressourcenzuständigkeiten usw. Und daher will ich die Bibliothek so in Klassen wrappen, dass sowohl Exceptionsicherheiten gegeben sind, als auch Speicher und Ressourcen wieder richtig und vollautomatisch freigegeben werden. (Das sehe ich doch gar nicht mal so falsch, denke ich.)

Aber wenn in den fremden Funktionen Fehler gemacht werden, kann ich da nichts machen, ausser alles auf ein Minimalbeispiel zu reduzieren und daraus eine Bugreport zu machen.

Skym0sh0 schrieb:

Wenn der Ctor von std::string einen nullptr bekommt fliegt eine Exception, damit kann ich dann was anfangen.

basic_string(const charT* s, size_type n, const Allocator& a = Allocator());
6 Requires: s shall not be a null pointer and n < npos.

Mit anderen Worten: Bei nullptr bekommst du UB.

Skym0sh0

UB heisst doch, dass die Compilerhersteller machen können was sie wollen.
Und ich habe das vorhin auch mal durchprobiert und da wurde mir ein std::logic_error geworfen (GCC 4.7.3)

Deine Aussagen, dass es kein nullptr ist reichen mir noch nicht, nachher kompilierst Du mit NDEBUG, oder so.

std::string str() const
    {
        const char * ptr = HandleContent(this->m_handle);
        return ptr==nullptr ? "" : std::string(ptr);
    }

Gleicher Absturz?

Können wir die Library ausprobieren, oder ist das was internes?

Skym0sh0 schrieb:

UB heisst doch, dass die Compilerhersteller machen können was sie wollen.

Ne, das ist implementation-defined behavior Ub heißt, dass sich keiner drum scheren muss. Bei implementation-defined behavior muss man sich drum scheren, d.h. was passiert, muss irgendwo dokumentiert sein.

Skym0sh0

Furble Wurble schrieb:

Deine Aussagen, dass es kein nullptr ist reichen mir noch nicht, nachher kompilierst Du mit NDEBUG, oder so.
std::string str() const
    {
        const char * ptr = HandleContent(this->m_handle);
        return ptr==nullptr ? "" : std::string(ptr);
    }
Gleicher Absturz?

Können wir die Library ausprobieren, oder ist das was internes?

Ja, leider was internes.
Und ja, gleicher Absturz.

Tja...dumm das.

Bist Du sicher, dass Du keinen Zwischenschritt vergessen hast? Z.b. schreibt die Doku ja irgendwas von "Rückgabepuffer beschreiben".

Und sonst: Code reduzieren.
Ein Durchlauf
1. Create
2. mach was mit Content
3. Release
ohne Wrapper funktioniert?

Darf evtl. nur ein solch Handle zu jeder Zeit existieren?

Ratlos,
FW

Skym0sh0

int main()
{
	Handle x = CreateHandle();

	std::cout << "x: " << x << " -> " << HandleContentLength(x) << std::endl;
	std::cout << "x: " << HandleContent(x) << std::endl;

	int r = ReleaseHandle(x);

	std::cout << r << std::endl;

	return 0;
}

Ausgabe:

x: 0xf7472000 -> 0
Speicherzugriffsfehler (Speicherabzug geschrieben)

Also es müssen rein von der Funktionalität mehrere Handles gleichzeitig existieren dürfen, da manche Funktionen der Bibliothek mehrere dieser Handles erwarten und da auch was reinschreiben.

Das Problem, auch bei meinem großen Programm, wo diese Dinger drin eingearbeitet waren, und auch wirklich nachprüfbar was in den Puffern stand und extrahiert wurde nach string, crashte es bei Rücksprung aus der Funktion zum Aufruf.

knivil

Wenn es was internes ist, dann hast du ja die Moeglichkeit in die Implementation zu schauen.

Skym0sh0

Nein. Es ist nichts internes unserer Firma hier. Aber es ist nichts öffentliches.
Ich habe einige *.so's, einige *.dll's und ein paar Header-Dateien.

Und glaub mir, wenn wir da an die Interna drankämen, wäre das ganze Ding schon neugeschrieben, damit es nicht nur mal läuft sondern auch Fehler überhaupt mal meldet (aber das ist 'ne andere Geschichte).

Aber um es mal beim Namen zu nennen, es geht um den Elster Rich Client (ERiC 18.1.4.65766) und die Handles sind RueckgabepufferHandle's (ja, es ist eine deutsche Bibliothek)

DocShoe

Mir fällt auf, dass HandleContentLength 0 zurückgibt, vielleicht darfst du in dem Fall HandleContent gar nicht aufrufen? Sagt die Doku irgendwas dazu? Oder tritt der Fehler immer auf, auch wenn HandleContentLength einen Wert >0 zurückgibt?

Edit:
Ist das der gleiche Verein, der auch den Bundestrojaner programmiert hat?
*Duck und weg*

Skym0sh0

Gibt die Länge des Inhalts eines Rückgabepuffers zurück.
Die zurückgegebene Zahl entspricht der Anzahl von Bytes, die von einer zuvor aufgerufenen ERiC
API-Funktion in den Rückgabepuffer geschrieben wurden. Die Null-Terminierung, die bei Aufruf von
EricRueckgabepufferInhalt() an das zurückgegebene Character-Array angefügt wird, wird bei dieser
Längenangabe nicht berücksichtigt.

Parameter:
in : Handle auf einen mit EricRueckgabepufferErzeugen() angelegten
Rückgabepuffer. Dieser Rückgabepuffer darf nicht bereits
freigegeben worden sein.

Rückgabe:
- Bei Übergabe eines gültigen Handles: Anzahl der in den Rückgabepuffer geschriebenen Bytes
- Bei Übergabe des ungültigen Wertes NULL: 0

Skym0sh0 schrieb:

Gibt die Länge des Inhalts eines Rückgabepuffers zurück.
Die zurückgegebene Zahl entspricht der Anzahl von Bytes, die von einer zuvor aufgerufenen ERiC
API-Funktion in den Rückgabepuffer geschrieben wurden. Die Null-Terminierung, die bei Aufruf von
EricRueckgabepufferInhalt() an das zurückgegebene Character-Array angefügt wird, wird bei dieser
Längenangabe nicht berücksichtigt.

Parameter:
in : Handle auf einen mit EricRueckgabepufferErzeugen() angelegten
Rückgabepuffer. Dieser Rückgabepuffer darf nicht bereits
freigegeben worden sein.

Rückgabe:
- Bei Übergabe eines gültigen Handles: Anzahl der in den Rückgabepuffer geschriebenen Bytes
- Bei Übergabe des ungültigen Wertes NULL: 0

Und hast du getestet, ob das stimmt? Insbesondere wenn size 0 liefert?

Skym0sh0

Also wenn ich die Länge des nullptr abfrage kommt wie dokumentiert auch 0 raus.

Greife ich auf irgendeine Speicheradresse zu crasht es (wie eigentlich erwartet), irgendwelche Checks macht ERiC also nicht.

Also ich denke, ich habe die Spezifikationen dieser Doku schon getestet. o_O

Was meinst du genau?

DocShoe schrieb:

Ist das der gleiche Verein, der auch den Bundestrojaner programmiert hat?
*Duck und weg*

Offensichtlich nicht, denn der Bundestrojaner hat doch halbwegs funktioniert, wenn ich mich recht erinnere
Aber laut Wikipedia kommt der Bundestrojaner von der Digi Task GmbH im Auftrag der Bayerischen Staatsregierung. Und ERiC kommt auch aus Bayern (Steueramt oder Finanzamt oder sowas). Mh, ich frag mal grad die Illuminanten.....

Skym0sh0 schrieb:

Also wenn ich die Länge des nullptr abfrage kommt wie dokumentiert auch 0 raus.

Spannend wird es ja erst bei der Umkehrung. Evtl. ist der zugriff auf HandleContent() ungültig, wenn HandleContentLength()==0 - auf jeden Fall ist er überflüssig.

Allerdings verstehe ich das hier:

Skym0sh0 schrieb:

Das Problem, auch bei meinem großen Programm, wo diese Dinger drin eingearbeitet waren, und auch wirklich nachprüfbar was in den Puffern stand und extrahiert wurde nach string, crashte es bei Rücksprung aus der Funktion zum Aufruf.

(so unverständlich es auch geschrieben sein mag)
dahingehend, dass auch bei HandleContentLength()!=0 der Wrapper crasht.
Richtig?

Skym0sh0

Ja

knivil

Also wenn ich die Länge des nullptr abfrage kommt wie dokumentiert auch 0 raus.

Und was bedeutet Laenge? Groesse des Buffers? Warum dann nicht eins? Hast du die Bibliothek korrekt initialisiert?

Ansonsten zusammenfassend: Es crasht also recht haeufig. Aber bei anderen funktioniert die Bibliothek ...

Skym0sh0

Wie bei anderen funktioniert sie?

Ich würde mal behaupten, dass es nur eine Handvoll ernste Anwender davon in Deutschland gibt. Zumal das die neue Version ist.

Zweitens läuft sie bei auch ohne Probleme. Unter Windows per MSVC. Nur Linux mit dem GCC spackt rum.

Ausserdem bin ich eigentlich nicht an einer Q&D Lösung interessiert, dass es so gerade klappt, sondern an einer ordentlichen Lösung, die mir nicht sämtlichen RAM stiehlt falls mal eine Exception fliegen sollte.

Initialisieren ist nicht nötig, wenn ichd as richtig im Kopf habe. Ich werde da morgen nochmal nach suchen, ob weitere Initialisierungsschritte notwendig sind.

Um dir mal einen Eindruck zu geben von dem Ding und der letzten Version:
Bei manchen Fehlern wurde keine Fehlercode returnt oder eine Exception geworfen. Auch ein kontrollierter Absturz war nicht programmiert.
Das Problem war: Es ging etwas nicht, obwohl alle Returncodes sagten "Alles ok".
Wo ist der Knackpunkt? Tja, in einer Logging-Datei die bei einem Run schon mehrere Tausend Zeilen umfasst stand irgendwo dann eine Zahl, eine ganz normale Zahl. Das war der Fehlercode.

Ist das etwa kein Luxus??