Clip Zip Divide by Zero 30083AC0

[saratoga]

Config file doesn't matter for me (crashes if its deleted), but the folder does matter.  If I put it in a directory alone, then it plays.  If I put it in a directory with one other MP3 file so that a track after it must be buffered, then it crashes. 

Try with this folder:

http://mit.edu/mgg6/www/crashes.7z

Edit:  This crashes the Zip, but not the Clip+.

[mudlord]

Found something interesting, indeed doesnt crash from the Zip's internal memory, only crashes from the microSD card. I'll try adding more files and seeing what happens from internal memory.

edit: yep, confirmed your crash scenario with internal memory, too.

[dreamlayers]

I'm getting crashes when running from internal memory when there are other things to play afterwards. There is no crash if the m4a is the only playable file in the directory or if it comes last. The crash is when fetching cached->id at the "if (cached && cached->id == handle_id) {" line in find_handle() in apps/buffering.c:

Edit: disregard what I said before. It is actually in the while loop lower down in find_handle(), when fetching m->id:

http://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/buffering.c;h=96ec92201fffa468128c10015fad6580d5bbff1c;hb=HEAD#l403

Code: [Select]

    while (m && m->id != handle_id) {
        m = m->next;
    }

Edit2: This is a RAM dump when the crash occurred: https://dl.dropboxusercontent.com/u/16662598/Rockbox/internal_ram_clipzip_buffercrash.bin.xz This seems to be the handle situation. Offsets are in RAM dump, which started at 0x30000000 in memory. first_handle (pointer to first handle) is at A4A40 and pointer to next handle is at handle offset plus 0x12C.

1680a0 id=1
168918 id=2
169124 Next handle should be here, but there's no sign of it and other data instead.

Edit3: This starts around 7d1a47c Rewrite filesystem code (WIP), because 95a4c3a works but da4938d crashes.

[jhMikeS]

This is particular to the file format?

[saratoga]

This is particular to the file format?

I have only been able to reproduce it with an AAC followed by an MP3. 

[jhMikeS]

A regular, non-zero pattern fill of the entire audio buffer just before playback starts might help. It's hard to tell if the garbage was already there or filled-in by playback's file reading. Post a RAM dump of that.

[jhMikeS]

Perhaps provide the very file as well, please?

[saratoga]

Sorry thought you had this:
http://mit.edu/mgg6/www/crashes.7z

Edit:  Playing the M4A in that folder structure generates the crash.  Other structures do not necessarily (see dreamlayers comment above).

Edit2:  The Zip and Fuze+ crash, but I could not get the Clip+ to. 

[jhMikeS]

Sorry thought you had this:
http://mit.edu/mgg6/www/crashes.7z

I guess I missed that. I tried the direct m4a link and it wasn't working.

Does this only happen when the buffering of the mp3 starts (I don't think the first file will fit in its entirety)? I ask because I don't know if I'll be able to duplicate it because the closest device I have as far as memory size is a Fuze V2. My only AMS V1 is a clip with only 2MB.

I'm suspicious that it's low-level if it's specific to certain devices. It's worth mentioning here again that the newer file system code doesn't align buffers at the file API level, which already had side effects on another model but that was fixed up.

It's also possible that obeying POSIX more closely actually changed some expected return values/errnums.

Getting a sentinel-marked buffer dump would help me see if the last handle for the MP3 metadata isn't just being clobbered on account of over reading the previous M4A.

Well, I've got plenty of ideas of things to check but not much info yet to start ruling things out. Will get back...

[saratoga]

Fuze v2 and Zip are nearly identical (same SOC, same memory, both color displays) so I expect it will happen on Fuze v2, but I don't have one to try. 

There was also a report of an ALAC file that causes the same effect (crash post file system rework, fine before it), but I never got a sample to test so I didn't pay attention to it.  Does the MP4 parser do something unusual compared to other codecs?

[dreamlayers]

When playing the "crashes" directory, the Clip Zip sim prints "rebuffer_handle(): space is needed". This does not happen when: the mp3 file comes first and I play either file, the m4a is the only file in the folder, or I play a folder with mp3 files. Everything seems to work fine in the sim, but I wonder if that rebuffer_handle() somehow fails on the real device.

[jhMikeS]

The Fuze V2 gets hit with a data abort followed by an undefined instruction. It looks like that particular MP3 has to follow the M4A. I haven't found other MP3 files already on the device that I replace it with that trigger the bug.

ETA: e200 V1 also has issues with the same file combination but doesn't crash outright. I attached a capture of the crazy buffering screen stats.

ETAA: It's worthy to note that both files fit in the buffer so it's strictly these in series that's triggering.

[jhMikeS]

Finally should be squashed in eefc7c7.