I have an application running on Android 2.2.2 and it’s running out of memory when trying to read a somewhat large (~500kb) XML file.
The XML file is located at /res/xml, and it’s read like this (in a simplified manner):
XmlResourceParser xmlParser = getResources().getXml(R.xml.myxml);
This runs perfectly on most devices (although it does take a few seconds to complete). I’m testing against a low-end device (a Huawei M835), however, and it appears to run out of memory when trying to load that.. it never finishes that call.
The error I get is not very helpful – it’s just a big dump with no proper stack trace or anything. Here’s my full logcat response once I execute the above line:
DEBUG(1700): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
DEBUG(1700): Build fingerprint: 'Huawei/M835/hwm835/M835:2.2.2/HuaweiM835/C177B622:user/release-keys'
DEBUG(1700): pid: 2798, tid: 2798 >>> com.mypackage.MyApplication <<<
DEBUG(1700): signal 11 (SIGSEGV), fault addr 00000000
DEBUG(1700): r0 46a95008 r1 00000000 r2 0011ce24 r3 00000018
DEBUG(1700): r4 0013e8f0 r5 00000000 r6 a8125a48 r7 0011ce24
DEBUG(1700): r8 beebc460 r9 4166ebc0 10 416ae1c0 fp 4166ebbc
DEBUG(1700): ip 80000000 sp beebc3e8 lr a8119b8b pc afd0f110 cpsr a0000010
DEBUG(1700): #00 pc 0000f110 /system/lib/libc.so
DEBUG(1700): #01 pc 00019b88 /system/lib/libutils.so
DEBUG(1700): #02 pc 000459e6 /system/lib/libandroid_runtime.so
DEBUG(1700): #03 pc 00011cb4 /system/lib/libdvm.so
DEBUG(1700): #04 pc 0003c3d8 /system/lib/libdvm.so
DEBUG(1700): #05 pc 00023cb4 /system/lib/libdvm.so
DEBUG(1700): #06 pc 0001c244 /system/lib/libdvm.so
DEBUG(1700): #07 pc 0005155a /system/lib/libdvm.so
DEBUG(1700): #08 pc 00058faa /system/lib/libdvm.so
DEBUG(1700): #09 pc 00016c78 /system/lib/libdvm.so
DEBUG(1700): #10 pc 0001d35c /system/lib/libdvm.so
DEBUG(1700): #11 pc 0001c1f4 /system/lib/libdvm.so
DEBUG(1700): #12 pc 000513c8 /system/lib/libdvm.so
DEBUG(1700): #13 pc 0003ec58 /system/lib/libdvm.so
DEBUG(1700): #14 pc 0002e908 /system/lib/libandroid_runtime.so
DEBUG(1700): #15 pc 0002f7be /system/lib/libandroid_runtime.so
DEBUG(1700): #16 pc 00008c86 /system/bin/app_process
DEBUG(1700): #17 pc 0000d362 /system/lib/libc.so
DEBUG(1700): code around pc:
DEBUG(1700): afd0f0f0 1a00002b e88d0fe0 e2603000 e213301c
DEBUG(1700): afd0f100 0a00000a e1530002 8202301c e1b0ce03
DEBUG(1700): afd0f110 28b100f0 48b10300 28a000f0 48a00300
DEBUG(1700): afd0f120 e3130004 1491a004 1480a004 e0422003
DEBUG(1700): afd0f130 e2522020 3a000008 e3c1c01f e28cc040
DEBUG(1700): code around lr:
DEBUG(1700): a8119b68 2a006063 1c38d00e ee7cf7f5 28006160
DEBUG(1700): a8119b78 200cd103 61204240 1c29e086 f7f51c3a
DEBUG(1700): a8119b88 6965ee60 686a61a5 886b61e2 d8014293
DEBUG(1700): a8119b98 d90a42ba 4a3f493e 18712005 686e18b2
DEBUG(1700): a8119ba8 96009701 ee70f7f5 1c27e063 372418ab
DEBUG(1700): stack:
DEBUG(1700): beebc3a8 00000000
DEBUG(1700): beebc3ac beebc3f8 [stack]
DEBUG(1700): beebc3b0 00000000
DEBUG(1700): beebc3b4 afd103f0 /system/lib/libc.so
DEBUG(1700): beebc3b8 00000003
DEBUG(1700): beebc3bc afd41724 /system/lib/libc.so
DEBUG(1700): beebc3c0 46a95008
DEBUG(1700): beebc3c4 c0000000
DEBUG(1700): beebc3c8 beebc460 [stack]
DEBUG(1700): beebc3cc 4166ebc0
DEBUG(1700): beebc3d0 416ae1c0 /dev/ashmem/dalvik-LinearAlloc (deleted)
DEBUG(1700): beebc3d4 afd0c741 /system/lib/libc.so
DEBUG(1700): beebc3d8 00000000
DEBUG(1700): beebc3dc afd103f0 /system/lib/libc.so
DEBUG(1700): beebc3e0 df002777
DEBUG(1700): beebc3e4 e3a070ad
DEBUG(1700): #00 beebc3e8 00000000
DEBUG(1700): beebc3ec a8125a48 /system/lib/libutils.so
DEBUG(1700): beebc3f0 0011ce24 [heap]
DEBUG(1700): beebc3f4 beebc460 [stack]
DEBUG(1700): beebc3f8 4166ebc0
DEBUG(1700): beebc3fc 416ae1c0 /dev/ashmem/dalvik-LinearAlloc (deleted)
DEBUG(1700): beebc400 4166ebbc
DEBUG(1700): beebc404 46a95008
DEBUG(1700): beebc408 0013e8f0 [heap]
DEBUG(1700): beebc40c a8119b8b /system/lib/libutils.so
DEBUG(1700): #01 beebc410 000a8b90 [heap]
DEBUG(1700): beebc414 1fe0106c
DEBUG(1700): beebc418 00000001
DEBUG(1700): beebc41c 0013e248 [heap]
DEBUG(1700): beebc420 ad3780f8 /system/lib/libandroid_runtime.so
DEBUG(1700): beebc424 0000aaa0 [heap]
DEBUG(1700): beebc428 0013e8f0 [heap]
DEBUG(1700): beebc42c 0013e248 [heap]
DEBUG(1700): beebc430 ad3780f8 /system/lib/libandroid_runtime.so
DEBUG(1700): beebc434 0000aaa0 [heap]
DEBUG(1700): beebc438 0013e8f0 [heap]
DEBUG(1700): beebc43c ad3459e9 /system/lib/libandroid_runtime.so
ActivityManager(124): Process com.mypackage.MyApplication (pid 2798) has died.
The problem seems to happen because this device only has a 22mb (?) heap size allocated. When reading Runtime.getRuntime().maxMemory(), .totalMemory(), and freeMemory(), I get 22mb, 2mb, and 0.5mb (respectively). Because apparently there’s only 0.5mb “free”, it can’t parse the ~0.5mb XML file.
(When testing that on my other test device, I get 32mb, 5mb, and 2mb.)
My question is: is there any way to load this XML without crashing the application like that?
Incidentally I have some memory-intensive bitmaps manipulation on the application, but that doesn’t throw any error… it still manages to run under the 24mb limit. I’m having a hard time understanding why a simple XML parsing would give me so much trouble.
This is an unmodified ROM, stock commercial installation of that model.
I can properly parse other XML files, or even this XML file, as long as they’re smaller. I had success with a 190kb version of this file, for example.
I’ve read that the SIGSEGV errors may indicate a firmware issue. Still, it seems clear the problem is happening because it has no memory to parse the large XML I’d like to think of ways to circumvent this error altogether.
The XML files that you want to use with
getXML()are pre-parsed (thus loading it entirely into memory), so in your case I would suggest moving the XML to therawfolder, and reading it with SAXParser, which parses the xml as it reads it (keeping in memory only as much as you need for the current node).Your Bitmap processing that you do is done natively, instead of in Java code, which allows for better memory management, and that’s why you’re not having problems with those.