Details

I've been working on PictureFlow - WPS Integration. I repeatedly had cases where showing a tracklist or playing for certain albums would cause a segfault. I tracked this down to a bug in the track list indexing. It only occurs under certain memory allocation circumstances that doesn't occur as readily with the std build. I have attached here a patch to fix it.

Explanation: the create_track_index requests memory for building a track index. The variable "tracks" references an array descending from the buffer top end. When a reallocation occurs it currently only moves the "tracks" position when a track count > 0. However, in some cases a reallocation occurs before the first track is stored and in that case the "tracks" position gets left in the middle of the track_names data causing corruption and then segfault. I've moved the (track_count > 0) decision so that it only controls moving tracks struct data. The "tracks" offset must happen even when track_count is 0.

This patch fixes the segfault on my Sansa Fuze v2 and in UISim. Tested against r26114.
I would expect the same result in other platforms.

I've also included this bug fix in my PictureFlow - WPS Integration patch until this bug fix gets accepted.

I still get a few crashes...
this occurs on a random Album,
the first time I access the Track list, it only shows me the Album Name with an empty track list and freezes.
I reboot, and go again to the same Album and try to access the Track list but it crashes right away showing me the following error:

Data abort
at 300525F0
FSR 0x8
(domain 0, fault 8)
address 0xE4543014

I press a button and it reboots....after that I can access the Tracklist and no more crashes.

I'm not getting that on mine. I checked the address 300525F0 in the map file and it may be in the firmware threading code (wakeup_priority_protocol_transfer) - I don't know how this interacts with pictureflow.
I think I have seen this before but not recently.
I think that rebuilding the tag database and then the album cache in pictureflow made it go away.

This time after rebuilding the cache I got a crash without having the usual first time freeze.
Same thing as before, when trying to access the track list.
After this crash no more crashes until I rebuild the the cache again.
I don't know if it is related but I use as3525v2-cpufreq-v10 patch. http://www.rockbox.org/tracker/task/11297

Data abort
at 30781130
FSR 0x8
(domain 0, fault 8)
address 0x5ECCBB8C

While "Preparing album artwork" it also says once "could no read bmp".

It may be connected with or aggravated by the v10 patch. I'm not using that and haven't had crashes recently (since my patch here).
It could also be there is another bug in there and it's not evident unless v10 is present.
After my current work I may try out v10 with pictureflow and see if I can find something wrong.