Data abort on Sansa Clip+ with latest daily build

[Carlo]

I can confirm your modified build has completely solved the issue. Can I provide any further debugging help?

[Bilgus]

can you try these builds?
run this one for a few hours to see if this fixes the issue
https://gerrit.rockbox.org/r/c/rockbox/+/5150
^this was the only other potential bug I found in chunk_alloc and i'm not able to get it to fail in testing
so its just a guess

if that still crashes then please run this one short term
https://gerrit.rockbox.org/r/c/rockbox/+/5149

it should take about 2 minutes to run when you start a track from the file browser

it runs a test allocating random length strings in the chunk_alloc and checking their integrity
hopefully it causes a data abort if not I think we need to look elsewhere
maybe with what playlist.c is doing at the time

Or what is it doing with those strings some overrun??
They just appear to be indexed and copied so I'm still at a loss there

[Carlo]

Sure, I've compiled build 5150 (2f71430) and installed it on my daily driver. I'll keep you updated.

[Carlo]

Build 5150 (2f71430) is unstable for me. Pc of the latest crash is 30075094, this is my mapfile:

0x0000000030074fd0                font_cache_create
0x0000000030075074                font_cache_get
0x000000003007a160                browse_fonts

I'll compile 5149 later and give it a try.

[Bilgus]

it keeps coming back to this font code
I'll try disabling the dynamic name for the font next
I think there is something else going on unless the second patch
up there shows something crashy but I think it might just be uncovering a different bug

Thanks for testing BTW I haven't been able to reproduce any of this on my clip+

[Bilgus]

here is a patch disabling dynamic font names try this one if 5149 doesn't crash
https://gerrit.rockbox.org/r/c/rockbox/+/5151

[Carlo]

5149 doesn't crash for me, I've tried several times and the log always says "err:0, tests 500 longest..". I've tried it in various directories of different sizes and the number of errors is always 0.

I'll give 5151 a try shortly.

[Bilgus]

5149 basically fills the whole buffer with randomly sized strings and then checks their integrity
if we aren't getting any errors then nothing got corrupted in that test. It also allocates a second buffer at the same time
to try and cause issues.

so I don't think its the chunk_allocator causing the issue I think its just uncovering another bug

but I might be wrong..

[Carlo]

5151 (a70c0833..) crashes almost immediately too. Pc 300638c0, mapfile:

30063890 lcd_getstringsize
300638a4 lcd_init_viewport
30063920 lcd_set_viewport_ex

Let me provide a recap:

5147 - Good
5149 - No memory corruption
5150 - Crash after a few minutes
5151 - Crash in less than two minutes

I always triple-check that I'm actually running the intended build by comparing the version string from System -> Rockbox Info

[Bilgus]

Something is definitely up here i dont know what but could you give me a recap on your exact procedure for reproducing this?

Even down to the mundane..
Like i start at the main menu i go to files i choose a file in a directory of 25 files
It goes to the WPS i play a few songs in the WPS
Then i fast forward a few songs and skip back a song or two

I hit the back button it returns to the main menu
Then i go to the file browser and choose a new directory with 21 songs
I play a file and it crashes

OR
If you could and this is a big ask could you get a clean SD card and do an install there with like 10 songs
Or less and get a reproducible set of files based on the current
Dev version that you can get the bug reproduced on
And zip that up and upload it somewhere so i can see if I can reproduce it on my clip+

[Carlo]

My exact procedure is extremely simple:

Theme: Informative Beauty

- Turn on the Clip+;
- From the menu I choose "Files" -> "Music";
- Choose a directory at random, containing an average of 15-30 files;
- Start playing a file at random;
- Repeteadly skip to the next track from the WPS.

The crash happens as soon as I have skipped a few tracks. It never ever happened while playing a given track, only right after skipping to the next track. Moreover, the bug happens at random, there's no reliable way to trigger it, as it may happen after I have already skipped several times through the same tracks inside the same directory, e.g.:

- From the directory "dirname" containing 10 files I start playing the first one;
- From the WPS, I start skipping to file 2 -> file 3 -> file 4.. the crash happens here.
OR:
- From the WPS, I start skipping to file 2 -> file 3 -> file 4.. -> file 10, -> back to file 1 -> file 2.. crash.

I always play my files directly from the file browser, as I don't use bookmarks or the database. I'm using the internal Clip+ memory, not a SD card.

I'll try to identify a directory that happens to reliably trigger the bug and provide a zip, but again, the crashes may happen in less than one minute or even after almost one hour of usage.

[Carlo]

I'm uploading right now an archive that contains my .rockbox directory (build 5151, a70c0833e1) and two MP3 folders. This build is extremely unstable for me, latest crash had a pc of 3006298c:

300628fc  font_enable_all
30062968 font_get
300629c8 font_get_width

I will PM you shortly a GDrive link with the relevant files.

In order to reproduce the bug, simply go inside any one of the two directories with the file browser, start playing a file, then skip tracks, go to the other directory, start playing another file, skip tracks again, etc. This specific build crashes extremely quickly for me.

Edit: the build mapfile is available at https://drive.google.com/file/d/1fbFiezrTogO6yaGOozl8J_xXHOZ0RChn/view?usp=sharing

[Bilgus]

Ive run this build about 3 hours now with your songs and 0 crashes so far

are you able to copy to your other player and crash one of those?

have you tried running from the sd card to eliminate a storage problem?

finally if you can't repro on other players etc we can try upping the CPU voltage..

[Carlo]

I can reproduce it by skipping files on a known good SD card and on other players too. See attached screenshot.

Would the internal memory size be a triggering factor?

Edit: I can always quickly reproduce the crash on players with 8 gb of internal memory (with more than 7 gb being used).

Edit 2: the less free space on the player, the quicker the bug seems to be triggered. Skipping tracks as quickly as possible almost always triggers the bug for me.

[Carlo]

I can reproduce the bug ~80% of the times in less than one minute by doing the following:

- Turn on the Clip+;
- Start playing a random file from the browser as soon as possible;
- Skip forward tracks as quickly as possible from the WPS.

Those four players have 8 GB of internal memory with 7+ GB used and are running build 5151 with the Informative Beauty theme.

PC is either 3006298c or 300638c0.