Gpsp 0.9-2xb

[Zenny]

You know I actually wanted to note the autoframeskip/manual frameskip thing, since i overclock to 280 i dont want any frames skipped so i set them to off/0 and I have a feeling it might have something to do with the freezes, maybe something in skipping of frames actually causes the freeze? I have maybe had 1 freeze overall releases both zod's and exophase's and deleting the config files for the games fixed that.

 

[fusion_power]

QUOTE
I have no clue about Telnet so all I can do is play GPSP, fear the crashes and watch, when they happen. I can't have a config problem because The games I play are new on my GP2X so no old rom-cfg's exist and I had deleted the GPSP- standard -cfg of course.
Like I sayed before, the crashes are absolutely random. Ok, I had a reproducable series of crashes, when I want to load a Savegame in Metroid but after some resets, this was gone to. (GP2X need his 15-30 Seconds to lose his Ram-content until he can turned on again I think so I shouldn't instant turn OFF/ON this Thing.

I mentioned only another phenomenon: Many games "Hangs" for some miliseconds, maybe reloading stuff, graphic, music... I don't know. Maybe these are the points where crashes can be happen?

I think you missed the point Exophase was making here.

As a developer, bug reports which are vague (i.e. "crashes are absolutely random") are usually of little help in debugging a system and getting it to work. I think Exophase would benefit more if you mentioned OC speeds, firmware, loaded rom, config, game location, etc. If this seems to be of no relevance then its probably best to leave Expohase and any devs to find the problem for themselves.

If you manage to find any consistant way of making gpsp crash then this gives Exophase something to work on.

I had reported all my settings more than often here. And normally I don't change my Settings for GPSP.

By the way, when we can expect a new Version of the Emulator? besides the crash-problem there still enough small bugs like the FPS display INSIDE the gba Screen area. (Often over score/health game displays). Should be outside, we have more than enough free black space.
AND when you in menu and returning to the game, B-button from menu-selection makes A-button-action ingame. Not always useful I find.
And the savegame bug still is in the Emulator: Saves are not broken but you have to reload a new state twice when you change the slot to get it working, can be confusing.

 

[Zeladin]

Well for a start I only get that cyclical frame stutter when I have Autoframeskip on, standing in one place, I'm almost certain it shouldn't do that... Exophase already mentioned that that might be a source of issues I think.

Isn't the autoframeskip the ideal thing to use (other than the cyclic stutter) though? I found manual causes alot of slow-down at certain points in a game. I suppose if you are lucky enough to OC to 270 MHz or so then it is not as much of an issue. For those that can't auto seems the best.
I'm not sure... I would have thought the idea of autoframeskip was that it skipped frames only when necessary. Whatever the story is, in Baldurs Gate at least at 250mhz (Yes I admit I can OC to 270, but its a waste of battery), when FS is off, I get a steady 60fps in an area, autoFS gives 25-60 (actual frames), and FS manual 1 gives a steady 30fps. So in this context at least autoframeskip gives the 'roughest' gameplay. Then I think its broken - so...

 

[Rivroner]

Maybe auto frameskip gives you the roughest gameplay but you will get the most acurracy gamplay to original.No slowdowns in scroll or musics.

 

[notaz]

Well I was playing Advance Wars for ~ 40 minutes and it hung on me. I had serial cable plugged in, so I can tell that:

* It didn't produce any output to stdout/stderr
* It didn't segfault, the process was still alive, memory usage and thread count normal (same as on startup),
* Linux was also alive and responsive, so it is not overclocking issue (I was not overclocking much anyway)

So I assume it simply deadlocked. MK2 fw 2.1.1
Default settings, only scaling turned off, "good" gba bios.

I'll try to do a debug build and attach gdb when it hangs next time, whenever I really want to play it (because trying to reproduce it intentionally takes so much time..).

 

[fusion_power]

* Linux was also alive and responsive, so it is not overclocking issue (I was not overclocking much anyway)

Sounds like it should be possible for GPSP to crash WITHOUT we have to restart the whole GP2X. For me as normal user without external control possibilities maybe the emu or gmenu or whatever can be patched in the way, we land on the gp2x "desktop" after a emu-crash instead of a frozen screen and a time eating Handheld restart. This would be a big improvement so crashes don't hurt that much.

 

[Exophase]

Well I was playing Advance Wars for ~ 40 minutes and it hung on me. I had serial cable plugged in, so I can tell that:

* It didn't produce any output to stdout/stderr
* It didn't segfault, the process was still alive, memory usage and thread count normal (same as on startup),
* Linux was also alive and responsive, so it is not overclocking issue (I was not overclocking much anyway)

So I assume it simply deadlocked. MK2 fw 2.1.1
Default settings, only scaling turned off, "good" gba bios.

I'll try to do a debug build and attach gdb when it hangs next time, whenever I really want to play it (because trying to reproduce it intentionally takes so much time..).

Okay, so it's frozen, not crashed. It's perhaps in deadlock.

Yes, autoframeskip is only supposed to skip frames when "necessary." But determining when isn't at all a trivial matter. I've tried to improve it, and I'll probably continue to do so..

 

[notaz]

ok it happened again and I could attach to one thread:
CODE

(gdb) bt
#0 0x00129a70 in __pthread_sigsuspend ()
#1 0x00128b7c in __pthread_wait_for_restart_signal ()
#2 0x00126614 in pthread_cond_wait ()
#3 0x0010bdc4 in SDL_CondWait ()
#4 0x000aa48c in update_gbc_sound (cpu_ticks=8159) at ../sound.c:478
#5 0x000091c8 in update_gba () at ../main.c:610
#6 0x000f7664 in arm_update_gba_thumb ()
#7 0x003e930c in rom_translation_cache ()
#8 0x003e930c in rom_translation_cache ()
Previous frame identical to this frame (corrupt stack?)

(gdb) p gbc_sound_buffer_index
$1 = 49542
(gdb) p sound_buffer_base
$2 = 46080
(gdb) p audio_buffer_size
$4 = 2048
(gdb) p gbc_sound_buffer_index - sound_buffer_base
$5 = 3462
(gdb) p audio_buffer_size * 3 /2
$6 = 3072


Unfortunately I was not able to attach to other threads, because the program probably needs to be linked with debug pthread library or something. GDB would just not list threads, and attaching directly to some thread caused gdb deadlock.

For me as normal user without external control possibilities maybe the emu or gmenu or whatever can be patched in the way, we land on the gp2x "desktop" after a emu-crash instead of a frozen screen and a time eating Handheld restart. This would be a big improvement so crashes don't hurt that much.

The problem is that it does not chash, it still runs, but it stops on waiting for some event which never happens. And that is not so easy to detect, because it is often normal situation.

 

[Exophase]

ok it happened again and I could attach to one thread:
CODE

(gdb) bt
#0 0x00129a70 in __pthread_sigsuspend ()
#1 0x00128b7c in __pthread_wait_for_restart_signal ()
#2 0x00126614 in pthread_cond_wait ()
#3 0x0010bdc4 in SDL_CondWait ()
#4 0x000aa48c in update_gbc_sound (cpu_ticks=8159) at ../sound.c:478
#5 0x000091c8 in update_gba () at ../main.c:610
#6 0x000f7664 in arm_update_gba_thumb ()
#7 0x003e930c in rom_translation_cache ()
#8 0x003e930c in rom_translation_cache ()
Previous frame identical to this frame (corrupt stack?)

(gdb) p gbc_sound_buffer_index
$1 = 49542
(gdb) p sound_buffer_base
$2 = 46080
(gdb) p audio_buffer_size
$4 = 2048
(gdb) p gbc_sound_buffer_index - sound_buffer_base
$5 = 3462
(gdb) p audio_buffer_size * 3 /2
$6 = 3072

Unfortunately I was not able to attach to other threads, because the program probably needs to be linked with debug pthread library or something. GDB would just not list threads, and attaching directly to some thread caused gdb deadlock.

For me as normal user without external control possibilities maybe the emu or gmenu or whatever can be patched in the way, we land on the gp2x "desktop" after a emu-crash instead of a frozen screen and a time eating Handheld restart. This would be a big improvement so crashes don't hurt that much.

The problem is that it does not chash, it still runs, but it stops on waiting for some event which never happens. And that is not so easy to detect, because it is often normal situation.


That's pretty enlightening, although not that surprising. The question is, why would it get stuck there in particular? The call to sound_callback in the audio thread should eventually pull it out.

 

[Tobriand]

Well, maybe it does - it's just when people have been waiting for 5-10 seconds they assume it's not going to recover and reset? At least some of the time, it's conceivable that that's happening - much like hangs in PC games every so often.

 

[Exophase]

Well, maybe it does - it's just when people have been waiting for 5-10 seconds they assume it's not going to recover and reset? At least some of the time, it's conceivable that that's happening - much like hangs in PC games every so often.

I don't see any reason for it to take a long time to happen, it should happen within the same time it always does, a matter of milliseconds (depending on buffer size)

 

[notaz]

Hm, why are you unlocking sound_mutex _before_ increasing gbc_sound_buffer_index (in the very end of gbc_sound_buffer_index())? Couldn't this scenario happen:

1. At the very end of update_gbc_sound() sound_mutex is unlocked.
2. Just after that sound_callback() kicks in. gbc_sound_buffer_index is not yet increased, so sound_callback() hits SDL_CondWait, which does not return until signalled, so it waits.
3. update_gbc_sound() increases gbc_sound_buffer_index, but it's too late, sound_callback() is already in SDL_CondWait(), which won't return until it is signalled.
4. update_gbc_sound() returns and is called again later. Then it also hits SDL_CondWait(), which does not get signalled, because sound_callback() also waits on the same condition. Deadlock.

Shouldn't gbc_sound_buffer_index be protected by sound_mutex (at the end of update_gbc_sound()) and SDL_CondSignal() called _after_ increasing gbc_sound_buffer_index?

(this is what I have noticed after a brief look, I haven't done extensive analysis of the situation).

 

[cowai]

Hurray!?

 

[Tobriand]

Does sound potentially promising... we'll have to see what Exophase says - fingers crossed!

 

[fusion_power]

For me as normal user without external control possibilities maybe the emu or gmenu or whatever can be patched in the way, we land on the gp2x "desktop" after a emu-crash instead of a frozen screen and a time eating Handheld restart. This would be a big improvement so crashes don't hurt that much.

The problem is that it does not chash, it still runs, but it stops on waiting for some event which never happens. And that is not so easy to detect, because it is often normal situation.


This Emulator is really a special one, right? :lol: Well, i thought it has something to do with sound because I always noticed these gfx hangers here and there when sound hangs for some miliseconds (especially in Baldurs Gate), then everything was fine when Sound/Music was starting again. I'm sure exact the same reason who does the small hangs makes the complete crash-hanging, I only have no clue why this happen only sometimes. The 1337 explanations here are a little to high for me but I'm sure you guys are on the right way to fix the problem. Good Luck!

 

[___]

This is going to be interesting. I wonder if this is going to get rid of the freezes.

 

[Exophase]

Hm, why are you unlocking sound_mutex _before_ increasing gbc_sound_buffer_index (in the very end of gbc_sound_buffer_index())? Couldn't this scenario happen:

1. At the very end of update_gbc_sound() sound_mutex is unlocked.
2. Just after that sound_callback() kicks in. gbc_sound_buffer_index is not yet increased, so sound_callback() hits SDL_CondWait, which does not return until signalled, so it waits.
3. update_gbc_sound() increases gbc_sound_buffer_index, but it's too late, sound_callback() is already in SDL_CondWait(), which won't return until it is signalled.
4. update_gbc_sound() returns and is called again later. Then it also hits SDL_CondWait(), which does not get signalled, because sound_callback() also waits on the same condition. Deadlock.

Shouldn't gbc_sound_buffer_index be protected by sound_mutex (at the end of update_gbc_sound()) and SDL_CondSignal() called _after_ increasing gbc_sound_buffer_index?

(this is what I have noticed after a brief look, I haven't done extensive analysis of the situation).

Indeed, good find. I moved the unlock/signal to the end of the function. I just wonder why I haven't noticed this sooner.. I guess it's a pretty narrow section for it to get stuck in.

Let me know if you see anything else.. I don't like synchronization code ^_^

I don't intend to release a new version for a while still so someone might want to try changing this themselves and seeing if it improves things. I don't recommend using devkitGP2X, I've tried it, I can't get it to produce good binaries. I use the Open2x toolchain (if it wasn't obvious from the makefile)

 

[Daid]

Indeed, good find. I moved the unlock/signal to the end of the function. I just wonder why I haven't noticed this sooner.. I guess it's a pretty narrow section for it to get stuck in.

Let me know if you see anything else.. I don't like synchronization code ^_^

I don't intend to release a new version for a while still so someone might want to try changing this themselves and seeing if it improves things. I don't recommend using devkitGP2X, I've tried it, I can't get it to produce good binaries. I use the Open2x toolchain (if it wasn't obvious from the makefile)

Would disabling sound rule out this possible deadlock? I'm currently stuck in zelda minish cap with a 100% of the time crash at a sertain point. I can walk back fine, but every time I enter a certain room it hangs after a few seconds.

I haven't been able to build gpSP yet. But then again, I shouldn't have tried it with devkitGP2X as soon as I can build succesfully I'll try to investigate this hangup (or crash, haven't accessing linux afterwards yet)

 

[Creature XL]

I haven't been able to build gpSP yet. But then again, I shouldn't have tried it with devkitGP2X as soon as I can build succesfully I'll try to investigate this hangup (or crash, haven't accessing linux afterwards yet)

If you use LiNUX then download the prebuild toolchain and library from open2x. Those work for me without problems. Building those with the script didn't worked, cause it seems to build an older version of gcc. I got an compilation warning about bad singedness or something.

After being able to compile it, I could finally remove the cpu_speed thing and now gpSP starts up faster directly into the rom selection.
And changed the default volume

 

[Exophase]

Indeed, good find. I moved the unlock/signal to the end of the function. I just wonder why I haven't noticed this sooner.. I guess it's a pretty narrow section for it to get stuck in.

Let me know if you see anything else.. I don't like synchronization code ^_^

I don't intend to release a new version for a while still so someone might want to try changing this themselves and seeing if it improves things. I don't recommend using devkitGP2X, I've tried it, I can't get it to produce good binaries. I use the Open2x toolchain (if it wasn't obvious from the makefile)

Would disabling sound rule out this possible deadlock? I'm currently stuck in zelda minish cap with a 100% of the time crash at a sertain point. I can walk back fine, but every time I enter a certain room it hangs after a few seconds.

I haven't been able to build gpSP yet. But then again, I shouldn't have tried it with devkitGP2X as soon as I can build succesfully I'll try to investigate this hangup (or crash, haven't accessing linux afterwards yet)


Turning off sound won't change anything, that just mutes the output. What point are you stuck at? Well, if you have a deterministic location, definitely see if it's fixed by this.