On Monday 09 May 2011 08:02:40 [email protected] wrote: > Fabian Hänsel <[email protected]>: > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Lug-dd maillist - [email protected] https://ssl.schlittermann.de/mailman/listinfo/lug-dd
