On Monday 09 May 2011 08:02:40 holger.dietze@arcor.de wrote:
Fabian Hänsel fabtagon@gmx.de:
Lösung gefunden: das malloc() selbst hat nur wenig mit dem segfault zu tun. Ursache ist ein voller Heap.
Ich hatte sinngemäß Folgendes: void func_with_malloc(int length) {
char data[length]; unsigned char *srcsrc; srcsrc = (unsigned char*) malloc(length);}
Wenn nun length zu groß wurde, fühlte sich das anschließende malloc bedrängt.
Unklar ist mir, wieso ich in dem Fall nicht bei CALL einen Heap Overflow oder ähnliches gemeldet bekomme.
Weil vor dem malloc() noch keine Schreiboperationen im Speicher erfolgen. Die Definition von data[] setzt erstmal bloss den Stackpointer deutlich nach unten. Erst das Schreiben des Arguments zu malloc() oder der Ruecksprung- Adresse (je nach Call-Konvention) in den Stack zeigt das Problem.
Guter Einwurf! Ich hatte die dynamische Stack-Allocation nicht gesehen.
Es ist im Allgemeinen keine gute Idee sehr grosse Datenblöcke auf dem Stack abzulegen. Ein wenig googeln sagt uns, dass das Stack-Segment eines Thread zw. 8 und 10MB groß werden darf - normalerweise ist das jenseits alles Notwendigen, aber Dein Code kann das locker überspringen. Bei embedded Systemen kann die erlaubte Stackgröße sogar darunter liegen (ich habe schon Werte von 32kB in freier Wildbahn gesehen).
Kleiner Hinweis: mit GNU LibC ist jedes Programm ein multi-thread Programm. Spätestens, wenn Du nach einer IP-Adresse fragst macht die Libc einen Helper- Thread auf.
Wenn Du C++ verwendest kannst Du das Problem sehr leicht umgehen, indem Du Dir eine Array-Klasse schreibst, die die eigentlichen Daten auf den Heap legt. (QByteArray und QString aus Qt machen das so.)
Konrad