Coincidentally, all those who have personally emailed me have the HTC
Thunderbolt.

I've run allocationtracker and stuff, but it has been of limited use
when I can't reproduce the problem.

Yes, I know that a place where you get the OutofMemory isn't
necessarily the cause of the problem. I am looking at everything,
including bitmap allocations. But customer feedback suggests that this
might happen before those other allocations happen, meaning there
could be memory lost in some of these http retrievals.

Here's something I can't explain. I've added a catch(OutOfMemoryError
err) around this spot in my latest version. How am I still getting
errors with the same stack trace? I would think it would start failing
somewhere else.

And has anyone seen anything weird with the HTC Thunderbolt?

Nathan

java.lang.OutOfMemoryError: (Heap Size=16327KB, Allocated=14167KB,
Bitmap Size=7690KB)
at org.apache.http.util.ByteArrayBuffer.<init>(ByteArrayBuffer.java:
53)
at
org.apache.http.impl.io.AbstractSessionInputBuffer.init(AbstractSessionInpu tBuffer.java:
82)
at
org.apache.http.impl.io.SocketInputBuffer.<init>(SocketInputBuffer.java:
93)
at
org.apache.http.impl.SocketHttpClientConnection.createSessionInputBuffer(So cketHttpClientConnection.java:
83)
at
org.apache.http.impl.conn.DefaultClientConnection.createSessionInputBuffer( DefaultClientConnection.java:
170)
at
org.apache.http.impl.SocketHttpClientConnection.bind(SocketHttpClientConnec tion.java:
106)
at
org.apache.http.impl.conn.DefaultClientConnection.openCompleted(DefaultClie ntConnection.java:
129)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(De faultClientConnectionOperator.java:
173)
at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:
164)
at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConn Adapter.java:
119)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDi rector.java:
348)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.j ava:
555)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.j ava:
487)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.j ava:
465)

HTC, for unknown reasons, messed up the buffer size. If you set it
yourself, the problem goes away.

Android Training in London: http://bit.ly/smand1, http://bit.ly/smand2

On Mar 29, 1:41 pm, Mark Murphy <mmur...@commonsware.com> wrote:

Until I got a recent log, I didn't know how much it was trying to
allocate - 2Megabytes. That seems awfully greedy when you have a 16M
heap - multiple downloads in a row without triggering garbage
collection are sure to bring you down. I'm happy to allocate less
since I'm only downloading 69K files.

Like those in Stack Overflow said, I hope HTC enjoys all the returns.

I guess once in a while, the stack trace from OutOfMemoryError
actually does tell you where the problem is.

Nathan

The problem isn't only the size, but the fact that Android employs a
GC engine that tends to fragment, so while there might be gobs of heap
space, there might not be a 2MB block free. Anything looking to
regularly use large blocks like that should maintain their own pool,
which HttpClient doesn't do (expecting more like the 8K (IIRC)
default).

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

Android Training in London: http://bit.ly/smand1, http://bit.ly/smand2

Nathan

There are some connections I don't control, such as the dispatch on
Google Analytics.

Nathan

On Mar 29, 2:36 pm, Nathan <critter...@crittermap.com> wrote:

Short of Analytics fixing this in their code, I think you're screwed.
Can you disable your use of Analytics if you're on a Thunderbolt?

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!