Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Looking at the stack trace, it looks like Android's HttpClient.execute() implementation is throwing an OOM. </p> </blockquote> <p>That is not indicated by the stack trace you have on the issue. Of course, you didn't provide the whole stack trace on the issue.</p> <blockquote> <p>What's the best way to get the attention of Android devs about this? Any better options than reporting on <a href="http://code.google.com/p/android/issues">http://code.google.com/p/android/issues</a>?</p> </blockquote> <p>The odds of this being a pure Android bug are small, though not zero.</p> <p>Here are some other possibilities, in no particular order:</p> <ol> <li><p>There is no problem with <code>execute()</code> per se, but that you are simply running out of memory, and the stack traces you have encountered are simply demonstrating that <code>execute()</code> is stressing your heap.</p></li> <li><p>The problem is in some modifications that HTC made to Android for the Thunderbolt, possibly only taking effect when on the LTE network.</p></li> <li><p>The problem is somehow caused by the Verizon LTE network itself (e.g., some proxy of theirs sending back screwball information that is causing HttpClient to have a conniption).</p></li> </ol> <blockquote> <p>Any ideas on how I can work around this?</p> </blockquote> <p>First, I'd use existing tools (e.g., dumping HPROF and examining with Eclipse MAT) to confirm that you don't have a memory leak in general that the Thunderbolt/LTE combo just seems to be tripping over.</p> <p>Next, I recommend that you come up with some way to consistently reproduce the error. That could be your existing app with a series of steps to follow, or it could be a dedicated app (e.g., log the URL that triggers the OOM, then create a tiny app that just does that HttpClient request). I wish DeviceAnywhere had a Thunderbolt, but it doesn't look like it. I'll put some feelers out and see if I can get some help on that front.</p> <p>In terms of working around it, as a stopgap, you can detect that you're running on a Thunderbolt via <code>android.os.Build</code> data, and perhaps that you're on LTE via <code>ConnectivityManager</code> (I'm guessing LTE would list as WiMAX, but that's just a guess), and warn users about the problems with that combo.</p> <p>Beyond that, you can try changing up your HttpClient usage a bit and see if it has an effect, such as: </p> <ul> <li>If you are only supporting API Level 8 or higher, you could give <code>AndroidHttpClient</code> a shot as a drop-in replacement</li> <li>Disable multi-threaded access (in general or Thunderbolt-specific) and get rid of the <code>ThreadSafeClientConnManager</code></li> </ul> <p>I'm sorry that I don't have a "magic bullet" answer for you here.</p> <hr> <p><strong>UPDATE</strong></p> <p>Now that I have the full stack trace, looking through the source code is...illuminating, somewhat.</p> <p>The problem appears to be that:</p> <pre><code>HttpConnectionParams.getSocketBufferSize(params); </code></pre> <p>is returning that 2MB or so value that is triggering the OOM. That's an awfully big buffer, particularly for the Dalvik GC engine, which can get fragmented (yes, there's that word again).</p> <p><code>params</code> here is the <code>HttpParams</code>. You seem to be creating those yourself via <code>getHttpParams()</code>. For example, <code>AndroidHttpClient</code> sets that to 8192:</p> <pre><code>HttpConnectionParams.setSocketBufferSize(params, 8192); </code></pre> <p>If you are setting the socket buffer size yourself, try reducing it. If not, try setting it to 8192 and see if that helps.</p>
    singulars
    1. This table or related slice is empty.
    1. POAndroid HttpClient OOM on 4G/LTE (HTC Thunderbolt)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommonsWare
    1. USCommonsWare
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POAndroid HttpClient OOM on 4G/LTE (HTC Thunderbolt)
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COAh, cut-paste error. The full stack is now there. Thanks. Those are good suggestions - I'll try some of the things you recommended and post an update if I find anything new.
      singulars
      1. PO
      1. USpsychotik
    2. COBtw, I did think of #1 but from what I can tell in the logs that users have sent they are doing nothing special while on LTE that wouldn't happen while on 3G/WiFi. So though there is a change that this is because of a memory condition induced by my application it seems unlikely since only using LTE causes it to occur.
      singulars
      1. PO
      1. USpsychotik
    3. CO@psychotik: I updated the answer based upon further research, itself based upon your amended stack trace.
      singulars
      1. PO
      1. USCommonsWare
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload