From: Charles Mason <charlie.mas_at_gmail.com>
Date: Thu, 16 Oct 2008 20:49:30 +0100

On Wed, Oct 15, 2008 at 5:27 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Wed, 15 Oct 2008, Magnus Holmgren wrote:
>
>> The address is the program counter, i.e., it refers to the instruction
>> that caused the abort. Grab the rockbox.map file for the build you're using.
>> That should give you an idea where the problem is (which function, with a
>> little luck). To get the exact location, I've used a disassembler on the
>> rockbox.elf file used to create the final binary, but I imagine a debugger
>> can be used too.
>
> When you've pinpointed the function name with the map file, you can objdump
> the object file (in which that function is located) to get the exact
> position of the crash.

After a lot of following the program counter in rockbox.map I
predictably traced it back to the load_tagcache function.

It turned out that my app wasn't fixing the tag entries to the length
4+(8xn) correctly. If the field is less than 4 chars long it didn't
fix it didn't pad out its length. Obviously that was causing the crash
during loading the DB to RAM as it wasn't of an expected length.

Regarding my original question about the first field in the master
index, I think my previous explanation of what that field actually
represents was correct. Well it seems to work and as far as I can tell
matches the field generated by Rock Box its self.

Thanks you all for the help.

Charlie M
Received on 2008-10-16