#0 0xb7be2aed in getenv () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7e46e14 in X11_KeyToUnicode () from /usr/lib/libSDL-1.2.so.0
#2 0xb7e429b9 in X11_KeyToUnicode () from /usr/lib/libSDL-1.2.so.0
#3 0xb7e0e785 in SDL_PumpEvents () from /usr/lib/libSDL-1.2.so.0
Obviously, SDL_PumpEvents() isn’t calling X11_KeyToUnicode()
directly…can you try this with a debug build of SDL?
–ryan.
env_override = SDL_getenv(“SDL_MOUSE_RELATIVE”);
Okay, so it’s definitely crashing in getenv(), and that specific call
looks okay…it’s possible something is silently corrupting memory, and
wrote on the environment table’s memory prior to this call.
I guess the next step is to see if any SDL program does this on your
system. In the SDL sources, there’s a “test” directory…pick one or two
of your favorites and see if they crash in the same way.
If they don’t, it might be a bug in your app, I’m afraid, but we’ll see
what happens.
–ryan.
Going back to your first paragraph, nothing would surprise me with this
code. If it makes a difference, I can putenv(“SDL_MOUSE_RELATIVE=1”);
as the first line of main() and everything works okay. Sorry for being
naive, been a long time since I did much C++.
Doing so is only masking the problem, though…if it overwrote the
environment table, it’s still going to overwrite something until you
figure out what.
Is valgrind the best option at this point?
I would think so, but it didn’t seem to find anything the first
time…which might mean you’re overwriting static memory, not some
dynamically allocated buffer. Look for global arrays.
The good news is that it seems to crash pretty quickly, so you’re
probably causing problems somewhere in the startup code.
–ryan.