Rockbox

after reboot the database seems to work properly

Thanks for the bug report!

The panic message seems to hint at a stack overflow in the dircache thread. (The directory cache is temporarily disabled during the database commit, and reloaded afterwards.)

Is the crash reproducible after each database update or reinitialization? If so, please list the exact steps. Could you please double-check that you cannot reproduce the behavior (with the same steps) with r30058? There have been no dircache changes since then… Maybe you just haven't rebuilt or updated your database for some time.

where do I get an older build?

I've just tested the newest build and it crashed on reinitialization with a stack overflow.
The crash is not always the case. Sometimes it just stops scanning the disk at 78% and then the player isn't responding any more.

nervermind... i've found the old releases archive :-)

r30058 crash

r30052 works

I've tested the daily versions, so no test of r30052...r30057

no that's weird, I've tested r30058 again and now it worked. so the bug is not reproducable.

I just ran into this myself on a FuzeV2, with a r30091-based build.

I guess disabling dircache (in system settings → disk) is a safe workaround until this is fixed.

Changing the bug category -- this is likely not a database bug, but happens when the dircache is reloaded after the updated database has been committed.

If you can still reproduce the issue: Please retry with a recent build. Revision r30122 contains an important dircache fix that may have caused the problem.

I think the issue is gone. I can't reproduce the crash any more.

now its a data abort at 0004CE24 (0)

r30122

there is a database_tmp.tcd in the .rockbox directory that is normally not there

This looks like it's an unrelated issue, likely in the database (given that the database_tmp.tcd file still existed).

Could you please check which function corresponds to address 4CE24 in your build? The rockbox.map file in your build directory will be of help.

If this is address is not related to the dircache, please open a new Flyspray task and repeat all relevant information there.

I used the official r30122 build downloaded from the rockbox build server, so I don't have a map file available. If I have time after work I will build the firmware at home and check the map file.

In the end I've found the time to build the r30122 revision. According to the map file the crash occured in the function tagcache_search.

Did you actually reproduce the crash with your own build? I'm asking because just comparing addresses between two builds is nearly worthless even when building identical versions because minor differences in the build environment (compiler and linker versions) may cause link addresses to vary wildly.

I could not reproduce a crash since then.