Bad alloc obwohl noch speicher frei

kartoffelsack

Wir haben einen Tomcat laufen, der via JNI eine windows-DLL einbindet.

Irgendwo scheinen wir ein resourcen-Leck zu haben. Aber irgendwie ist das alles nicht klar:

Wir haben folgende Symptome:
- Der Speicherverbrauch steigt, wenn man genau hinsieht, leicht an (man merkt es aber erst über mehrere Stunden)
- Tritt das Problem auf, äußert es sich au Java-Seite so, dass keine Threads mehr erzeugt werden können
- Zur selben Zeit melden die C-DLLs bad_alloc-Exceptions

Nun ist es aber so, dass der Rechner, wenn das Problem autritt, garnicht ausgelastet ist:

Momentan (der Fehler ist vor ein paar Minuten aufgetreten) ist der Resourcen-Verbrauch des Prozesses 'tomcat5.exe' folgendermaßen:
Speichernutzung: 281.488
Maximale Speichernutzung: 468.388
Virtueller Speicher: 284.480
Handles: 2989
Threads: 322

Status des Rechners:
Realer Spüeicher: 2096524 (2 Gig)
Verfügbar: 1200204

Zugesicherter virtueller Speicher: 599388
Grenzwert: 4035236
Maximalwert 987792

Hat irgendjemand ne Idee? Ist einer der Werte auffällig? Was kann ich noch überprüfen? Wo kann ich ansetzen?

groovemaster

Aus der Ferne kann man da nur schwer 'ne Dianose stellen. Am besten mal ein entsprechendes Diagnose Tool verwenden, oder selber einen kleinen Memory Tracer einbinden. So kann man wenigstens sehen, wo fehlende Speicherfreigaben sind und was allokiert wurde. Evtl. ist ja eine Arraygrösse beim Allokieren nicht initialisiert, so dass dort irgendein grosser Wert drinsteht, der dann zu der bad_alloc Exception führt.

kartoffelsack

Mit Diagnose-Tools haben wir schon versucht was zu finden. Auch mit selbstgeschriebenen MemTracern. Das Problem ist, dass wir java und mehrere DLLs haben. Nicht gerade das beste Terrain für die Dinger.

Das mit der uninitialisierten Variable ist ne gute Idee. hm, aber auch nicht recht logisch anhand der Symptome: bad_allocs an mehreren Stellen, Java kann keine Threads aufmachen.

Was halt einfach komisch ist, ist doch, dass der Speicherverbrauch weit unter den Grenzen des Rechners liegt.

Findet ihr die Zahl von 300 Threads verdächtig?

TheBigW

Findet ihr die Zahl von 300 Threads verdächtig?

Nö, wieso? Bei mir laufen schon im Normalbetrieb min 400.

Habt Ihr die Möglichkeit die Dll mal seperat zu testen ohne in Java einzubinden, bzw. die Java Seite einzeln zu testen mit einer "dummy"- Variante der DLL?

kartoffelsack

Wir haben einige C++ und Delphi-Applikationen, bei denen die DLLs problemlos laufen.

In Verbindung mit dem Java haben wir aber einige Probleme:

- Das besagte scheinbare Resourcen-Leak (es gibt schon irgendwo ein kleineres Speicherleck - ein paar MB pro Stunde, aber das kann doch nicht der Grund für die Probleme sein, wo der Rechner doch noch ne Menge Speicher frei hat)

- FLT_STACK_CHECK_EXCEPTIONS (liegt wohl am Zusammenspiel zwischen den DLLs die mit Borland compiliert sind und der JNI-DLL, die mit VC++ gemacht ist)

Die Möglichkeit der Dummy-DLLs haben wir leider nicht, da die das System an andere Realsysteme anbinden. Bei Labortests hatten wir die Probleme eigentlich nie.

TheBigW

Na dann beibt ja eigentlich nur ein Fehler auf Java - Seite bzw. irgend etwas JNI mystisches.
Gebt Ihr complexe Datentypen über JNI rüber oder nur native? Ich weiß nicht, wie der GC es handhabt mit Objekten, die irgendwie über JNI "nach außen" verbunden sind. Eventuell kann er die dann nicht "kassieren", weil sie ja für Ihn im Niemandsland liegen.

Vielleicht ist die Frage im Java Forum dann besser aufgehoben....