[java] oorzaak outofmemory error vinden

[Alarmnummer]

Ik krijg zo heel nu en dan wel eens een out of memory error (per ongeluk oneindige recursie ofzo...), maar deze fout is echt enorm lastig om op te sporen omdat je dus geen stacktrace krijgt. Hoe vinden jullie de oorzaak van een out of memory error?

(Het gaat me dus niet erom dat je vm gewoon te weinig geheugen heeft).

[edit]
Hoe zit het trouwens bij .NET? Wat krijg je te zien als je bv een oneindige recursieve aanroep hebt?

[ Voor 15% gewijzigd door Alarmnummer op 05-11-2003 13:11 ]

[whoami]

In .NET krijg je een StackOverflowException bij een oneindige recursie.
Ik krijg ook geen stacktrace te zien, zelfs als ik de exceptie catch, en ik wil de StackTrace property uitlezen, dan krijg ik een lege string terug.

[Alarmnummer]

Hoe spoor jij dan de oorzaak op? Ik vaak met system.out checken waar ik wel ben geweest en waar niet. En meestal zit het in de 'nieuwe' code, dus daar eerst ff kijken.

*heeft hekel aan debugger.. werkt er nooit mee*

[yrew]

Ik heb ooit weleens jpobe gebruikt. Hiervan was ik wel onder de indruk. Met jProbe kun je op object niveau kijken hoeveel geheugen je programma in beslag neemt. Op die manier kun je vrij snel het object vinden wat het geheugen opvreet. Er zitten nog 101 andere mogelijkheden in jProbe, alleen heb ik hiervoor nog niet de tijd gehad.

Verder beperk ik mezelf door zomin mogelijk functies/modules aan te zetten en van hieruit steeds een module erbij. Totdat mijn geheugen excessief stijgt en dan weet ik iig in welk deel van mijn programma ik moet zoeken. Als je daar eenmaal bent moet je snel je geheugen lek kunnen vinden. Waarbij ik wel moet zeggen dat dit theoretisch heel leuk klinkt, maar in de praktijk toch vaak de nodige problemen opleverd. Het zit hem vaak in kleine dingen.

[DaCoTa]

Voor dit soort problemen zijn er debuggers en profilers gemaakt. Als je een hekel hebt aan debuggers vraag ik me af of je er ooit mee gewerkt hebt zoals het hoort. Kijk bijvoorbeeld eens naar Eclipse, met een erg fraaie geintegreerde debugger. Een eenvoudigere manier om bugs op te sporen is er gewoon niet.

Mijn oude methode van debugging (System.out debugging) heb ik lang gedaan, maar sinds ik een debugger gebruik kan wel zeggen dat ik bugs VEEL eerder kan vinden.

Daarnaast, om code te profilen of geheugen gebruik omlaag te krijgen gebruik ik sinds een aantal weken JProfile. In de eerste dag van gebruik heb ik in twee uur tijd 60% van de processing tijd van een verwerkingsprocedure afgesloopt. Iets wat zonder profiler absoluut onmogelijk is. Verder blijft bij een OOME de JVM door de profiler in leven en kan je naar alle geinstantieerde objecten kijken en laten berekenen hoe hun pad naar de JVM loopt. Oftwel, je kunt zien waarom al die 100.000en Strings niet geGC'd zijn en jouw JVM om zeep hebben geholpen.

Kortom: het wordt tijd om naar de moderne tijd te gaan qua ontwikkeltools... Eclipse is gratis, JProfile kun je 30 dagen op proef krijgen. Maar er zijn ook anderen (o.a. JProbe), maar daar heb ik geen ervaring mee.

[Glimi]

Als ik dat probleem zou hebben en ik zou zo 1-2-3 niet echt doorhebben waar het in zit, dan zou ik even snel vanaf het begin een thread maken, en die laten controleren met methodes uit Runtime
• freeMemory()
• maxMemory

Komen ze er dan achter dat de boel vol begint te lopen, dan zou traceInstructions en traceMethodCalls misschien wat kunnen opleveren.

[Alarmnummer]

DaCoTa schreef op 05 november 2003 @ 14:07:
Voor dit soort problemen zijn er debuggers en profilers gemaakt. Als je een hekel hebt aan debuggers vraag ik me af of je er ooit mee gewerkt hebt zoals het hoort.

Ik heb oa een debugger bij Codeguide en bij IDEA, dus daaraan geen gebrek. Ik vind ze alleen geen toegevoegde waarde hebben boven een system.out.

En voordat het een flame gaat worden over debuggers, afgezien van de outofmemory error heb ik mijn bugs vrij snel te pakken (unit testen helpt ook goed om de meeste bugs erg vroeg te pakken).

Daarnaast, om code te profilen of geheugen gebruik omlaag te krijgen gebruik ik sinds een aantal weken JProfile. In de eerste dag van gebruik heb ik in twee uur tijd 60% van de processing tijd van een verwerkingsprocedure afgesloopt. Iets wat zonder profiler absoluut onmogelijk is. Verder blijft bij een OOME de JVM door de profiler in leven en kan je naar alle geinstantieerde objecten kijken en laten berekenen hoe hun pad naar de JVM loopt. Oftwel, je kunt zien waarom al die 100.000en Strings niet geGC'd zijn en jouw JVM om zeep hebben geholpen.

Kortom: het wordt tijd om naar de moderne tijd te gaan qua ontwikkeltools... Eclipse is gratis, JProfile kun je 30 dagen op proef krijgen. Maar er zijn ook anderen (o.a. JProbe), maar daar heb ik geen ervaring mee.

Ik heb vroeger wel eens gewerkt met JProbe en JProfiler, maar ik vind dat nogal een heavy duty oplossing om een outofmemory error op te sporen (bij een recursieve aanroep). Ik vind het jammer dat de stacktrace (die beschikbaar is) niet afgedrukt wordt. Misschien dat hiervoor te weinig resources beschikbaar zijn, maar er moet vast wel een oplossing voor te vinden zijn.

Als je idd moet profilen dan zijn tools zoals JProbe en JProfiler wel onmisbaar natuurlijk, maar ik betwijfel of ze bij de outofmemory error ook een oplossing geven.

[edit]
Je kan natuurlijk ook outofmemory error hebben omdat je bv een memleak hebt. Idd kan een tools zoals JProbe daarbij enorm helpen. Maar mijn voornaamste probleem is eigelijk een recursieve aanroep (heb het wel eens gehad bij het sterker typeren (covariant return type) van een methode.

[ Voor 8% gewijzigd door Alarmnummer op 05-11-2003 14:22 ]

[Robtimus]

Oneindige recursie levert in Java toch ook een StackOverflowError op?

[Dash2in1]

IceManX schreef op 05 november 2003 @ 15:21:
Oneindige recursie levert in Java toch ook een StackOverflowError op?

Verschilt geloof ik.. beetje vreemd

[Verwijderd]

Dash2in1 schreef op 06 november 2003 @ 00:28:
[...]

Verschilt geloof ik.. beetje vreemd

Het ligt er een beetje aan volgens mij wat je recursieve code doet. Als er niet veel geheugen wordt gebruikt door de recursieve method loop je waarschijnlijk tegen een StackOverflowError aan, maar bij geheugen intensieve recursieve functies is gewoon eerder het geheugen van de JVM vol dan de stack.

Dit levert bijvoorbeeld een StackOverflowError op:

Java:

public void overflow()
{
   overflow();
}

En dit hoogstwaarschijnlijk een OutOfMemoryError:

Java:

public void outOfMem()
{
   int[] memFill = new int[10000];
   for (int i = 0; i < memFill.length; i++) memFill[i] = i;
   outOfMem();
}

[Alarmnummer]

Verwijderd schreef op 06 november 2003 @ 01:09:
[...]

Ik heb het net ff gechecked en het was idd een stackoverflowexception.

Maar eigelijk ging het me dus om deze rakker.. recursieve aanroep van functies.