ich habe das Problem, dass ich eine externe Bibliothek nutze und den verdacht habe, dass dort ein Bug drin ist. Aber da ich nach dem ganzen Gesuche und experimentieren total mit den Nerven durch bin, würde ich euch bitten, mal einen Blick auf den Code zu werfen, ob der denn auch das macht, was er soll:

#include <iostream>
#include <string>
#include <cassert>

class Releaser
{
	Handle m_handle;

	Releaser(Releaser const&);
	Releaser& operator=(Releaser);

public:
	Releaser()
	: m_handle(CreateHandle()) // != nullptr
	{
		std::cout << "Created on Adress: "<< m_handle << std::endl;
	}

	~Releaser()
	{
		int result = ReleaseHandle(this->m_handle);
		std::cout << "Destruction Result: " << result << std::endl;
	}

	Handle& get()
	{
		return this->m_handle;
	}

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

		std::cout << "\t" << "Size: " << size << ", Ptr: " << ptr << std::endl;
		assert(ptr != nullptr);
		return std::string(ptr, size);
	} // hier crasht es, aber erst wenn die Funktion verlassen wird

	std::size_t size() const
	{
		std::size_t s = HandleContentLength(this->m_handle);

		return s;
	}
};

void foo()
{
	Releaser x;
	Releaser error;

	std::cout << "x: " << x.get() << " -> " << x.size() << std::endl;
	std::cout << "e: " << error.get() << " -> " << error.size() << std::endl;

	//std::cout << Foo(error.get(), x.get()) << std::endl; // fuellt bei Bedarf die Handles

	std::cout << "e: " << error.str() << std::endl;
	std::cout << "x: " << x.str() << std::endl;
}

int main()
{
	foo();

	return 0;
}

Wobei ich weder die Implementierung noch das genauere Interface des Handles kenne(n kann). Es sieht nur ungefähr so aus:

struct Handle_
{ /* ... */ };
typedef Handle_* Handle;

Handle CreateHandle(); // erzeugt ein Handle

int ReleaseHandle(); // zerstört Handle und gibt eventuelle Fehlercodes zurück

const char* HandleContent(Handle); // gibt den Inhalt des Handles zurück

uint32_t HandleContentLength(Handle); // gibt die Länge des Inhalts des Handles zurück
// auf meinem GCC 4.7.3 mit -m32 kompiliert ist sizeof(std::size_t) == sizeof(uint32_t)

Mein Ziel war es, da die Bibliothek C ist, da ein bisschen C++-Style drumherum zu wrappen. In dem Fall halt RAII, damit ich nicht vergesse die Handles freizugeben.

Problem: Unter Windows alles gut und schön. Unter Linux stürzt das Programm ohne Angabe von Gründen ab.
Die Ausgabe ist:

Created on Adress: 0x8a63050
Created on Adress: 0x8a63b68
x: 0x8a63050 -> 0
e: 0x8a63b68 -> 0
	Size: 0, Ptr:

Es fehlt also die Ausgabe des ersten "xXx.str()" Aufrufs sowie alles danach...

Ich möchte eigentlich nur sichergehen, dass ich keinen Fehler gemacht habe und die Bibliothek buggy ist.

Bei deinem "Releaser" hast du die Rule of Three verletzt, das kann natürlich zu double deletes führen.

Jain. Ich habs nachträglich grad reingebaut, es gab sowohl vorher als auch nachher keinen Fehler.

Und das was ich gepostet habe war schon das vollständige abstürzende Programm. Ich sehe doch richtig, dass da keiner der Kopiermethoden(Copy-Ctor und CopyAssignment-Operator) gebraucht wird oO

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

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

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.

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.

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.

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?

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.

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.

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

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.

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)

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

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

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?

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

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?

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