Rockbox

Tasklist

FS#12684 - Any daily build for the Sansa Clip Zip from after the 2nd of May fatally crashes

Attached to Project: Rockbox
Opened by John Uren (johnuren1980) - Wednesday, 23 May 2012, 22:38 GMT
Last edited by MichaelGiacomelli (saratoga) - Saturday, 02 June 2012, 22:02 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System Sansa AMSv2
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Any build after the 2nd of May (e189b33 and after) won't boot after creating a database on the Sansa Clip Zip.

For completeness, this is what I do after installing Rockbox:
Boot
Select "Database"
Select the option to build a database (because you want to have a database of your music on your device)
Wait for database to build
Select database (pop-up of "Please reboot to enable")
Power off device (pop-up of "Shutting down...")
Power on device
Receive a fatal crash and never be able to boot the device to Rockbox again.

What follows is what is on the screen when Rockbox crashes:

*PANIC*
audio_reset_buffer_noalloc()
: EOM (65536 > 0)
bt pc: 0x3003DD6
A: 0x3003DDE
A: 0x3003DE4
A: 0x3001890
A: 0x30018DA
A: 0x3000866
This task depends upon

Closed by  MichaelGiacomelli (saratoga)
Saturday, 02 June 2012, 22:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  This specific problem is reported fixed. If there are more related issues beyond the voice buffer allocation problem, please open a new task for each of them.
Comment by Michael Sevakis (MikeS) - Thursday, 24 May 2012, 04:11 GMT
It's sort of an "out of memory" by audio but overly-severe treatment of it. Sure it's the build date and not just a huge database and/or alot of optional stuff enabled?
Comment by John Uren (johnuren1980) - Thursday, 24 May 2012, 06:49 GMT
No optional stuff enabled. Rockbox is as it comes from the build (as I have to re-enable Timestretch every time to listen to podcasts at >100% speed and not listen to chipmunks).

Database is of 195 files, mostly flac files but a few mp3s. Total of about 5GB (in an 8GB Clip Zip. No SD card installed).

I am reasonably sure it's the build date as I tried every daily build after the 2nd of May and all of them show the same error.

I have not tried builds before the 1st May (except one but I can't remember which).

I will try earlier builds later today and report on their crashiness after making a database.

If I don't make a database, everything else works OK AFAICT.
Comment by MichaelGiacomelli (saratoga) - Thursday, 24 May 2012, 08:15 GMT
Can you go to system > debug > buffering and report the values for the first 4 lines (pcm and below)? Should let you know how much memory is actually allocated.
Comment by Bertrik Sikken (bertrik) - Thursday, 24 May 2012, 16:36 GMT
One of the builds from today (May 24) works for me, starting with a completely new .rockbox folder.
Comment by John Uren (johnuren1980) - Thursday, 24 May 2012, 18:46 GMT
No optional stuff enabled. Rockbox is as it comes from the build (as I have to re-enable Timestretch every time to listen to podcasts at >100% speed and not listen to chipmunks).

Database is of 195 files, mostly flac files but a few mp3s. Total of about 5GB (in an 8GB Clip Zip. No SD card installed).

I am reasonably sure it's the build date as I tried every daily build after the 2nd of May and all of them show the same error.

I have not tried builds before the 1st May (except one but I can't remember which).

I will try earlier builds later today and report on their crashiness after making a database.

If I don't make a database, everything else works OK AFAICT.
Comment by John Uren (johnuren1980) - Thursday, 24 May 2012, 18:47 GMT
Sorry for the repost, my error.

In answer to the questions

With 2nd May build:
pcm: 0/5242

With 24th May build:
pcm : 0/0

Today's build has the same issue as reported.
Comment by John Uren (johnuren1980) - Thursday, 24 May 2012, 19:18 GMT
All builds work up until 2nd May.

Misread earlier question so what follows is the buffer info for the builds of 2nd, 3rd and 24th May.

2nd May:

pcm: 0/5242
alloc: 0/59
real: 0/59
usefl: 0/59

3rd May:

pcm: 0/0
alloc: 0/0
real: 0/0
usefl: 0/0

24th May:

pcm: 0/0
alloc: 0/0
real: 0/0
usefl: 0/0
Comment by MichaelGiacomelli (saratoga) - Thursday, 24 May 2012, 19:20 GMT
Sorry, you need to be actually playing (or at least have played and then paused) music. Just the 24 May build is enough.
Comment by John Uren (johnuren1980) - Thursday, 24 May 2012, 19:28 GMT
pcm: 507904/5242
alloc: 5926239/59
real: 5925615/59
usefl: 5269019/59
Comment by MichaelGiacomelli (saratoga) - Thursday, 24 May 2012, 19:39 GMT
I'm not expert on these things, but if the player thinks the audio buffer is only 59 bytes (and of those 59 bytes its used about 6 million of them), I think something has been terribly corrupted.

I don't suppose its this specific commit that stops working? http://git.rockbox.org/?p=rockbox.git;a=commit;h=da6cebb Was committed late on May 2 and touches the buffering code.
Comment by John Uren (johnuren1980) - Thursday, 24 May 2012, 19:45 GMT
I may be incorrectly reporting the available memory as the screen is small and may not be displaying all the numbers.
Comment by MichaelGiacomelli (saratoga) - Thursday, 24 May 2012, 19:47 GMT
Heh, so those numbers probably aren't correct? Might be nice to mention up front before i go trying to figure out what they mean :)
Comment by John Uren (johnuren1980) - Thursday, 24 May 2012, 20:00 GMT
Here is what the screendump shows
Comment by Michael Sevakis (MikeS) - Thursday, 24 May 2012, 21:55 GMT
"5242" should be "524288", so yeah, I'd say it's just cut off. It also shouldn't be an issue for the buffering itself if it hasn't been initialized yet, so the zero counts are nothing unusual if playback hasn't started.
Comment by Bertrik Sikken (bertrik) - Saturday, 26 May 2012, 11:57 GMT
If this is just a "normal" bug and not some kind of corruption, I wonder if we can duplicate it in the simulator, perhaps with the config file that John is using?
Also, can you post the exact build version (git hash) that corresponds to the *PANIC* message?
Comment by John Uren (johnuren1980) - Sunday, 27 May 2012, 20:21 GMT
I am not using any custom config file AFAIK. I am using rockbox "as built". For each build, I am deleting and adding the .rockbox folder.

Simulator? Is this the simulator compilers that are in the Ubuntu VM?
Comment by MichaelGiacomelli (saratoga) - Sunday, 27 May 2012, 20:30 GMT
Ubuntu can run the simulator. So can windows if you prefer that.
Comment by Bertrik Sikken (bertrik) - Sunday, 27 May 2012, 21:11 GMT
Still can't reproduce here, so there must be something different between your setup and mine, for example in the config file, or in the audio files.

Ok, correction:
I *can* reproduce it, but only when using RockboxUtility to install rockbox, it doesn't happen when I just unzip the result of 'make zip' when built from source. I suspect some voice-related stuff.
Also, the backtrace screen is mostly useless on the clip zip, it misses the last digit of the address, I guess we can skip the "0x" prefix.

Decoding the backtrace, I get:
playback.c: 827 - panicf("EOM"...) in audio_reset_buffer_no_alloc()
playback.c: 921 - audio_reset_buffer_no_alloc() in audio_reset_buffer()
playback.c: 3679 - audio_reset_buffer() in audio_restore_playback()
talk.c: 629 - audio_get_buffer() in restore_state()
talk.c: 786 - restore_state() in talk_id()
main.c:305 - talk_number() in init_tagcache()

I'm suspecting commit da6cebb6b0b17b4a75a2bd4f51b7cf70b5dafe40 ("Use buflib for the allocation of voice PCM resources.") now
Comment by John Uren (johnuren1980) - Sunday, 27 May 2012, 22:57 GMT
Ok. It is probably not my config but my trash folder. I had some corrupted files that Nautilus (and Windows) wouldn't remove in my .Trash-1000 folder. This may be causing the instabilities. Formatting the device and re-running the installation has deleted them. Adding a few mp3 files and running the database initialisation hasn't caused any fatal panics so far.
Comment by Bertrik Sikken (bertrik) - Monday, 28 May 2012, 18:53 GMT
I put a panic on the result of core_alloc_maximum in playback.c: audio_reset_buffer and it returns -1 and this panic fires. Next thing I'll try is to put audio_init before tagcache_init in main.c
Comment by Bertrik Sikken (bertrik) - Monday, 28 May 2012, 19:48 GMT
The problem appears to be that during the database commit at startup of rockbox, the database and the voice menu systems are competing for memory, so one of them cannot get any memory allocated. I don't know the exact fix yet, but in the meantime you can try to disable voice menus (under settings / general settings). To recover from the bootloop, you can insert the USB plug and then hold the LEFT/PREVIOUS button until it boots to the original firmware and delete any .tcd files from the .rockbox directory.
Comment by Michael Sevakis (MikeS) - Tuesday, 29 May 2012, 17:42 GMT
I would just remove the voicing at that point for now (#if 0). It's done before audio (and the hardware) is initialized anyway and I can't see how it could even ever have worked unless it used to be done later , after audio init.
Comment by Michael Sevakis (MikeS) - Wednesday, 30 May 2012, 22:49 GMT
I just disabled the talking in init_tagcache for now in ba8e436. Any success?
Comment by Zhan Shi (coredumpling) - Friday, 01 June 2012, 21:08 GMT
I'm not the original reporter, but I had this issue earlier on the Sansa Clip v1 and even isolated it to the same commit da6cebb.

I compiled the latest HEAD (currently running dce80ea) and cannot reproduce the problem anymore. Presumably the latest patches have fixed the issue.

Loading...