Dear all,

I started porting a large SDL-based application to x86 Android (for the forthcoming Intel Medfield chip), using Intel's Android Emulator for development (Intel Atom x86 System Image, Android 2.3.3. API Level 10).

I downloaded sdl-2.0.0, followed the instructions in README.android, ported my application, and unfortunately got an infinite hang on startup.

By adding countless __android_log_print debug statements, I found that the infinite hang is in function

static int
GLES_UpdateTexture(SDL_Renderer * renderer, SDL_Texture * texture,
                   const SDL_Rect * rect, const void *pixels, int pitch)

where this command never returns:

renderdata->glBindTexture(data->type, data->texture);

Interestingly, this hang does not happen the first time GLES_UpdateTexture is called, but only at a later stage.

Consequently, something must change in between the calls that causes the hang. After 5 hours of debugging, I found the thing that changes. My application allocates and changes 804 bytes of memory. I could further narrow the problem to changing a single 1 DWORD using this code:

char **linetable;
linetable=malloc(201*sizeof(*linetable));
linetable[116]=0xb4251988

So allocating a piece of memory and changing 1 DWORD within causes glBindTexture to hang/crash upon the next call. This can only mean that glBindTexture illegally accesses data at the address of linetable[116].

&linetable[116] is 0x8fa1370, so the next hours were dedicated to finding out who modifies the address 0x8fa1370 first.

The result made sense: Address 0x8fa1370 is first modified in function SDL_GL_CreateContext(SDL_Window * window), specifically by the call

ctx = _this->GL_CreateContext(_this, window);

which stores the value 0x8da4de8 there. This call leads directly to JAVA code in SDLActivity.java, which initializes the OpenGL context. At this point, I gave up.

My humble hypothesis is the following:

*) The JAVA code in SDLActivity.java allocates some memory while setting up the OpenGL Context, and this memory is unintentionally freed by the garbage collector or whoever when the function returns, since JAVA doesn't realize it's still needed.

*) My application legally allocates the now free memory and modifies it.

*) At the next call to glBindTexture, the memory is accessed again, and the changed content causes the crash/hang.

I don't have enough JAVA knowledge to proceed further, and I've no idea how I could provide anyone with source code that reproduces the problem (the application is just too large). I could supply the emulator image including the application, but I'm not sure if this is enough.

So my hope was that the details I described above ring a bell at someone involved in SDL for Android, who can pinpoint the problem by just browsing a few minutes through the SDL source...

Best regards and many thanks for your help,
Elmar

P.S.: feel free to email me privately: elmar at cmbi dot ru dot nl