Externe Bibliothek buggy?

[Furble Wurble]

ptr (in Z. 35) ist nicht nullptr ? Der darf es nämlich nicht sein für den C'tor von std::string .

[Skym0sh0]

Furble Wurble schrieb:

ptr (in Z. 35) ist nicht nullptr ? Der darf es nämlich nicht sein für den C'tor von std::string .

Nein. Der Inhalt ist zwar (wie eigentlich gewollt) 0, aber damit kommt std::string ja klar.

Selbst wenn ichd as return zu dem hier ändere, crasht es:

return "";

[Furble Wurble]

Skym0sh0 schrieb:

Furble Wurble schrieb:

ptr (in Z. 35) ist nicht nullptr ? Der darf es nämlich nicht sein für den C'tor von std::string .

Nein. Der Inhalt ist zwar (wie eigentlich gewollt) 0, aber damit kommt std::string ja klar.

Selbst wenn ichd as return zu dem hier ändere, crasht es:

return "";

Moment. Wenn es ein nullptr ist kann auch schon die Ausgabe crashen. Dann ist auch das (nachträgliche eingebaute) assert zu spät.
Und: nein, der C'tor kommt nicht mit einem nullptr klar.

[manni66]

Vielleicht liefert HandleContent(this->m_handle) Müll, wenn nichts enthalten ist, d.h. in deiner Ausgabe von ptr greifst du schon ins Klo.

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

[excepter]

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)

[Furble Wurble]

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?

[out]

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.

[Furble Wurble]

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

[manni66]

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