Rockbox

FYI, I have reproduced this crash on the latest gigabeat simulator as well. So its probably not isolated to the X5. I generated the crash with the icatcher theme for example. But I think its really any theme with the next track info on the WPS.

updated to r16156-080124 on my x5 hardware and tested again, same issue remains

As you're able to reproduce on the sim, could you try to get a backtrace? It's quite easy, run the sim in gdb and when it crashes, enter 'bt' and paste the output here. I think I have an idea where the crash is, but I'd like to be sure.

Even better, could you perhaps attach your sim config (including WPS files, if it's a non-standard one), and an example MP3 here, so we can all repro...

updated to r16156-080124 on my x5 hardware and tested again, same issue remains

oops, sorry about the re-comment, i guess thats what a browser'refresh' gets you.

anyway, I think this problem is reproduceable with any WPS with next track info. Use the icatcher which is a default theme/wps.

i don't know what 'run the sim in gdb' means, can you explain how I do that, Thanks.


Steve,
extract the latest x5 sim and fonts to a folder, put some vbr mp3's in a folder and use that as a dynamic playlist, then try the steps above. You may have to play a couple before it bombs, but its pretty consistent.

OK, i just did this on a fresh x5 sim, so here is what I did.

SIM shows rockbox ver: r16179-080127
i reproduced the crash without extracting the fonts, but if you want the screen to look right extract those too.

i extracted the latest x5 sim: r16179-080127
i extracted the latest fonts
i put an album of vbr mp3 files in the sim folder
i ran the sim, selected the icatcher theme from the list of default themes
i browsed throught the files and played a track from the album making a dynamic playlist of the album
i did a long select, playlist, view current playlist, and played a different track and returned to the wps with 'play' or 'prev'(which works fine once it seems).
i did a long select, playlist, view current playlist, and played a different track and returned to the wps with 'play' or 'prev', BOOM, the sim throws an illegal operation in Windows.(on my hardware x5, it just freezes and only responds to a long power off).

I attached the text info generated by the windows crash. I've reproduced this on the gigabeat sim as well and with different sets of vbr mp3's from different sources.

>> i don't know what 'run the sim in gdb' means, can you explain how I do that, Thanks.

At a shell prompt, go into your build directory (where rockboxui.exe lives), and type the following command:
gdb rockboxui.exe

At the (gdb) prompt, type:
run

You should see ths simulator appear. Now make it crash. The gdb/shell window should display some useful information and return to a (gdb) prompt. Type
bt

This will give more useful info. Please post back with all of the gdb output here.

I've tried to reproduce this (on an X6 sim with default settings + iCatcher), but it won't misbehave - could you perhaps put some example MP3s up?

Steve,
I don't have gdb, its not part of the x5 simulator standard files. Is gdb a linux app? I have a windows PC so I don't have gdb. I'm just unzipping the x5 simulator files to a windows pc.
Did you try the x5 sim crash procedure I described on a windows PC? Try that. Also you said x6 sim, did you mean x5? I'll see about posting some sample mp3 files, I may have to cut them to make sure i'm not violating copyrights.

Hi Jim,

I am running under Windows, using Cygwin to build the simulator. Have a look at http://www.rockbox.org/twiki/bin/view/Main/CygwinDevelopment for details, it's pretty quick to set up.

I've tried your recipe, but it always goes back to the WPS just fine, with the correct next song displayed.

I have some more clues, may or may not be helpfull. When trying to generate truncated vbr sample mp3's I found some interesting results.
The truncated mp3 files(20 sec.) would not crash the simulator. Even when I added tags. But a 30sec. vbr mp3 would crash it. Just a tagless mp3 file encoded with lame 3.97 with the -V2 option.

after testing almost every combination of 128,192,256,vbr mp3 files with and without tags, my summary recipe for generating the crash is:

playlist browse to a vbr mp3(any length) with id3 tag and play, then:
playlist browse to another vbr mp3 at least 30 seconds long (tags or no tags) and play, BOOM.

OR

playlist browse to vbr mp3(any length) with id3 tag and play, then:
playlist browse to any untagged mp3 at least 30 seconds long and play, BOOM.


I am attaching some sample mp3 files so you can try it yourself:

put these files into an 'mp3crash' folder on your simulator.
make a copy of vbr-tagged-30sec.mp3 called vbr-tagged-30sec-2.mp3(was saving space on the post)
from the sim, select the icatcher theme
from the sim, file browse to the mp3crash files and play cbr128-30sec.mp3(just to queue all the samples)
from the WPS, long select, playlist, view current playlist
browse to vbr with id3 tag(vbr-tagged-30sec.mp3) and play(return to wps screen)
from the WPS, long select, playlist, view current playlist
browse to another vbr at least 30 seconds long(vbr-tagged-30sec-2.mp3) (tags or no tags) and play, return to WPS, BOOM.

also test using this method going from the tagged vbr to the untagged cbr 128 included which should also crash.

Good work, but that zip file appears to be corrupted.

trying the attachment again with pkzip this time instead of windows xp zip. if this doesn't work, i may have to try from another network

ok, sorry this one shouldn't be corrupt, the first 2 were, something on that proxy server i guess.

this is getting tiresome, something in the upload on this site is corrupting the zip, trying straight mp3 files

I followed your recipe, but it didn't crash on return to the WPS. However, when I went back into View Current Playlist playing track 3, the marker was by track 1. Selecting track 1 and returning to the WPS then crashed. gdb output is:
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3148.0x490]
0x0042802a in evaluate_conditional (gwps=0x59dbc0, token_index=0x264fc64)
at gui/gwps-common.c:1408
1408 intval = (value && *value) ? 1 : num_options;
(gdb) bt
#0 0x0042802a in evaluate_conditional (gwps=0x59dbc0, token_index=0x264fc64)
at gui/gwps-common.c:1408
#1 0x00428634 in get_subline_timeout (gwps=0x59dbc0, line=13, subline=0)
at gui/gwps-common.c:1596
#2 0x004287de in update_curr_subline (gwps=0x59dbc0, line=13) at gui/gwps-common.c:1669
at gui/gwps-common.c:1926
#4 0x0042613c in gui_wps_display () at gui/gwps-common.c:345
#5 0x004257da in gui_wps_show () at gui/gwps.c:663
#6 0x00417a40 in wpsscrn (param=0x0) at root_menu.c:242
#7 0x00417e6a in load_screen (screen=2) at root_menu.c:465
#8 0x00417dfd in root_menu () at root_menu.c:575
#9 0x00404ce5 in app_main () at main.c:130
#10 0x00461f92 in thread_sdl_app_main (param=0x0) at thread-sdl.c:106
#11 0x6810a2ec in SDL_strtod () from /home/Steve/rockbox/buildsim/SDL.dll
#12 0x00000000 in ?? ()
(gdb) print value
$1 = 0x3000100 <Address 0x3000100 out of bounds>

I suspect this is the same problem as the off-by-one bug that's causing other issues where the last track in a playlist won't play. Some piece of code is interpreting the "current track" to mean the currently decoding track, not the current WPS track maybe?

I tried this formula again on the latest x5 simulator: r16192 with the exact same results. I have attached a gif image of all of my testing results. I can reproduce this consistently on multiple computers with the x5 simulator(varying recent versions) and also on my hardware x5(which freezes and has to be power cycled). I havent tried all of those permutations on the gigabeat sim but I think it has the same results. Oddly the IPOD sim seems to be more robust and does not crash consistently though it does periodically if you keep trying long enough. But I havent been able to crash my friends IPOD hardware at all with this recipe.

I have a WPS work-around for this but i would think this would be a widespread problem worth fixing. My workaround is to make the WPS flip into the next track info instead of having next track instantly showing. This effectively fixes the problem and I just have to put up with a 1sec. flash of ... every 20 sec or so. :)

This patch is a workaround. It prevents the player from crashing. Maybe a developer should look at it and find out why there is sometimes just crap in audio_next_track()->path when the track is changing.

It fixes my problem reported on  FS#8584 .