Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#11028 - r24657 breaks MIPS builds

Attached to Project: Rockbox
Opened by Maurus Cuelenaere (mcuelenaere) - Tuesday, 16 February 2010, 22:42 GMT+2
Last edited by Maurus Cuelenaere (mcuelenaere) - Monday, 22 February 2010, 00:00 GMT+2
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To Maurus Cuelenaere (mcuelenaere)
Player Type Another
Severity Medium
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

r24657 breaks MIPS-based players (Onda VX747, VX777) with an Address Exception (Store) in sab_process_dir()
This task depends upon

Closed by  Maurus Cuelenaere (mcuelenaere)
Monday, 22 February 2010, 00:00 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  In r24835.
Comment by Maurus Cuelenaere (mcuelenaere) - Tuesday, 16 February 2010, 23:37 GMT+2
I haven't figured this out yet, looks like this isn't an unaligned pointer problem but a NULL pointer dereference.

Assembly of crash at 0x8005BC84: http://pastebin.com/m2b403c87 (a0 contains 0x0).
For some reason the hardware says the referenced address is 0x140 while it should be (0x0+0x20) if I read the asm correctly..
Comment by amaury pouly (pamaury) - Tuesday, 16 February 2010, 23:57 GMT+2
Do you know to which line it corresponds on in the C code or do you have a way to know ?
Perhaps that's a fat_dir alignement problem due to the fact that it uses buffers that are probably manipulated by the fat code but I'm really not sure.
Could you also try with the next commit I did to dircache ? I finally move this fat_dir buffer to memory so this way we can make sure this is not an alignment problem.
Comment by Maurus Cuelenaere (mcuelenaere) - Wednesday, 17 February 2010, 18:53 GMT+2
> Do you know to which line it corresponds on in the C code or do you have a way to know ?

That's what I was trying to figure out yesterday, will look again today.

> Could you also try with the next commit I did to dircache ?

Crashes at the same instruction (it still looks like the CPU is accessing address 0x140, but I can't see why that happens..).
Comment by amaury pouly (pamaury) - Sunday, 21 February 2010, 12:56 GMT+2
Any progress concerning this bug ?
Comment by Maurus Cuelenaere (mcuelenaere) - Sunday, 21 February 2010, 21:50 GMT+2
> Any progress concerning this bug ?

Nope, sorry; haven't had much free time. I'll try looking at this today..
Comment by amaury pouly (pamaury) - Sunday, 21 February 2010, 23:56 GMT+2
I possibly solved the bug in r24835, I was doing a stupid NULL-pointer deference. That could explain this memory access to address 0x140 !
Could you try with this new commit ?
Comment by Maurus Cuelenaere (mcuelenaere) - Monday, 22 February 2010, 00:00 GMT+2
Yep, that seems to have fixed the issue! Thanks!

Loading...