ABORTING: DALVIK: HEAP MEMORY CORRUPTION IN dispose_chunk addr=0x0
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 8817 (iidian.imwaiter)
目前遇到的問題是，android系統通過USB連線印表機（印表機機型為YPT，Android系統為4.4.4）時，出現的一個很要命的問題。應用在列印很多單後，導致應用直接崩潰，介面顯示無法繼續執行。
查了很多資料，雖然都未解決問題，記錄下來，待後期參考
HEAP MEMORY CORRUPTION
有人說HEAP MEMORY CORRUPTION 一般是你指標越界或者使用了無效的指標造成堆資料破壞。
Native crash in Android 4.4.3
其中有一個回答
yes, but not related to Picasso. I understand why you ask, since there is something pointing to AsyncTask in the error dump. If I re-run my app, I can also see that each crash is in another thread(Sometimes asynctaks, sometimes regular threads).
But like I said, I can also reproduce the error in the Picasso sample app from the Picasso Github site…
I’m beginning to suspect this is not related to Picasso itself, but with memory allocation or GC in the Android system itself(Since android 4.4.3), but because Images are quite memory intensive, this Android bug is quickly reproducable when using Picasso.
翻譯
是的，但與Picasso無關。我理解您為什麼這樣問，因為在錯誤轉儲中有指向AsyncTask的東西。如果我重新執行我的應用程式，我還可以看到每次崩潰都在另一個執行緒中(有時是asynctaks，有時是常規執行緒)。
但就像我說的，我也可以在PicassoGithub網站上的Picasso樣本應用程式中重現錯誤……
我開始懷疑這與Picasso本身無關，而是與Android系統本身的記憶體分配或GC有關(因為Android 4.4.3)，但由於影象的記憶體非常密集，這個Android bug在使用Picasso時可以快速複製。
according to the guy I have been talking to on the Android forum. The error is located in the inSampleSize calculation. In picasso in the BitmapHunter.java file.
If the “options.inSampleSize = sampleSize” on line 341 is bigger then 3. Then you are in for trouble… If the value is 8 or larger, then it crashes immediately.
翻譯
據我在安卓論壇上聊天的人說。誤差位於取樣計算中。在Picasso的BitmapHunter.java檔案。
如果“選項。第341行比第3行大。那你就有麻煩了…如果值是8或更大，那麼它會立即崩潰。
Weird dalvik crashes since 4.4.3 on Nexus 5
還是上面那個哥們，在android社群問的問題，參考
ABORTING: DALVIK: HEAP MEMORY CORRUPTION IN dispose_chunk addr=0x0