Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Gareth - 2009-01-25
Last edited by Nils Wallménius - 2009-02-22

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

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.

Closed by  Nils Wallménius
2009-02-22 10:30
Reason for closing:  Fixed
Additional comments about closing:  

fixed in r20081

Admin
Frank Gevaerts commented on 2009-01-25 18:45

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

Paul Louden commented on 2009-01-25 19:51

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?

Alex Bennee commented on 2009-01-27 08:13

Which build tools did you use?

Thomas Martitz commented on 2009-02-08 16:50

I’m having a very similar issue, but the address is slightly different (0×9040).

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.

Marianne Arnold commented on 2009-02-08 21:55

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.

Alvin Chong commented on 2009-02-09 02:40

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

Toni commented on 2009-02-10 19:56

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.

Thomas Martitz commented on 2009-02-10 23:46

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.

Thomas Martitz commented on 2009-02-11 15:58

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?

Gareth commented on 2009-02-12 13:23

im assuming this is for the e200?

Thomas Martitz commented on 2009-02-12 15:13

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

Gareth commented on 2009-02-14 14:54

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.

Thomas Martitz commented on 2009-02-14 15:01

Delayed? How?

Toni commented on 2009-02-15 14:13

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 */

}

Thomas Martitz commented on 2009-02-15 14:15

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

Thomas Martitz commented on 2009-02-15 21:27

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).

Toni commented on 2009-02-16 20:32

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();
      }
Toni commented on 2009-02-21 16:17

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.

Thomas Martitz commented on 2009-02-21 16:18

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 :)

Nicolas Pennequin commented on 2009-02-21 17:38

I am all for the committing!

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing