Hallo, wir haben SuSE Linux 7.3. Darauf haben wir folgendes Problem: Ein Programm, dass 1200MB RAM verbraucht, stuerzt irgendwann mit 'segmetation fault' ab. Und das, obwohl die Grenzen des Rechners noch lange nicht erreicht sind. Mehrere kleine Programme gleichzeitig, die zusammen mehr Resourcen verbraten, laufen anstandslos durch. Der Hersteller des Compilers (Portland Group) schwoert, dass das nicht an seinem Compiler liegt. Gibt es irgendwo versteckt im System noch eine Begrenzung, wieviel ein einzelner Prozess brauchen darf? Oder ist da ein generelles Linux-Problem? Gruss und Dank im voraus fuer die Antwort, ulrich hiller Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller@mpia.de
* On Mon, 19 May 2003 at 17:13 +0200, Ulrich Hiller wrote:
wir haben SuSE Linux 7.3. Darauf haben wir folgendes Problem: Ein Programm, dass 1200MB RAM verbraucht, stuerzt irgendwann mit 'segmetation fault' ab. Und das, obwohl die Grenzen des Rechners noch lange nicht erreicht sind. Mehrere kleine Programme gleichzeitig, die zusammen mehr Resourcen verbraten, laufen anstandslos durch. Der Hersteller des Compilers (Portland Group) schwoert, dass das nicht an seinem Compiler liegt. Gibt es irgendwo versteckt im System noch eine Begrenzung, wieviel ein einzelner Prozess brauchen darf? Oder ist da ein generelles Linux-Problem?
Ja freilich. Auf 32bit Systemen sind unter Verwendung eines flat memory models maximal 4 GB pro Prozess adressierbar. Einen Teil davon zwackt sich der Kernel ab. Je nach jewähltem Splitpunkt bleiben dann idR irgendwas bei 2-3.5 GB pro Prozess (Details finden sich in den Kernelsourcen). Zusätzlich zu dem real verbrauchten Speicher zählen Files, die per mmap in den Speicher eingeblendet werden. Wenn dann aber ein segfault kommt, ist etwas im Programm faul. Als Möglichkeit fällt mir da mal ein, daß der malloc Speicher allokiert wird. Da (im Adressraum) aber nichts mehr frei ist, kommt ein NULL-Pointer retour, und dieser wird dann munter dereferenziert, ohne vorher zu prüfen. Was ist das für eine Anwendung? Selbst geschrieben? => Schau mal an der Absturzstelle, ob da irgendwo ein malloc/calloc in der Gegend herumläuft. Zugekauft? => Hersteller auf die Füße treten. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Ulrich Hiller schrieb:
wir haben SuSE Linux 7.3. Darauf haben wir folgendes Problem: Ein Programm, dass 1200MB RAM verbraucht, stuerzt irgendwann mit 'segmetation fault' ab. Und das, obwohl die Grenzen des Rechners noch lange nicht erreicht sind. Mehrere kleine Programme gleichzeitig, die zusammen mehr Resourcen verbraten, laufen anstandslos durch. Der Hersteller des Compilers (Portland Group) schwoert, dass das nicht an seinem Compiler liegt. [...]
Was ist denn das fuer ein Programm? Das sieht ehrlich gesagt eher so aus, als sein das Programm nicht sauber implementiert und wuerde einen Speicherfehler produzieren. Evtl. wird das Allokieren etc. des Speichers nicht ueberwacht und Fehler ab- gefangen oder es wird auf uninitialisierten Speicher zuge- griffen, o.ae. Es sieht so aus, als stehe Dir der Quellcode zur Verfuegung - dann compiliere das Programm mal mit Debug- ging-Flag und schau Dir den Absturz im Debugger (z.B. ddd) an. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hallo, On Mon, 19 May 2003, Thomas Hertweck wrote:
Ulrich Hiller schrieb:
wir haben SuSE Linux 7.3. Darauf haben wir folgendes Problem: Ein Programm, dass 1200MB RAM verbraucht, stuerzt irgendwann mit 'segmetation fault' ab. Und das, obwohl die Grenzen des Rechners noch lange nicht erreicht sind. Mehrere kleine Programme gleichzeitig, die zusammen mehr Resourcen verbraten, laufen anstandslos durch. Der Hersteller des Compilers (Portland Group) schwoert, dass das nicht an seinem Compiler liegt. [...]
Was ist denn das fuer ein Programm? Das sieht ehrlich gesagt eher so aus, als sein das Programm nicht sauber implementiert und wuerde einen Speicherfehler produzieren. Evtl. wird das Allokieren etc. des Speichers nicht ueberwacht und Fehler ab- gefangen oder es wird auf uninitialisierten Speicher zuge- griffen, o.ae. Es sieht so aus, als stehe Dir der Quellcode zur Verfuegung - dann compiliere das Programm mal mit Debug- ging-Flag und schau Dir den Absturz im Debugger (z.B. ddd) an.
Ansonsten: ein 'ltrace -S -s 128 -f ...' kann dabei helfen, den Ort des Segfaults einzugrenzen... Ein HW-Speicherfehler kann's u.U. natuerlich auch sein, wenn aber der Speicherbereich durch andere Anwendungen normal auch verwendet wird, dann ist's wohl ein SW-Fehler (was eh wahrscheinlich zu sein scheint). Achso: F'up (nicht gesetzt) bitte nach suse-programming, da ist das IMO besser aufgehoben ;) -dnh -- 65: Internet-Boom Schwachsinn (Theo Lieven)
participants (4)
-
Adalbert Michelic
-
David Haller
-
Thomas Hertweck
-
Ulrich Hiller