Externe Bibliothek buggy?

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

hustbaer

@Skym0sh0
Also hast du die "size erst prüfen" Variante jetzt schon probiert oder nicht?
Also sowas da

std::string str() const 
{ 
	if (std::size_t const s = this->size())
		return std::string(HandleContent(this->m_handle), s);
	else
		return std::string();
}

Wäre ja irgendwie naheliegend das zu versuchen.
Und wenn es funktioniert würde ich es auch nicht als "Q&D" bezeichnen.

Skym0sh0

Ja, die Idee kam mir mittlerweile auch. Das probiere ich jetzt.

Aber andererseits, wieso stürzt das Programm dann ab, wenn die size > 0 ist und der Puffer gefüllt ist?

Edit: Also hustbaers Idee ist probiert. Die Längenabfrage rettet mich in Fällen, wo die Größe tatsächlich 0 ist.
Das Problem bleibt jedoch: sind sinnvolle Dinge in den Rückgabepuffer geschrieben und die Länge damit > 0 (in meinem Fall knapp 115000 Zeichen), dann crasht es nach dem Pufferzugriff.

Skym0sh0

int main()
{
	EricRueckgabepufferHandle x = 0;

	assert(x == nullptr); // passt
	x = EricRueckgabepufferErzeugen();
	assert(x != nullptr); // passt

	EricRueckgabepufferHandle address = x;
	assert(x == address); // geht
	uint32_t s = EricRueckgabepufferLaenge(x);
	assert(x == address); // assertion nicht erfuellt

    return 0;
}

o_O

Muss ich mehr zu der Bibliothek sagen?