It's SO COMPLICATED!! (Nano 1G, Testing r26038M)

[sss]

I'm going to quit working on this bug until I get my new player.  Then I will have two platforms to test the firmware problems on and I can be more certain about specific players.
________

I would like to say that testing and debugging some of the code in SVN is quite a pain in the butt because it looks like changes in the rest of the system have affected the operation of other plugins.  Let me show you what I mean:

 Doom was reliable in the last stable release but now in SVN rockbox it seems to work sometimes but not other times and this is dependent on what WADs you try to use and whether or not you complete a level.  When I was testing SVN rockdoom in slightly earlier versions, it would crash either on startup with errors or after a few seconds of running with "data abort."  Now the behavior has changed in newer versions, so for a very short time I thought the bug(s) was/were fixed.  Now it will either crash on startup like before dependent on the WAD loaded, or it will run until the end of a level and then display corruption at the level summary screen and crash with a "data abort" when attempting to change levels.  I may have solved the conditional startup problem and the summary screen corruption problem but there are now errors for certain main WADs when trying to transition between levels.

To summarize:

In apps/plugins/doom/doom.make, reverting modification r25889 like this:

Code: [Select]

--from--
DOOMCFLAGS = $(PLUGINFLAGS) -Wno-strict-prototypes -O2 -fno-strict-aliasing
--to--
DOOMCFLAGS = $(PLUGINFLAGS) -Wno-strict-prototypes -O2

seems to fix level loading errors for some main wads. (Ultimate Doom suddenly loads again).

changing these lines in rockmacros.h:

Code: [Select]

--from--
#define open(a, ...)       my_open((a), __VA_ARGS__)
--to--
#define open(a,b)          rb->open((a),(b))

AND

Code: [Select]

--from--
int my_open(const char *file, int flags, ...);
--to--
int my_open(const char *file, int flags);

AND

Code: [Select]

--from--
#define open(a, ...)       my_open((a), __VA_ARGS__)
--to--
#define open(a,b)          my_open((a),(b))

AND THEN...
reverting rockdoom.c (same as changing these lines):

Code: [Select]

--from--
int my_open(const char *file, int flags, ...)
--to--
int my_open(const char *file, int flags)

AND

Code: [Select]

--from--
if (flags & O_CREAT)
{
va_list ap;
va_start(ap, flags);
filearray[fpoint]=rb->open(file, flags, va_arg(ap, unsigned int));
va_end(ap);
}
else
filearray[fpoint]=rb->open(file, flags);
--to--
filearray[fpoint]=rb->open(file, flags);

will eliminate the corruption lines on summary screen (end of level) and get rid of the inevitable "data abort" error that occurs directly after.
However, although those bugs are fixed, some main WADs are still unusable because during the summary screen when it tries to load a different level you still get R_FlatNumForName and R_TextureNumForName errors that effectively crash the device.  It is interesting that these problems can be WAD dependent (I'm not even talking about third party WADs).  TNT and Doom 2 may work while Ultimate Doom and "Doom Registered" will crash at the end of the level.  Even Doom 2 will crash if I don't apply the above code fixes, although it will be by "data abort."  Can somebody tell me what's going on here?  I've got photos of some of the bugs and crashes this time in case they are interesting to someone.  Let me know if I should post them here or not.

And another thing, there are two rockbox skins that don't work in newer rockbox versions.  What needs to be changed to make them functional again?

[sss]

I now have a sansa fuze (v1) that I've tried it with.  The fuze is a little unstable playing music (I can get it to crash under certain conditions), but EXTREMELY UNSTABLE playing doom, regardless of the WAD file used.  It seems doom is a great stability benchmarking tool because it is the one thing than can get just about any player to crash sooner or later.
I noted that the stability issues (including data aborts, freezes, and other errors, all midgame) in doom for the fuze are COMPLETELY different than the data abort issues on the nano 1G.  Unlike the nano, which ran doom stable in 3.5.1, the fuze seems invariably unstable with doom no matter which version of the firmware was in question and there is no telling when it will crash or why.  Memory might be an issue as this thing only has 8mb of ram vs the nano's 32mb, but I think there is something more to the story as I can get ANY level to crash or data abort no matter the size or complexity as long as it wants to load-- but it can take a while to get it to crash.  Anywhere between 5 and 40 minutes is the amount of time needed to test the crash behavior.

Not sure if anyone cares but the last data abort error on the FUZE read:

Code: [Select]

Data abort
at 307BA474
FSR 0x8
(domain 0, fault 8)
address 0xE151000F

[torne]

It seems doom is a great stability benchmarking tool because it is the one thing than can get just about any player to crash sooner or later.

Doom's stability only says anything about how stable Doom is on that player. It's in no way a benchmark for Rockbox's general stability on the device: it's a huge chunk of foreign code which we didn't write, it makes various assumptions that our toolchains aren't thrilled about, etc.

Doom is not a particular priority for any of the developers, as far as I know. If you want to see it work more reliably, then the best way would be to learn how to fix it yourself and submit patches.

[[Saint]]

For what it's worth, I've never had Doom crash on my Nano1Gs.
Or my Nano2Gs for that matter.
Using current, daily, or release builds.

I *once* saw the issue you talked about earlier with the garbled text, but a reboot fixed that right up and I never saw it again.

[St.]

EDIT: BTW, I noticed you've put "(Nano 1G, Testing r26038M)" as the title of this thread, you know you're only supposed to report issues in unmodified source code right?