This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12429 - Fuze+: playback failures (data aborts/undef instr/etc) with several codecs
Attached to Project:
Rockbox
Opened by Jean-Louis Biasini (JeanLouisBiasini) - Monday, 05 December 2011, 18:29 GMT+2
Last edited by Andree Buschmann (Buschel) - Sunday, 11 December 2011, 17:34 GMT+2
Opened by Jean-Louis Biasini (JeanLouisBiasini) - Monday, 05 December 2011, 18:29 GMT+2
Last edited by Andree Buschmann (Buschel) - Sunday, 11 December 2011, 17:34 GMT+2
|
DetailsSeveral problem occurs with those format on Fuze+'s port. The problem has been identified as player specific as it doesn't occurs on clip+ and has been seen on 2 differents Fuze+ unit.
The problem are quite random which lead to difficulties to track them down precisely. Nevertheless, 3 differents phases can be observe regarding the behaviour of the fuze+ and mpc files: - Normal behaviour (files can be selected, play, playlist also play without problem) - Non-playing behauviour (files are skipped one after the other till the end of the dynamic play list) -- Nothing consistent was found on how to go from normal into non-playing behaviour or reverse. - Buggy behaviour (you can actually play and skip between files but after playing one file, the player will just hang stucked or go into panic at the moment to load the next one: Two different value set were observed for now (backtrace remains the same): Data abort at 63E57B28 FSR 0x8 (domain 0, fault 8) address 0x64000000 backtrace start A: 0x63E56AE8 A: 0x60040D28 A: 0x6003D87C A: 0x6003DB50 backtrace end or: Data abort at 63E57B24 FSR 0x8 (domain 0, fault 8) address 0x64000001 backtrace start A: 0x63E56AE8 A: 0x60040D28 A: 0x6003D87C A: 0x6003DB50 backtrace end Several tests were made so far to establish that: 1) The problem is not files specific as normal behaviour and non-playing and buggy behaviour occurs on the same sets of files. Differents tag coding and even wiping all the tag away didn't help either. 2) The problem is not related to database as not building it and/or erasing all DB files doesn't wipe out the buggy behaviour. 3) The problem ist not be related to specific settings or if so, it is related to defaut settings. Recompiling, reinstalling rockbox from scratch doesn't solve the buggy behaviour 4) Nothing consistent was found about how the player goes from normal to non-playing or reverse. However some consistent (systematical) way to go from non-playing to buggy phase was found: - Reinitialize the database (wether if there are no DB or an already present up-to-date one). But the player will then be back on non-playing phases after reboot. - Playing a big directory with a lot of files after skipping 20 to 50 of then the player will eventually start playing one of then (a random one nothing consistent here to) - desactivating the directory's cache option (settings > system > disk) this way is the only way to remains even after reboot. 5) the backtrace of panic occuring in buggy behaviour was given into the ./utils/analisys/find_address.pl tool with the following result: https://gist.github.com/1434466 6) Flac format as been seen with the same non-playing behviour. But buggy phases gave no backtrace: Data abort at 63E71120 FSR 0x1 (domain 0, fault 1) address 0x00004D6B |
This task depends upon
Closed by Andree Buschmann (Buschel)
Sunday, 11 December 2011, 17:34 GMT+2
Reason for closing: Fixed
Additional comments about closing: The MPC sv7 crash is fixed with r31211, flac crash is fixed with r31207 (enlarged MAX_FRAMESIZE).
The undefined instruction and the dircache influence will be handled in separate tasks.
Sunday, 11 December 2011, 17:34 GMT+2
Reason for closing: Fixed
Additional comments about closing: The MPC sv7 crash is fixed with r31211, flac crash is fixed with r31207 (enlarged MAX_FRAMESIZE).
The undefined instruction and the dircache influence will be handled in separate tasks.
https://gist.github.com/1434486
Do you use other formats as well? To me this does not sound like a mpc or flac related issue, but like a general code playback issue.
The 0x63E57B28 and 0x63E57B24 data aborts are where values are loaded from r->buff[] in mpc_bits_read() at:
ret = (r->buff[0] | (r->buff[-1] << 8)) >> r->count;
It is found in mpc_bits_reader.h and inlined right after the first mpc_demux_fill() call in the d->si.stream_version <= 7 branch of mpc_demux_decode_inner(), which is inlined within mpc_demux_decode(). The start of the backtrace is the call of mpc_demux_decode() from codec_run(). It's interesting that the failing data accesses are just past the end of RAM.
The FLAC data abort at 0x63E71120 is weird. It is past the end of .bss, and it doesn't seem like FLAC uses codec_malloc().
Another thing is that when rather than going into panic the player just hang, although the bug occurs at the end of the file, it shows a WPS with the progress bar on the 1/6 of the file.
For a link to the forum : http://forums.rockbox.org/index.php/topic,26284.msg186784.html#msg186784 and following thread of the same user.
The backtrace algorithm examines both the stack and code. If the code jumps somewhere crazy, I don't expect to get a backtrace. There, FLAC is executing code from past the end of .bss. I don't see anything that would put code there, so it seems PC shouldn't be in that area. There is probably some memory corruption. (BTW. Stack corruption can also cause backtrace to fail.)
Severity is high, because the impact of the failure itself is high. We could lower the priority of course.
Undefined instruction at 0000AC44
backtrace start
pc: 0x0000AC44
sp: 0x00005350
backtrace end
find_addr.pl returns:
jean-louis@debian:~/Bureau/rockbox-devtree/rockbox/buidl$ ../utils/analysis/find_addr.pl 0x0000AC44 1
/home/jean-louis/Bureau/rockbox-devtree/rockbox/buidl/firmware/libfirmware.a(thread.o) -> threads
jean-louis@debian:~/Bureau/rockbox-devtree/rockbox/buidl$ ../utils/analysis/find_addr.pl 0x00005350 1
/home/jean-louis/Bureau/rockbox-devtree/rockbox/buidl/apps/codec_thread.o ->