Software Archive
Read-only legacy content
17061 Discussions

Massive memory corruption in the Android 4.0.3 x86 virtual device image with hardware OpenGL

Elmar
Beginner
393 Views
Hi, my company is porting a large C application to Android x86 to run on Intel's Medfield Atoms. Unfortunately, it seems that the Linux version of the Android Emulator using Intel's Android 4.0.3 image reproducibly overwrites application memory as soon as OpenGL hardware acceleration is enabled, so I get segmentations faults etc. all over the place. This has been reproduced on two different computers, one with nVIDIA drivers, one with ATI/AMD Radeon drivers, both running CentOS 5.4 64bit. A typical, simplified example looks like that: (dbg_print is a wrapper for __android_log_print) // Allocate memory int k; int leny=512; int32 *linetable=malloc(leny*sizeof(*linetable)); dbg_print("!!!!Allocated linetable %p, size %d\\n",linetable,leny*sizeof(*linetable)); // Fill memory for (i=0;i=0xac567008+i*320; // Print first ten elements in linetable dbg_print("Looking at pointer %p. Current data at this address:\\n",linetable); for (k=0;k<10;k++) dbg_print("%p: %p",&linetable,linetable); // Now wait for 5 seconds (if this wait is removed, all is OK) dbg_print("Waiting for 5 seconds...\\n"); SDL_Delay(5000); // Print first ten elements in linetable again (these changed now) for (k=0;k<10;k++) dbg_print("%p: %p",&linetable,linetable); // Free pointer (gives segmentation fault in 'free', since not only the pointer data, // but presumably also memory allocation info have been overwritten: dbg_print("Now calling free with pointer %p:\\n",linetable); free(linetable); dbg_print("Freed\\n"); The 'adb logcat' output then looks like that: I/yasra ( 1851): !!!!Allocated linetable 0x82bb228, size 2084 I/yasra ( 1851): Looking at pointer 0x82bb228. Current data at this address: I/yasra ( 1851): 0x82bb228: 0xac567008 I/yasra ( 1851): 0x82bb22c: 0xac567148 I/yasra ( 1851): 0x82bb230: 0xac567288 I/yasra ( 1851): 0x82bb234: 0xac5673c8 I/yasra ( 1851): 0x82bb238: 0xac567508 I/yasra ( 1851): 0x82bb23c: 0xac567648 I/yasra ( 1851): 0x82bb240: 0xac567788 I/yasra ( 1851): 0x82bb244: 0xac5678c8 I/yasra ( 1851): 0x82bb248: 0xac567a08 I/yasra ( 1851): 0x82bb24c: 0xac567b48 I/yasra ( 1851): Waiting for 5 seconds... I/yasra ( 1851): 0x82bb228: 0xff888888 I/yasra ( 1851): 0x82bb22c: 0xff888888 I/yasra ( 1851): 0x82bb230: 0xff888888 I/yasra ( 1851): 0x82bb234: 0xff888888 I/yasra ( 1851): 0x82bb238: 0xff888888 I/yasra ( 1851): 0x82bb23c: 0xff888888 I/yasra ( 1851): 0x82bb240: 0xff888888 I/yasra ( 1851): 0x82bb244: 0xff888888 I/yasra ( 1851): 0x82bb248: 0xff888888 I/yasra ( 1851): 0x82bb24c: 0xff888888 I/yasra ( 1851): Now calling free with pointer 0x82bb228: F/libc ( 1851): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) I/DEBUG ( 787): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 787): Build fingerprint: 'generic_x86/sdk_x86/generic_x86:4.0.4/IMM76D/eng.juntian.20120418.185032:eng/test-keys' I/DEBUG ( 787): pid: 1851, tid: 1865 >>> org.libsdl.app <<< I/DEBUG ( 787): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad I/DEBUG ( 787): eax 00000000 ebx acc08b9c ecx 00000004 edx 00000000 I/DEBUG ( 787): esi ac48e000 edi ac68c3a0 I/DEBUG ( 787): xcs 00000073 xds 0000007b xes 0000007b xfs 00000000 xss 0000007b I/DEBUG ( 787): eip acb15b13 ebp ac68c3bc esp ac68c374 flags 00000282 I/DEBUG ( 787): #00 eip: acb15b13 /data/data/org.libsdl.app/files/yasra.so (abort) I/DEBUG ( 787): #01 eip: acb4cef2 /data/data/org.libsdl.app/files/yasra.so (dlfree) I/DEBUG ( 787): #02 eip: acb44423 /data/data/org.libsdl.app/files/yasra.so (free) I/DEBUG ( 787): #03 eip: ac9bcf48 /data/data/org.libsdl.app/files/yasra.so (ysu_exit) I/DEBUG ( 787): #04 eip: ffffffff (ysu_exit) I/DEBUG ( 787): #05 eip: ffffffff (ysu_exit) I/DEBUG ( 787): #06 eip: ffffffff (ysu_exit) I/DEBUG ( 787): #07 eip: ffffffff (ysu_exit) I/DEBUG ( 787): stack: I/DEBUG ( 787): #00 ac68c374 00000002 (ysu_exit) I/DEBUG ( 787): #00 ac68c378 ac68c3a0 (ysu_exit) I/DEBUG ( 787): #00 ac68c37c 00000000 (ysu_exit) I/DEBUG ( 787): #00 ac68c380 acb434e1 /data/data/org.libsdl.app/files/yasra.so (pthread_mutex_lock) I/DEBUG ( 787): #00 ac68c384 acc08b9c /data/data/org.libsdl.app/files/yasra.so (pthread_mutex_lock) I/DEBUG ( 787): #00 ac68c388 00000820 (pthread_mutex_lock) I/DEBUG ( 787): #00 ac68c38c 00000824 (pthread_mutex_lock) I/DEBUG ( 787): #00 ac68c390 acc08b9c /data/data/org.libsdl.app/files/yasra.so (pthread_mutex_lock) I/DEBUG ( 787): #00 ac68c394 082bc278 [heap] (pthread_mutex_lock) I/DEBUG ( 787): #00 ac68c398 acb6c2dc /data/data/org.libsdl.app/files/yasra.so I/DEBUG ( 787): #00 ac68c39c ac68c3bc I/DEBUG ( 787): #00 ac68c3a0 fffffbdf I/DEBUG ( 787): #00 ac68c3a4 082bc278 [heap] I/DEBUG ( 787): #00 ac68c3a8 acb88d9e /data/data/org.libsdl.app/files/yasra.so I/DEBUG ( 787): #00 ac68c3ac acb15a9b /data/data/org.libsdl.app/files/yasra.so (abort) I/DEBUG ( 787): #00 ac68c3b0 acc08b9c /data/data/org.libsdl.app/files/yasra.so (abort) I/DEBUG ( 787): ...... ...... I/DEBUG ( 787): #01 ac68c3c0 acb4cef2 /data/data/org.libsdl.app/files/yasra.so (dlfree) I/DEBUG ( 787): #01 ac68c3c4 acd05078 (dlfree) I/DEBUG ( 787): #01 ac68c3c8 0000002a (dlfree) I/DEBUG ( 787): #01 ac68c3cc acb6c2dc /data/data/org.libsdl.app/files/yasra.so I/DEBUG ( 787): #01 ac68c3d0 ac68c428 I/DEBUG ( 787): #01 ac68c3d4 00000820 I/DEBUG ( 787): #01 ac68c3d8 00000029 I/DEBUG ( 787): #01 ac68c3dc 082bb000 [heap] I/DEBUG ( 787): #01 ac68c3e0 082bb220 [heap] I/DEBUG ( 787): #01 ac68c3e4 b7f01e49 /system/lib/libc.so (__errno) I/DEBUG ( 787): #01 ac68c3e8 00000000 (__errno) I/DEBUG ( 787): #01 ac68c3ec ac872c19 /data/data/org.libsdl.app/files/yasra.so (dbg_write) I/DEBUG ( 787): #01 ac68c3f0 acc08b9c /data/data/org.libsdl.app/files/yasra.so (dbg_write) I/DEBUG ( 787): #01 ac68c3f4 acd057c0 (dbg_write) I/DEBUG ( 787): #01 ac68c3f8 acb6a825 /data/data/org.libsdl.app/files/yasra.so I/DEBUG ( 787): #01 ac68c3fc ac68c41c I/DEBUG ( 787): ...... ...... I/DEBUG ( 787): #02 ac68c400 acb44423 /data/data/org.libsdl.app/files/yasra.so (free) I/DEBUG ( 787): #02 ac68c404 082bb228 [heap] (free) I/DEBUG ( 787): #02 ac68c408 ac68c428 (free) I/DEBUG ( 787): #02 ac68c40c 00000005 (free) I/DEBUG ( 787): #02 ac68c410 00000000 (free) I/DEBUG ( 787): #02 ac68c414 acb44409 /data/data/org.libsdl.app/files/yasra.so (free) I/DEBUG ( 787): #02 ac68c418 acc08b9c /data/data/org.libsdl.app/files/yasra.so (free) I/DEBUG ( 787): #02 ac68c41c 00000028 (free) I/DEBUG ( 787): #03 ac68c420 ac9bcf48 /data/data/org.libsdl.app/files/yasra.so (ysu_exit) I/DEBUG ( 787): #03 ac68c424 082bb228 [heap] (ysu_exit) I/DEBUG ( 787): #03 ac68c428 082bb228 [heap] (ysu_exit) I/DEBUG ( 787): #03 ac68c42c ff888888 (ysu_exit) I/DEBUG ( 787): #03 ac68c430 ac567008 (ysu_exit) I/DEBUG ( 787): #03 ac68c434 00000140 (ysu_exit) I/DEBUG ( 787): #03 ac68c438 00000208 (ysu_exit) I/DEBUG ( 787): #03 ac68c43c 00000140 (ysu_exit) I/DEBUG ( 787): #03 ac68c440 10810000 (ysu_exit) I/DEBUG ( 787): #03 ac68c444 082bba50 [heap] (ysu_exit) I/DEBUG ( 787): #03 ac68c448 00000000 (ysu_exit) I/DEBUG ( 787): #03 ac68c44c 00000000 (ysu_exit) I/DEBUG ( 787): #03 ac68c450 00000000 (ysu_exit) I/DEBUG ( 787): #03 ac68c454 00000000 (ysu_exit) I/DEBUG ( 787): #03 ac68c458 00000000 (ysu_exit) I/DEBUG ( 787): #03 ac68c45c 082bb0a0 [heap] (ysu_exit) I/DEBUG ( 787): ...... ...... So you can see that 'someone' (hate him!) overwrites my allocated memory with 0xff888888 if I wait 5 seconds. I looked at the memory regions before and after, and the values before got smaller (0xff868686,0xff848484) and the values at higher addresses got larger (0xff8a8a8a..). This reminded me of RGBA values, where the 'ff' is the constant alpha value, and the rest is a grey color gradient. I therefore guessed that this is actually texture data, and indeed, if I turned off OpenGL hardware acceleration, the problem disappeared. The memory corruption is so massive that I cannot even get a 'Hello World' to run, so I'm wondering if anyone else got any program running in this wild emulator with hardware acceleration enabled? Please tell me if Intel is the right spot to handle this report, or if it should be reported to Google instead. To reproduce the problem, I can provide you with the emulator image, please contact me privately if you want it (elmar _at_ cmbi.ru.nl). Best regards and many thanks for your help, Elmar
0 Kudos
2 Replies
Elmar
Beginner
392 Views
Ahm, why did the "Preview" button display my message correctly, with all line feed present, while the final message is now unreadable? How do I post a readable message??

E.
0 Kudos
Elmar
Beginner
392 Views
OK, here is the second and final try to get the linefeeds in. In case it fails again, I also attached a text file with this message. Ah no, just noted that the "Add Files" button also doesn't work (Firefox 10.0.6).

Hi,

my company is porting a large C application to Android x86 to run on Intel's Medfield Atoms. Unfortunately, it seems that the Linux version of the Android Emulator using Intel's Android 4.0.3 image reproducibly overwrites application memory as soon as OpenGL hardware acceleration is enabled, so I get segmentations faults etc. all over the place.

This has been reproduced on two different computers, one with nVIDIA drivers, one with ATI/AMD Radeon drivers, both running CentOS 5.4 64bit.

A typical, simplified example looks like that:
(dbg_print is a wrapper for __android_log_print)

// Allocate memory
int k;
int leny=512;
int32 *linetable=malloc(leny*sizeof(*linetable));
dbg_print("!!!!Allocated linetable %p, size %d\n",linetable,leny*sizeof(*linetable));

// Fill memory
for (i=0;i=0xac567008+i*320;

// Print first ten elements in linetable
dbg_print("Looking at pointer %p. Current data at this address:\n",linetable);
for (k=0;k<10;k++) dbg_print("%p: %p",&linetable,linetable);

// Now wait for 5 seconds (if this wait is removed, all is OK)
dbg_print("Waiting for 5 seconds...\n");
SDL_Delay(5000);

// Print first ten elements in linetable again (these changed now)
for (k=0;k<10;k++) dbg_print("%p: %p",&linetable,linetable);

// Free pointer (gives segmentation fault in 'free', since not only the pointer data,
// but presumably also memory allocation info have been overwritten:
dbg_print("Now calling free with pointer %p:\n",linetable);
free(linetable);
dbg_print("Freed\n");

The 'adb logcat' output then looks like that:

I/yasra ( 1851): !!!!Allocated linetable 0x82bb228, size 2084
I/yasra ( 1851): Looking at pointer 0x82bb228. Current data at this address:
I/yasra ( 1851): 0x82bb228: 0xac567008
I/yasra ( 1851): 0x82bb22c: 0xac567148
I/yasra ( 1851): 0x82bb230: 0xac567288
I/yasra ( 1851): 0x82bb234: 0xac5673c8
I/yasra ( 1851): 0x82bb238: 0xac567508
I/yasra ( 1851): 0x82bb23c: 0xac567648
I/yasra ( 1851): 0x82bb240: 0xac567788
I/yasra ( 1851): 0x82bb244: 0xac5678c8
I/yasra ( 1851): 0x82bb248: 0xac567a08
I/yasra ( 1851): 0x82bb24c: 0xac567b48
I/yasra ( 1851): Waiting for 5 seconds...
I/yasra ( 1851): 0x82bb228: 0xff888888
I/yasra ( 1851): 0x82bb22c: 0xff888888
I/yasra ( 1851): 0x82bb230: 0xff888888
I/yasra ( 1851): 0x82bb234: 0xff888888
I/yasra ( 1851): 0x82bb238: 0xff888888
I/yasra ( 1851): 0x82bb23c: 0xff888888
I/yasra ( 1851): 0x82bb240: 0xff888888
I/yasra ( 1851): 0x82bb244: 0xff888888
I/yasra ( 1851): 0x82bb248: 0xff888888
I/yasra ( 1851): 0x82bb24c: 0xff888888
I/yasra ( 1851): Now calling free with pointer 0x82bb228:
F/libc ( 1851): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
I/DEBUG ( 787): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 787): Build fingerprint: 'generic_x86/sdk_x86/generic_x86:4.0.4/IMM76D/eng.juntian.20120418.185032:eng/test-keys'
I/DEBUG ( 787): pid: 1851, tid: 1865 >>> org.libsdl.app <<<
I/DEBUG ( 787): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG ( 787): eax 00000000 ebx acc08b9c ecx 00000004 edx 00000000
I/DEBUG ( 787): esi ac48e000 edi ac68c3a0
I/DEBUG ( 787): xcs 00000073 xds 0000007b xes 0000007b xfs 00000000 xss 0000007b
I/DEBUG ( 787): eip acb15b13 ebp ac68c3bc esp ac68c374 flags 00000282
I/DEBUG ( 787): #00 eip: acb15b13 /data/data/org.libsdl.app/files/yasra.so (abort)
I/DEBUG ( 787): #01 eip: acb4cef2 /data/data/org.libsdl.app/files/yasra.so (dlfree)
I/DEBUG ( 787): #02 eip: acb44423 /data/data/org.libsdl.app/files/yasra.so (free)
I/DEBUG ( 787): #03 eip: ac9bcf48 /data/data/org.libsdl.app/files/yasra.so (ysu_exit)
I/DEBUG ( 787): #04 eip: ffffffff (ysu_exit)
I/DEBUG ( 787): #05 eip: ffffffff (ysu_exit)
I/DEBUG ( 787): #06 eip: ffffffff (ysu_exit)
I/DEBUG ( 787): #07 eip: ffffffff (ysu_exit)
I/DEBUG ( 787): stack:
I/DEBUG ( 787): #00 ac68c374 00000002 (ysu_exit)
I/DEBUG ( 787): #00 ac68c378 ac68c3a0 (ysu_exit)
I/DEBUG ( 787): #00 ac68c37c 00000000 (ysu_exit)
I/DEBUG ( 787): #00 ac68c380 acb434e1 /data/data/org.libsdl.app/files/yasra.so (pthread_mutex_lock)
I/DEBUG ( 787): #00 ac68c384 acc08b9c /data/data/org.libsdl.app/files/yasra.so (pthread_mutex_lock)
I/DEBUG ( 787): #00 ac68c388 00000820 (pthread_mutex_lock)
I/DEBUG ( 787): #00 ac68c38c 00000824 (pthread_mutex_lock)
I/DEBUG ( 787): #00 ac68c390 acc08b9c /data/data/org.libsdl.app/files/yasra.so (pthread_mutex_lock)
I/DEBUG ( 787): #00 ac68c394 082bc278 [heap] (pthread_mutex_lock)
I/DEBUG ( 787): #00 ac68c398 acb6c2dc /data/data/org.libsdl.app/files/yasra.so
I/DEBUG ( 787): #00 ac68c39c ac68c3bc
I/DEBUG ( 787): #00 ac68c3a0 fffffbdf
I/DEBUG ( 787): #00 ac68c3a4 082bc278 [heap]
I/DEBUG ( 787): #00 ac68c3a8 acb88d9e /data/data/org.libsdl.app/files/yasra.so
I/DEBUG ( 787): #00 ac68c3ac acb15a9b /data/data/org.libsdl.app/files/yasra.so (abort)
I/DEBUG ( 787): #00 ac68c3b0 acc08b9c /data/data/org.libsdl.app/files/yasra.so (abort)
I/DEBUG ( 787): ...... ......
I/DEBUG ( 787): #01 ac68c3c0 acb4cef2 /data/data/org.libsdl.app/files/yasra.so (dlfree)
I/DEBUG ( 787): #01 ac68c3c4 acd05078 (dlfree)
I/DEBUG ( 787): #01 ac68c3c8 0000002a (dlfree)
I/DEBUG ( 787): #01 ac68c3cc acb6c2dc /data/data/org.libsdl.app/files/yasra.so
I/DEBUG ( 787): #01 ac68c3d0 ac68c428
I/DEBUG ( 787): #01 ac68c3d4 00000820
I/DEBUG ( 787): #01 ac68c3d8 00000029
I/DEBUG ( 787): #01 ac68c3dc 082bb000 [heap]
I/DEBUG ( 787): #01 ac68c3e0 082bb220 [heap]
I/DEBUG ( 787): #01 ac68c3e4 b7f01e49 /system/lib/libc.so (__errno)
I/DEBUG ( 787): #01 ac68c3e8 00000000 (__errno)
I/DEBUG ( 787): #01 ac68c3ec ac872c19 /data/data/org.libsdl.app/files/yasra.so (dbg_write)
I/DEBUG ( 787): #01 ac68c3f0 acc08b9c /data/data/org.libsdl.app/files/yasra.so (dbg_write)
I/DEBUG ( 787): #01 ac68c3f4 acd057c0 (dbg_write)
I/DEBUG ( 787): #01 ac68c3f8 acb6a825 /data/data/org.libsdl.app/files/yasra.so
I/DEBUG ( 787): #01 ac68c3fc ac68c41c
I/DEBUG ( 787): ...... ......
I/DEBUG ( 787): #02 ac68c400 acb44423 /data/data/org.libsdl.app/files/yasra.so (free)
I/DEBUG ( 787): #02 ac68c404 082bb228 [heap] (free)
I/DEBUG ( 787): #02 ac68c408 ac68c428 (free)
I/DEBUG ( 787): #02 ac68c40c 00000005 (free)
I/DEBUG ( 787): #02 ac68c410 00000000 (free)
I/DEBUG ( 787): #02 ac68c414 acb44409 /data/data/org.libsdl.app/files/yasra.so (free)
I/DEBUG ( 787): #02 ac68c418 acc08b9c /data/data/org.libsdl.app/files/yasra.so (free)
I/DEBUG ( 787): #02 ac68c41c 00000028 (free)
I/DEBUG ( 787): #03 ac68c420 ac9bcf48 /data/data/org.libsdl.app/files/yasra.so (ysu_exit)
I/DEBUG ( 787): #03 ac68c424 082bb228 [heap] (ysu_exit)
I/DEBUG ( 787): #03 ac68c428 082bb228 [heap] (ysu_exit)
I/DEBUG ( 787): #03 ac68c42c ff888888 (ysu_exit)
I/DEBUG ( 787): #03 ac68c430 ac567008 (ysu_exit)
I/DEBUG ( 787): #03 ac68c434 00000140 (ysu_exit)
I/DEBUG ( 787): #03 ac68c438 00000208 (ysu_exit)
I/DEBUG ( 787): #03 ac68c43c 00000140 (ysu_exit)
I/DEBUG ( 787): #03 ac68c440 10810000 (ysu_exit)
I/DEBUG ( 787): #03 ac68c444 082bba50 [heap] (ysu_exit)
I/DEBUG ( 787): #03 ac68c448 00000000 (ysu_exit)
I/DEBUG ( 787): #03 ac68c44c 00000000 (ysu_exit)
I/DEBUG ( 787): #03 ac68c450 00000000 (ysu_exit)
I/DEBUG ( 787): #03 ac68c454 00000000 (ysu_exit)
I/DEBUG ( 787): #03 ac68c458 00000000 (ysu_exit)
I/DEBUG ( 787): #03 ac68c45c 082bb0a0 [heap] (ysu_exit)
I/DEBUG ( 787): ...... ......


So you can see that 'someone' (hate him!) overwrites my allocated memory with 0xff888888 if I wait 5 seconds.
I looked at the memory regions before and after, and the values before got smaller (0xff868686,0xff848484) and the values at higher addresses got larger (0xff8a8a8a..). This reminded me of RGBA values, where the 'ff' is the constant alpha value, and the rest is a grey color gradient. I therefore guessed that this is actually texture data, and indeed, if I turned off OpenGL hardware acceleration, the problem disappeared.

The memory corruption is so massive that I cannot even get a 'Hello World' to run, so I'm wondering if anyone else got any program running in this wild emulator with hardware acceleration enabled?

Please tell me if Intel is the right spot to handle this report, or if it should be reported to Google instead.

To reproduce the problem, I can provide you with the emulator image, please contact me privately if you want it (elmar _at_ cmbi.ru.nl).

Best regards and many thanks for your help,
Elmar

0 Kudos
Reply