ZSNES problems on Mandrake 9.2

[jamez1988]

I downloaded zsnes for RedHat 8, or something like that. I installed it on Mandrake 9.2. It crashed every 5 minutes. I got sick of attempting to play "Super Mario World" at the rate of one crash a level, so I uninstalled it and got the version for Mandrake 9.2 off an official Mandrake mirror.

I installed that package and ran it. Same problem.

this computer has 96 Mb Ram, about 500MHz on an AMD processor and some obscure graphics card with like 4 megs. It has two hard drives, one with 15 gigs for linux, 15 gigs for windows files, and the other drive with 8 gigs for windows to live on. For some reason, Linux cannot access the files on the other partition of the drive it lives on.

Does anyone know what the problem is?

(With ZSNES, that is. I really don't care about the fact that linux can't acess the files in the other partition of the drive it lives on)

[Dark Ninja]

Well, that 4MB graphics card isn't helping you out.

Also, good video drivers help on top of that.

And, I noticed that if you use the "cheats" stuff, a lot of time it causes games to crash horribly.

[jamez1988]

Dude, the emulator runs fine with the 4MB graphics card.
My problem is that it keeps crashing. I've never had any trouble with my video drivers under linux before.
I don't use any cheats or anything, it just crashes.

[bwkaz]

If you aren't already, you can try running zsnes from a shell and then take a look at the error that it prints when it dies.

If you've done that, or if the error is merely "Segmentation violation" or "Segmentation fault", then maybe run it under gdb to see where in the code it's segfaulting. Running it under gdb will require that your zsnes executable was built with debugging support, though (the -g option to gcc), so you might have to rebuild it yourself.

Once in gdb, use "run" to start the program up. Play it until it segfaults (when that happens, the terminal that gdb is running in will take over, and zsnes will appear to have frozen up). You'll be back at the gdb prompt. Do a "bt" (backtrace) to get a call stack backtrace, which is the set of functions that have all called each other, right up to the one that segfaulted.