Hi Folks, I’m new to SDL and I’m finding debugging a bit of a nightmare. I’m
working mostly from the console in mipsEEel-linux and find that certain
operations will cause my code to crash, SDL seems to take complete control of
the input devices on my system and i can’t swap to another virtual terminal
to kill the process off or even reset the system and i’m forced to do a hard
reboot.
Is there a way I can get back to a shell once SDL has crashed? I don’t really
want to work in X because of the speed difference.
Hi Folks, I’m new to SDL and I’m finding debugging a bit of a nightmare. I’m
working mostly from the console in mipsEEel-linux and find that certain
operations will cause my code to crash, SDL seems to take complete control of
the input devices on my system and i can’t swap to another virtual terminal
to kill the process off or even reset the system and i’m forced to do a hard
reboot.
Is there a way I can get back to a shell once SDL has crashed?
Is SDL handling the crash and calling the SDL_Parachute function to reset
the video mode?
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
not that I can see, when SDL crashes all i have is a blank (graphics mode)
screen with an (imovable) mouse cursor in the top left corner.
I’ve found that crashes are far less frequent when I use C rather than C++ so
I’m back coding in C (which is a bit of a nuisance as I’d like to use the
STL).
To compound the problem, I’m working on Playstation2 Linux which doesn’t
behave entirely like Intel Linux, I can’t use gdb with and SDL graphics mode
application unless I’m working from XWindows.
Is there a flag I can set to ensure calling the SDL_Parachute function or
something similar?
Thanks
dunch.On Wednesday 04 December 2002 07:30, Sam Lantinga wrote:
Hi Folks, I’m new to SDL and I’m finding debugging a bit of a nightmare.
I’m working mostly from the console in mipsEEel-linux and find that
certain operations will cause my code to crash, SDL seems to take
complete control of the input devices on my system and i can’t swap to
another virtual terminal to kill the process off or even reset the system
and i’m forced to do a hard reboot.
Is there a way I can get back to a shell once SDL has crashed?
Is SDL handling the crash and calling the SDL_Parachute function to reset
the video mode?
Er, my method is always if SDL initializes correctly, I call
atexit(SDL_Quit) before doing anything else, so if my program seg faults
or there’s a crash, SDL_Quit() will still be called. I don’t know if
you’re already doing something like this though. atexit() is an ANSI
function I believe.On Wed, 2002-12-04 at 07:55, Duncan Hughes wrote:
Is there a flag I can set to ensure calling the SDL_Parachute function or
something similar?
atexit() handlers won’t be called if your program exits abnormally (eg
via a signal).
If you have a SEGV handler and you exit() from it, it might, but then
you’re probably not able to write a core file, which would make
debugging much harder.On Wed, Dec 04, 2002 at 07:04:28AM -0800, Chris Thielen wrote:
Is there a flag I can set to ensure calling the SDL_Parachute function or
something similar?
Er, my method is always if SDL initializes correctly, I call
atexit(SDL_Quit) before doing anything else, so if my program seg faults
or there’s a crash, SDL_Quit() will still be called. I don’t know if
you’re already doing something like this though. atexit() is an ANSI
function I believe.
Is there a flag I can set to ensure calling the SDL_Parachute function or
something similar?
Er, my method is always if SDL initializes correctly, I call
atexit(SDL_Quit) before doing anything else, so if my program seg faults
or there’s a crash, SDL_Quit() will still be called. I don’t know if
you’re already doing something like this though. atexit() is an ANSI
function I believe.
yeah, I’m already doing that and i’ve written a signal handler to call
SDL_Quit whenever I press ctrl+c but that doesn’t work either.
It seems that SDL grabs complete control of the keyboard/mouse/display
whenever i run from the console and when it locks up I’m unable to regain
control of the system, for example if I set a breakpoint in gdb, the program
runs until the breakpoint is hit but then keeps control of the
screen/keyboard so I’ve effectively lost control of the sytem.
I suspect that this is a problem with the SDL/Playstation2 drivers and I’m
hoping that someone on the list has some experience of the ps2 and can tell
me for sure.
Oh well, I am starting to make a little progress now with SDL which I think is
a really good library. I’m just having a few teething troubles.
Thanks, dunch.On Wed, 2002-12-04 at 07:55, Duncan Hughes wrote:
On Wed, 2002-12-04 at 07:04:28, Chris Thielen wrote:
What I typically do is telnet (or ssh or whatever) into my test system
from another box, and (in X) run it in the debugger on the test-box
display from a telnet terminal, or (for fbcon) attach to it with the
debugger after it’s already running…
Hope that helps…
-LorenOn Wed, 2002-12-04 at 12:11, Duncan Hughes wrote:
yeah, I’m already doing that and i’ve written a signal handler to call
SDL_Quit whenever I press ctrl+c but that doesn’t work either.
It seems that SDL grabs complete control of the keyboard/mouse/display
whenever i run from the console and when it locks up I’m unable to regain
control of the system, for example if I set a breakpoint in gdb, the program
runs until the breakpoint is hit but then keeps control of the
screen/keyboard so I’ve effectively lost control of the sytem.
I suspect that this is a problem with the SDL/Playstation2 drivers and I’m
hoping that someone on the list has some experience of the ps2 and can tell
me for sure.
Oh well, I am starting to make a little progress now with SDL which I think is
a really good library. I’m just having a few teething troubles.