Rockbox

000090D0 seems to be in add_handle() in apps/buffering.c

Isn't this the same error you were getting earlier, that turned out to be file corruption on your device?

Also, please be more descriptive. Unless you've tested every audio format and encoding option Rockbox supports, "any file" may not be correct, so list details that can be used by others to reproduce (what settings you've changed, exact file types, etc). Also, this is a build you downloaded from our site, and not one you compiled yourself?

Which build tools did you use?

I'm having a very similar issue, but the address is slightly different (0x9040).

It happens when I browse the database and select <All tracks> in my "Various Artists" album artist node. In this node, the tracks are of different formats. Maybe the metadata gathering of the first unbuffered track is involved.

Something like this happens to me too on my c200 but so far only with one specific folder and only when I start playing this album by selecting the first track - reproducable data abort at 00008CC4 (0) at the time it *stops* buffering as the disk activity symbol in my WPS tells me. Funnily enough the crash does not happen if I start playing track 2 even when skipping back to track 1 and it has to buffer again. Oh, also important for reproducing is a WPS with album art in this specific case...

There were no file system errors on my microSD (checked with chkdsk) and a binary comparison to the "master" music directory on my PC also showed no differences, files work perfectly there).

If I remember correctly, amiconn also tracked it back to the add_handle function.

My error reads "Data Abort at 0000A634 (0)", if it helps.

From the attached elf I read:
90d0: e5843000 str r3, [r4]
90d4: e2833001 add r3, r3, 0x1
90d8: e3c33102 bic r3, r3, 0x80000000
which is:
new_handle->id = cur_handle_id;
in add_handle code. So "new_handle" seems to be invalid here.

My data abort is earlier. Using r19965 and e200, my data abort happens 0x947C.
The disassembly of that part (add_handle() ): http://pastebin.ca/1333249

Note that Toni's line is way below ( 9498: e5853000 str r3, [r5] )

And another note: Even though my playlist reproduces the data abort prefectly (after cold boot), the data abort disappears by just slightly altering the buffersize (e.g. by adding logf support, or disabling dircache and load to ram), or by resuming playback at a few seconds into the first track of the playlist instead of 0.

My observation is that the 6th track is just with very few bytes in the buffer and that the abort happens very quickly after track count goes to 6 . The data abort happens when buffering is finished. Possibly split seconds later (I could imagine that buffering the metadata of the first unbuffered track causes some failure).
However, this is not the case for Marianne's folder, so partial buffering seems not related.

This fixes the data abort for me (it makes sure new_widx is still 4byte aligned after changing it).

BUT: On the very album that causes the abort (without the patch), Rockbox doesn't stop boosting when buffering is finished. It unboosts normally on other albums. Maybe this is a hint on the real problem.

Can you look if the patch fixes it for you anyway?

im assuming this is for the e200?

The task is initially about the e200. c200 seems to be affected too. The patch I added is target independent at all.

2 things i forgot too mention; 1) the WPS i am using for this is freestate, from http://www.rockbox.org/twiki/bin/view/Main/WpsSansaE200#Free_State 2) my AA is all between 300 - 500 px tall/wide. And the patch didnt do much, just delayed the crash.

Delayed? How?

I checked the piece of code in add_handle() which calculates new 'cannot wrap' handles:

With current code I basically get following logics after removing the macros:

else if(!can_wrap)
{
if(new_widx < buffer_len-1)
{
if(new_widx + sizeof(struct memory_handle) + data_size > buffer_len-1)
new_widx = buffer_len-1 - sizeof(struct memory_handle);
}
}

which is buggy, because:
1) It can overwrite data from the previous handle
2) It will use the guard buffer by default for data storage
3) If the guard buffer is too small unrelated data can be overwritten

To my understanding the correct logic is as follows:

else if(!can_wrap)
{
if(new_widx + len > buffer_len)
new_widx = 0; /* wrap to the start */
}

Gareth, can you please be more specific about your recent report? It doesn't really help me.

Using this patch, which does what Toni says (hopefully, at least), I get the same results. No abort, but continuous boosting. The 6th track isn't buffered too, while SVN does that and data aborts (r20010).

The constant boosting is another bug. I don't completely understand playback.c, but it seems, that the 'filling' state should be triggered more often, to make the following condition true:
if (filling != STATE_FILLING) {
cancel_cpu_boost();
}

kugel, I am all for committing your latest patch. At least the data abort bug, which gets obvious with active AlbumArt, is fixed with this.

Well, given that the simple alignment correction fixes it for me too, I'm not sure if that's the correct fix.

I made it after your logic. If you think your logic is correct (or, rather at least more correct than what's in SVN), go ahead and commit it :)

I am all for the committing!