A question of propriety

thewanderer · Post by **thewanderer** » Sat Nov 19, 2005 4:41 am

I have a repeatable crash (or, rather, freeze) bug to report, but before I do, I'd like to make certain it's appropriate. The "properly reporting a bug" announcement topic says to only report bugs on the latest WIP version, and as a member (albeit not a coding member) of an unrelated open-source project I can certainly appreciate that. However, I'd like to know: is it acceptable to report bugs on CVS, if they are not the ephemeral "broken then quickly fixed" type? I track CVS, mostly on general principle, and would prefer to avoid going back and installing an earlier version if I don't need to do so.

LDAWG · Post by **LDAWG** » Sat Nov 19, 2005 5:42 am

Uhhh... since wehn do you have to "install" zsnes?
It doesn't put any keys into the Windows Registry, nor does it register .DLLs, among other things.

Aerdan · Post by **Aerdan** » Sat Nov 19, 2005 6:32 am

thewanderer wrote:I have a repeatable crash (or, rather, freeze) bug to report, but before I do, I'd like to make certain it's appropriate. The "properly reporting a bug" announcement topic says to only report bugs on the latest WIP version, and as a member (albeit not a coding member) of an unrelated open-source project I can certainly appreciate that. However, I'd like to know: is it acceptable to report bugs on CVS, if they are not the ephemeral "broken then quickly fixed" type? I track CVS, mostly on general principle, and would prefer to avoid going back and installing an earlier version if I don't need to do so.

Don't worry, we accept CVS-based bug reports as readily as we do WIP bug reports.

LDAWG, SHUT THE BLOODY MOTHERFUCKING HELL UP.

thewanderer · Post by **thewanderer** » Sat Nov 19, 2005 4:13 pm

Thank you. The next 'question' would be whether to just provide the information as a reply here, since the thread exists already, or start a new thread with a more appropriate subject line; if no one replies saying "just put it here" by the time I get around to writing up the report, I'll put it in a new thread just to be on the safe side.

And since I'm running zsnes under Linux, yes, I do in fact "install" it; it may not be strictly necessary, but I don't tend to keep mental track of which programs really do and do not need "make install". Just for the record.

Aerdan · Post by **Aerdan** » Sat Nov 19, 2005 4:41 pm

Go ahead and post it here.

thewanderer · Post by **thewanderer** » Sat Nov 19, 2005 8:39 pm

All right. The bug has been present since the CVS version of a few weeks ago at least, and I've been able to trigger it consistently by minor variations of the following.

Open ZSNES, make sure that none of the options under Config/Sound/Interpolation are checked, load the Chrono Trigger ROM, get into a battle, attack an enemy (with Crono, I haven't tested with anyone else), wait until the attack actually hits so the sound effect is triggered, go into the menu, go into the sound config, change the "Interpolation" setting, and (if possible) leave the menu to go back into the game. The emulator should have segfaulted by this point. It doesn't seem to make any difference whether or not the sound effect is still playing when I go into the menu; the crash happens either way.

Having an interpolation option checked to start out with just makes it harder to trigger the segfault; I've done it moving from one type of interpolation to another, as well as from no interpolation to any of the three types, and IIRC from at least one of the types to no interpolation. It sometimes takes me multiple changes from one state to another, popping back into the game in between, but I've always been able to produce the segfault. Going from "no interpolation" to any of the three types is just the simplest way to trigger it that I've found.

I've tried to capture debug information using gdb, but (perhaps as a result of the multi-threaded implementation of zsnes) I haven't been able to get anything useful even after compiling with debugging enabled.

I have sound and stereo sound both enabled, sampling at 44100 Hz, 100% volume, low-pass filter set to "hi quality" (although that last doesn't seem to make any difference)

I'm running Linux 2.6.11.2, via Debian (mostly sid by this point), and ZSNES from CVS of yesterday. I've got an Athlon XP 2200+, 512MB of PC3200 RAM, an 128MB GeForce FX 5200 (not Ultra), sound built into my motherboard. If further system information is needed, just let me know exactly what I need to dig out; I don't want to provide floods of information which don't prove to be relevant.

Similarly, if there's any other (non-'system specs') information I should have provided but didn't think of, just let me know what.

The CRC of my Chrono Trigger ROM, just for the record, is 2d206bf7. I don't think it makes an immense amount of difference, since I've been able to produce the same error in the Japanese version, so it's plainly not a matter of ROM corruption - but the information is here just in case.

(There's also the completely unrelated issue that since upgrading to yesterday's CVS, from CVS of about two weeks ago, my "recently open ROMs" list has been empty and has stayed that way no matter what I do - but that's got nothing to do with the crash bug, it's just annoying; I've mentioned it here because I can, not because I expect people to do anything about it immediately.)

Aerdan · Post by **Aerdan** » Sat Nov 19, 2005 9:36 pm

If you're using GCC 3.4, please don't use -O3 when compiling, unless you also specify -fno-web.

-fweb is included in -O3 and, in GCC 3.4 at least, removes live code.

This may or may not fix the issue with 'recently played ROMs' being [and staying] blank.

Jonas Quinn · Post by **Jonas Quinn** » Sat Nov 19, 2005 10:19 pm

thewanderer wrote:(There's also the completely unrelated issue that since upgrading to yesterday's CVS, from CVS of about two weeks ago, my "recently open ROMs" list has been empty and has stayed that way no matter what I do - but that's got nothing to do with the crash bug, it's just annoying; I've mentioned it here because I can, not because I expect people to do anything about it immediately.)

That's because of Nach's parsegen update. It overwrites the last used roms stuff when you start ZSNES the first time after compiling.

thewanderer wrote:All right. The bug has been present since the CVS version of a few weeks ago at least, and I've been able to trigger it consistently by minor variations of the following.

Open ZSNES, make sure that none of the options under Config/Sound/Interpolation are checked, load the Chrono Trigger ROM, get into a battle, attack an enemy (with Crono, I haven't tested with anyone else), wait until the attack actually hits so the sound effect is triggered, go into the menu, go into the sound config, change the "Interpolation" setting, and (if possible) leave the menu to go back into the game. The emulator should have segfaulted by this point. It doesn't seem to make any difference whether or not the sound effect is still playing when I go into the menu; the crash happens either way.

Having an interpolation option checked to start out with just makes it harder to trigger the segfault; I've done it moving from one type of interpolation to another, as well as from no interpolation to any of the three types, and IIRC from at least one of the types to no interpolation. It sometimes takes me multiple changes from one state to another, popping back into the game in between, but I've always been able to produce the segfault. Going from "no interpolation" to any of the three types is just the simplest way to trigger it that I've found.

I've tried to capture debug information using gdb, but (perhaps as a result of the multi-threaded implementation of zsnes) I haven't been able to get anything useful even after compiling with debugging enabled.

I have sound and stereo sound both enabled, sampling at 44100 Hz, 100% volume, low-pass filter set to "hi quality" (although that last doesn't seem to make any difference)

I'm running Linux 2.6.11.2, via Debian (mostly sid by this point), and ZSNES from CVS of yesterday. I've got an Athlon XP 2200+, 512MB of PC3200 RAM, an 128MB GeForce FX 5200 (not Ultra), sound built into my motherboard. If further system information is needed, just let me know exactly what I need to dig out; I don't want to provide floods of information which don't prove to be relevant.

Similarly, if there's any other (non-'system specs') information I should have provided but didn't think of, just let me know what.

The CRC of my Chrono Trigger ROM, just for the record, is 2d206bf7. I don't think it makes an immense amount of difference, since I've been able to produce the same error in the Japanese version, so it's plainly not a matter of ROM corruption - but the information is here just in case.

That bug is already known:
http://zsnes.ownaged.com/bugzilla/show_bug.cgi?id=21

Post by **Nach** » Sat Nov 19, 2005 11:24 pm

Jonas Quinn wrote:
thewanderer wrote:(There's also the completely unrelated issue that since upgrading to yesterday's CVS, from CVS of about two weeks ago, my "recently open ROMs" list has been empty and has stayed that way no matter what I do - but that's got nothing to do with the crash bug, it's just annoying; I've mentioned it here because I can, not because I expect people to do anything about it immediately.)
That's because of Nach's parsegen update. It overwrites the last used roms stuff when you start ZSNES the first time after compiling.

Yes, and if the problem persists, open ~/.zsnes/zguicfgl.dat and remove prevloaddnamel and prevloadfnamel lines.

thewanderer · Post by **thewanderer** » Sat Nov 19, 2005 11:33 pm

I'm using GCC 3.3.5; I just tested, and the final two steps of the compile (at least) use -O0 and -O2 respecfively.

I had tried to get the "recently opened ROMs" list to rebuild, in the usual way (since I've lost the list before), by opening a ROM (say, Chrono Trigger) and then opening another; unfortunately , every time I restarted (even if I had closed the emulator normally rather than killing it after it crashed) the list would be empty again. This last time when I tried, during the most recent session experimenting with what could produce the bug, the list did not remain empty... I don't know what changed (certainly not the source or the installed copy), but it seems to be working now.

I'm not sure that I like having the list wiped with every new version; I tend to use the list to go back to a few of the same games over and over (testing different text in translations, for instance), and that isn't going to change just because I've re-synced with the latest CVS. Still, if it's intentional behaviour I suppose I can get used to it.

Apologies for reporting an already known bug; I didn't realize that ZSNES even had a Bugzilla until I saw the link in Aerdan's .sig, after posting. I'm glad to see that it's known about; I'll be waiting for a fix.

Post by **Nach** » Sat Nov 19, 2005 11:50 pm

thewanderer wrote: I'm not sure that I like having the list wiped with every new version

Every new version?

I changed the format it's saved in twice in the past several months. That's not every new version, and with the last change, it doesn't look like I'll be changing it for a long time.

thewanderer · Post by **thewanderer** » Mon Nov 21, 2005 12:41 am

Oh. I interpreted "new version" as meaning "new copy of ZSNES" (i.e. one which had not previously been run), or at least "version resulting from compiling after any change in the source code anywhere". I'm not sure why I did that, but it did make sense at the time. Not nearly as much of a problem, then; thank you for the information.

ZSNES board

A question of propriety

A question of propriety

Re: A question of propriety