Closed GoogleCodeExporter closed 8 years ago
I tried to analyse a heap dump from android, and it seems, that there are lots
of Session Objects hanging around. But i could not find the reason why they are
still referenced.
Original comment by keinh...@gmail.com
on 26 Oct 2014 at 9:35
This is a question for the mailing list. The bugtracker is not a discussion
forum.
Original comment by noelgrandin
on 26 Oct 2014 at 1:48
Why is this an discussion? Its clearly a bug, because i get an outofmemoryerror.
Original comment by keinh...@gmail.com
on 26 Oct 2014 at 2:21
Hi,
Well, it's not clear where the bug is, it could be in your application. I don't
think it makes sense to log a bug if you don't know yet.
Did you read
http://h2database.com/html/tutorial.html?highlight=Android&search=android#androi
d ?
Original comment by thomas.t...@gmail.com
on 26 Oct 2014 at 4:19
Hi,
yes i've read that already.
And i made a simple example to demonstrate the bug (see code above).
Maybe it is my Android Applications fault... So i simplified my App to include
only the example from above. Here is the complete Activity class. Its the one
and only Activity. No UI, nothing but this:
package de.exware.ffmanager.android;
import java.io.File;
import java.sql.*;
import android.app.Activity;
import android.os.Bundle;
import android.os.Environment;
public class FFManager extends Activity
{
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
}
@Override
protected void onResume()
{
super.onResume();
try
{
Class.forName("org.h2.Driver");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
}
File extfile = getExternalFilesDir(null);
if(extfile == null)
{
extfile = Environment.getExternalStorageDirectory();
}
File file = new File(extfile,"database/db");
String dburl = "jdbc:h2:" + file.getAbsolutePath()
+ ";FILE_LOCK=FS"
+ ";PAGE_SIZE=1024"
+ ";CACHE_SIZE=128";
Connection con = null;
Statement stm = null;
while(true)
{
try
{
con = DriverManager.getConnection(dburl, "sa", "");
stm = con.createStatement();
stm.execute("xy");
}
catch(Exception ex)
{
try
{
stm.close();
con.rollback();
con.close();
}
catch (SQLException e)
{
e.printStackTrace();
}
}
}
}
}
And here you see the growing memory from the logcat output, which is nearly 1MB
in 10 seconds. Which is very much if there are only 16MB available.
10-26 17:49:57.837: D/dalvikvm(2211): GC_FOR_ALLOC freed 324K, 10% free
3592K/3972K, paused 3ms, total 4ms
10-26 17:50:05.177: D/dalvikvm(2211): GC_FOR_ALLOC freed 398K, 11% free
3701K/4152K, paused 3ms, total 4ms
10-26 17:50:05.777: D/dalvikvm(2211): GC_FOR_ALLOC freed 306K, 9% free
3906K/4264K, paused 4ms, total 4ms
10-26 17:50:06.417: D/dalvikvm(2211): GC_FOR_ALLOC freed 392K, 10% free
4028K/4472K, paused 4ms, total 4ms
10-26 17:50:07.017: D/dalvikvm(2211): GC_FOR_ALLOC freed 314K, 8% free
4226K/4592K, paused 5ms, total 5ms
10-26 17:50:07.617: D/dalvikvm(2211): GC_FOR_ALLOC freed 399K, 10% free
4342K/4792K, paused 5ms, total 5ms
10-26 17:50:08.237: D/dalvikvm(2211): GC_FOR_ALLOC freed 330K, 8% free
4558K/4940K, paused 6ms, total 6ms
I also found, that leaving away this line:
stm.execute("xy");
does no longer create the issue. Also replacing it with a valid select
statement solves the issue. So i can create lots of connections which are
garbage collected without being explicitly closed. But if i execute a single
statement which failes, then neither rollback(), nor close() will free the
memory.
So i still think it is a bug.
And yes, the sample is not an real world app (just demo). I'm trying hard to
avoid exceptions like the one produced here. This bug hit me during development
phase, because of an bug in my real application.
thanks for your quick responses.
martin
Original comment by keinh...@gmail.com
on 26 Oct 2014 at 5:27
Hello,
it's me again :-)
I've searched google for a couple of hours the last 2 days and it seems like i
have found the solution for this strange problem.
The bug is not in my APP, and also is not in h2.
Seems like the bug is in the Android Debugger.
As shown above the memory usage is growing rapidly, but, to my surprise, only
if the Debugger is connected (which i did all the time, because i'm
developing).
If the APP is launched without debugger, everything works. No more memory
leaking.
If the APP is started in debugging mode and the debugger is disconnected after
some time, the leaking stops and the leaked memory will be freed.
If the debugger is connected to an already running APP, memory leaking starts
again until the debugger is disconnected again.
Maybe you could put a note about this behavior on your Tutorial page, so other
guys won't run in the wrong direction like me.
http://h2database.com/html/tutorial.html?highlight=Android&search=android#androi
d
thank you for your patience
martin
Original comment by keinh...@gmail.com
on 29 Oct 2014 at 5:51
Original issue reported on code.google.com by
keinh...@gmail.com
on 25 Oct 2014 at 5:22