Rockbox

Tasklist

FS#9827 - Rockbox data Abort at 000090D0 (0)

Attached to Project: Rockbox
Opened by Gareth (Mystic_kitsune) - Sunday, 25 January 2009, 18:38 GMT
Last edited by Nils Wallménius (nls) - Sunday, 22 February 2009, 10:30 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

rockbox aborts at the address 000090D0 (0) with build 19852 while playing any music file, the buffers all fill synchronously and the abort happens after they all fill.
This task depends upon

Closed by  Nils Wallménius (nls)
Sunday, 22 February 2009, 10:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in r20081
Comment by Frank Gevaerts (fg) - Sunday, 25 January 2009, 18:45 GMT
000090D0 seems to be in add_handle() in apps/buffering.c
Comment by Paul Louden (Llorean) - Sunday, 25 January 2009, 19:51 GMT
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?
Comment by Alex Bennee (ajb) - Tuesday, 27 January 2009, 08:13 GMT
Which build tools did you use?
Comment by Thomas Martitz (kugel.) - Sunday, 08 February 2009, 16:50 GMT
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.
Comment by Marianne Arnold (pixelma) - Sunday, 08 February 2009, 21:55 GMT
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.
Comment by Alvin Chong (direcow) - Monday, 09 February 2009, 02:40 GMT
My error reads "Data Abort at 0000A634 (0)", if it helps.
Comment by Toni (ahellmann) - Tuesday, 10 February 2009, 19:56 GMT
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.
Comment by Thomas Martitz (kugel.) - Tuesday, 10 February 2009, 23:46 GMT
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.
Comment by Thomas Martitz (kugel.) - Wednesday, 11 February 2009, 15:58 GMT
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?
Comment by Gareth (Mystic_kitsune) - Thursday, 12 February 2009, 13:23 GMT
im assuming this is for the e200?
Comment by Thomas Martitz (kugel.) - Thursday, 12 February 2009, 15:13 GMT
The task is initially about the e200. c200 seems to be affected too. The patch I added is target independent at all.
Comment by Gareth (Mystic_kitsune) - Saturday, 14 February 2009, 14:54 GMT
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.
Comment by Thomas Martitz (kugel.) - Saturday, 14 February 2009, 15:01 GMT
Delayed? How?
Comment by Toni (ahellmann) - Sunday, 15 February 2009, 14:13 GMT
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 */
}
Comment by Thomas Martitz (kugel.) - Sunday, 15 February 2009, 14:15 GMT
Gareth, can you please be more specific about your recent report? It doesn't really help me.
Comment by Thomas Martitz (kugel.) - Sunday, 15 February 2009, 21:27 GMT
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).
Comment by Toni (ahellmann) - Monday, 16 February 2009, 20:32 GMT
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();
}
Comment by Toni (ahellmann) - Saturday, 21 February 2009, 16:17 GMT
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.
Comment by Thomas Martitz (kugel.) - Saturday, 21 February 2009, 16:18 GMT
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 :)
Comment by Nicolas Pennequin (nicolas_p) - Saturday, 21 February 2009, 17:38 GMT
I am all for the committing!

Loading...