FS#10492 - Data abort error

Attached to Project: Rockbox
Opened by Sabrena (aetaslupus) - Friday, 07 August 2009, 00:31 GMT
Last edited by Magnus Holmgren (learman) - Monday, 07 September 2009, 19:46 GMT
Task Type Bugs
Category Codecs
Status Closed
Assigned To No-one
Operating System iriver H10
Severity Low
Priority Normal
Reported Version Version 3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Data Abort at 01E8DD28

This error message only applies to ogg vorbis files, the player completely freezes up and I have to hit the reset button to play any of my music.
This task depends upon

Closed by  Magnus Holmgren (learman)
Monday, 07 September 2009, 19:46 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r22653.
Comment by MichaelGiacomelli (saratoga) - Friday, 07 August 2009, 20:19 GMT
Can you upload a file that has this behavior?
Comment by Sabrena (aetaslupus) - Saturday, 08 August 2009, 15:01 GMT
This is the main file I tested and found the problem with but I have tried other ogg vorbis files and found the same issue.
Comment by Magnus Holmgren (learman) - Sunday, 09 August 2009, 13:33 GMT
I have a file with a similar problem. In both cases, the crash is in floor1.c (in the simulator). For the above file, the crash is a segfault in render_line (though I couldn't easily see in the debugger exactly what caused the segfault), in "my" file, it is a division by zero in render_point (due to x0 and x1 being zero). In both cases, it could be caused by incorrect creation of or reading from info->postlist...

Tremor SVN from July 2009 works fine. Reverting the changes in render_point makes no difference.
Comment by Magnus Holmgren (learman) - Sunday, 30 August 2009, 07:07 GMT
I tested again with (a custom build of) r22540 and that worked fine. Would be nice to know why it worked now though...
Comment by Dave Hooper (stripwax) - Monday, 31 August 2009, 18:09 GMT
The crash (on sim at least) for that file appears to be due to accessing array out of bounds. In particular, the x and y values in render_line look totally wrong, and cause us to try and access invalid elements of the output buffer and/or the fromdB lookup. Definitely looks like a packet is mis-decoded and we try and render garbage.
Comment by Magnus Holmgren (learman) - Tuesday, 01 September 2009, 18:24 GMT
Based on a message on the mailing list, I tested simulator builds of 3.2 and 3.3. 3.2 works, 3.3 fails, so that points to  FS#9882 .

(Edit) Additional note: iram_pcm_doublebuffer (in block.c) is false for the failing files.
Comment by Sei Aoyumi (Aoyumi) - Thursday, 03 September 2009, 12:25 GMT
I made the patch which revised this problem. In addition, this patch keeps the memory allocation of the (1st) PCM buffer simple form than before.
Comment by Magnus Holmgren (learman) - Thursday, 03 September 2009, 19:05 GMT
Thanks. That works for my test tracks on an e200, and the above file in the simulator.