While working with SDL for android I started getting semi random segfaults. When I debugged I couldn’t get a stack trace(It would just give two lines of addresses and question marks with a warning about a possible corrrupted stack).
Manually commenting out lines till I found one that would let it keep running led me to find that the line that caused the crash was
JNIEnv *aEnv = (JNIEnv *)SDL_AndroidGetJNIEnv();
Any ideas on why this might occur, my idea was that maybe I’m not initiating something when I call SDL_Init so I tried with SDL_Init(SDL_INIT_EVERYTHING) with no change. Anything else I might try to figure out this bug?
maybe it is related to some jni stuff you are doing. it would help if you
post the code that you commented.
also check the readme, there is a section about valgrind on android.Am 01.10.2014 00:39 schrieb “ruler501” <d.ruler501 at gmail.com>:
While working with SDL for android I started getting semi random
segfaults. When I debugged I couldn’t get a stack trace(It would just give
two lines of addresses and question marks with a warning about a possible
corrrupted stack).
Manually commenting out lines till I found one that would let it keep
running led me to find that the line that caused the crash was
JNIEnv *aEnv = (JNIEnv *)SDL_AndroidGetJNIEnv();
Any ideas on why this might occur, my idea was that maybe I’m not
initiating something when I call SDL_Init so I tried with
SDL_Init(SDL_INIT_EVERYTHING) with no change. Anything else I might try to
figure out this bug?
The only line I commented was the line with SDL_AndroidGetJNIEnv(), that does cause crashes later on, but it did allow execution to get farther(at least as far as I could tell by stepping through.
M. Gerhardy wrote:> maybe it is related to some jni stuff you are doing. it would help if you post the code that you commented.
also check the readme, there is a section about valgrind on android. Am 01.10.2014 00:39 schrieb “ruler501” <@Ruler_501 (@Ruler_501)>:
While working with SDL for android I started getting semi random segfaults. When I debugged I couldn't get a stack trace(It would just give two lines of addresses and question marks with a warning about a possible corrrupted stack).
Manually commenting out lines till I found one that would let it keep running led me to find that the line that caused the crash was
JNIEnv *aEnv = (JNIEnv *)SDL_AndroidGetJNIEnv();
Any ideas on why this might occur, my idea was that maybe I’m not initiating something when I call SDL_Init so I tried with SDL_Init(SDL_INIT_EVERYTHING) with no change. Anything else I might try to figure out this bug?
You can’t do much of anything in JNI without the environment variable.
Commenting that out wouldn’t narrow anything down.
Jonny DOn Wed, Oct 1, 2014 at 10:30 AM, ruler501 <d.ruler501 at gmail.com> wrote:
The only line I commented was the line with SDL_AndroidGetJNIEnv(), that
does cause crashes later on, but it did allow execution to get farther(at
least as far as I could tell by stepping through.
M. Gerhardy wrote:
maybe it is related to some jni stuff you are doing. it would help if
you post the code that you commented.
also check the readme, there is a section about valgrind on android. Am
01.10.2014 00:39 schrieb “ruler501” <>:
Quote:
While working with SDL for android I started getting semi random
segfaults. When I debugged I couldn’t get a stack trace(It would just give
two lines of addresses and question marks with a warning about a possible
corrrupted stack).
Manually commenting out lines till I found one that would let it keep
running led me to find that the line that caused the crash was
JNIEnv *aEnv = (JNIEnv *)SDL_AndroidGetJNIEnv();
Any ideas on why this might occur, my idea was that maybe I’m not
initiating something when I call SDL_Init so I tried with
SDL_Init(SDL_INIT_EVERYTHING) with no change. Anything else I might try to
figure out this bug?
Whenever I come across weird crashes in places that are seemingly unrelated, I often find the cause to be pointer corruption. Perhaps you are going
out-of-bounds on an array which just happens to step on something used by SDL_AndroidGetJNIEnv()? I tend to use valgrind to find such errors. I
haven’t tried using valgrind with SDL2 on android (yet).
AlvinOn 30/09/14 19:39, ruler501 wrote:
While working with SDL for android I started getting semi random segfaults. When I debugged I couldn’t get a stack trace(It would just give two lines
of addresses and question marks with a warning about a possible corrrupted stack).
Manually commenting out lines till I found one that would let it keep running led me to find that the line that caused the crash was
JNIEnv *aEnv = (JNIEnv *)SDL_AndroidGetJNIEnv();
Any ideas on why this might occur, my idea was that maybe I’m not initiating something when I call SDL_Init so I tried with
SDL_Init(SDL_INIT_EVERYTHING) with no change. Anything else I might try to figure out this bug?
I have no idea how to get valgrind working on android. Gdb can be annoying enough to get working. Otherwise I don’t think I touch anything used by the function but I’ll look at the source and see if I can find some answers there
Alvin Beach wrote:> On 30/09/14 19:39, ruler501 wrote:
While working with SDL for android I started getting semi random segfaults. When I debugged I couldn’t get a stack trace(It would just give two lines
of addresses and question marks with a warning about a possible corrrupted stack).
Manually commenting out lines till I found one that would let it keep running led me to find that the line that caused the crash was
JNIEnv *aEnv = (JNIEnv *)SDL_AndroidGetJNIEnv();
Any ideas on why this might occur, my idea was that maybe I’m not initiating something when I call SDL_Init so I tried with
SDL_Init(SDL_INIT_EVERYTHING) with no change. Anything else I might try to figure out this bug?
Whenever I come across weird crashes in places that are seemingly unrelated, I often find the cause to be pointer corruption. Perhaps you are going
out-of-bounds on an array which just happens to step on something used by SDL_AndroidGetJNIEnv()? I tend to use valgrind to find such errors. I
haven’t tried using valgrind with SDL2 on android (yet).
Maybe not explicitly, but perhaps you are changing something via a pointer, but the pointer is/has become invalid? Could also be accessing an
uninitialised pointer? Do you see any difference when you compile the app for debug vs compiling for release?
AlvinOn 01/10/14 12:57, ruler501 wrote:
I have no idea how to get valgrind working on android. Gdb can be annoying enough to get working. Otherwise I don’t think I touch anything used by the
function but I’ll look at the source and see if I can find some answers there
Another thing to try is, if it is possible with you code base, could you rip your jni/src code out and make a desktop application? If you are using
the SDL2’s android-project, then you already have a main(). I’ve done this before. It really just depends on your jni/src code base and how dependent
it is on Android. Then you can use valgrind (I like the valkyrie gui).
One final thought, if you have updated your copy of SDL2 (e.g. from Mercurial), be sure to update your src/org/libsdl/app/SDLActivity.java. I’ve
forgotten to do that a few times as well.
AlvinOn 01/10/14 13:02, Alvin Beach wrote:
On 01/10/14 12:57, ruler501 wrote:
I have no idea how to get valgrind working on android. Gdb can be annoying enough to get working. Otherwise I don’t think I touch anything used by the
function but I’ll look at the source and see if I can find some answers there
Maybe not explicitly, but perhaps you are changing something via a pointer, but the pointer is/has become invalid? Could also be accessing an
uninitialised pointer? Do you see any difference when you compile the app for debug vs compiling for release?
maybe you are handling the jni stuff from a differnet thread than the main thread?Am 01.10.2014 um 18:16 schrieb Alvin Beach :
On 01/10/14 13:02, Alvin Beach wrote:
On 01/10/14 12:57, ruler501 wrote:
I have no idea how to get valgrind working on android. Gdb can be annoying enough to get working. Otherwise I don’t think I touch anything used by the
function but I’ll look at the source and see if I can find some answers there
Maybe not explicitly, but perhaps you are changing something via a pointer, but the pointer is/has become invalid? Could also be accessing an
uninitialised pointer? Do you see any difference when you compile the app for debug vs compiling for release?
Alvin
Another thing to try is, if it is possible with you code base, could you rip your jni/src code out and make a desktop application? If you are using
the SDL2’s android-project, then you already have a main(). I’ve done this before. It really just depends on your jni/src code base and how dependent
it is on Android. Then you can use valgrind (I like the valkyrie gui).
One final thought, if you have updated your copy of SDL2 (e.g. from Mercurial), be sure to update your src/org/libsdl/app/SDLActivity.java. I’ve
forgotten to do that a few times as well.
I call it in main right after initialization so it has to be the right thread.
Martin Gerhardy wrote:> maybe you are handling the jni stuff from a differnet thread than the main thread?
Am 01.10.2014 um 18:16 schrieb Alvin Beach :
On 01/10/14 13:02, Alvin Beach wrote:
On 01/10/14 12:57, ruler501 wrote:
I have no idea how to get valgrind working on android. Gdb can be annoying enough to get working. Otherwise I don’t think I touch anything used by the
function but I’ll look at the source and see if I can find some answers there
Maybe not explicitly, but perhaps you are changing something via a pointer, but the pointer is/has become invalid? Could also be accessing an
uninitialised pointer? Do you see any difference when you compile the app for debug vs compiling for release?
Alvin
Another thing to try is, if it is possible with you code base, could you rip your jni/src code out and make a desktop application? If you are using
the SDL2’s android-project, then you already have a main(). I’ve done this before. It really just depends on your jni/src code base and how dependent
it is on Android. Then you can use valgrind (I like the valkyrie gui).
One final thought, if you have updated your copy of SDL2 (e.g. from Mercurial), be sure to update your src/org/libsdl/app/SDLActivity.java. I’ve
forgotten to do that a few times as well.