Clip Zip Divide by Zero 30083AC0

[ngoni]

I've been trying to use the development version for a few months, but after installation no matter what I'm doing a minute after boot I get a divide by zero crash:

"Divide by zero opc:30083AC0 sp:3bt end"

It always crashes at the same address. The release version works fine and I've tried with and without SD card inserted.

[gevaerts]

I'd try checking the filesystem for corruption

[ngoni]

Yeah I've tried that. I even formatted and reinstalled. Same error. 3.13 works just fine and has never crashed. I don't have the technical skills to trace down where this bug was introduced, but right now the development version is broken for the Clip Zip.

[dreamlayers]

I don't have any problems running recent versions on my Clip Zip. I also suspect that something in the file system is triggering a problem

"Divide by zero opc:30083AC0 sp:3bt end"

Unfortunately, that address is not helpful. It is probably in __udivdi3, which is a 64 bit division routine. The important address is the call to that routine, which is hopefully in the backtrace.

[saratoga]

Our divide by zero exception prints the address of the exception and not the caller ?

[ngoni]

I've formatted and reinstalled multiple times. Done windows chkdsk scanning for bad blocks and even ran iterations of Check Flash which found no problems:



I've got hundreds of hours on 3.13 with absolutely no problems so I really don't see this as a hardware problem. Thanks for the replies anyway. It would be nice to know where the crash is happening, would getting an emulator up and running inside of gdb be the best place to find it?

[dreamlayers]

Our divide by zero exception prints the address of the exception and not the caller ?

Both 64 and 32 bit division is implemented via a call to a GCC library function and not via an instruction. A 32 bit division by zero will show the address of the caller of the library function. The 64 bit division functions call 32 bit division functions, and the pc address is one of those calls.

"Divide by zero opc:30083AC0 sp:3bt end"

I just noticed the "bt end" there, meaning a backtrace was attempted but didn't succeed. The "sp:3" makes no sense though. Intentionally doing a division by zero on mine gives this:

Divide by zero a
pc:30083550 sp:3
bt end

The top two lines are truncated on the right. The pc value seems trustworthy.

One idea is saving the whole stack from the exception handler and doing a backtrace manually.

[mudlord]

Not sure if this is related, but I am using a Sansa Clip Zip with a Lexar 64GB microSD card.

I am able to easily reproduce crashes with a certain M4A file which works in other Windows music players and on 3.13 firmware but not the c3c2c91 git version.

The error message is:
Data abort at 30 FSR 0x8 (domain 0, fault address 0x50A813 pc 30007AA8 sp 3 bt end

I tried reformatting the microSD card, to no avail.

[saratoga]

Can you post a link to it?

[mudlord]

Its a commercial title so I suppose I can PM you a link.

[saratoga]

Thanks, this is reproducible for me on the Zip (but not on the Clip+) so its likely some sort of memory corruption problem.  I'll try and debug it when I get a chance.

[saratoga]

I think this is probably fair use for debugging purposes:

http://mit.edu/mgg6/www/buffering_crash.m4a

Crash is in buffering.c, find_handle if I have the objdump right. 

[dreamlayers]

I think this is probably fair use for debugging purposes:

http://mit.edu/mgg6/www/buffering_crash.m4a

Crash is in buffering.c, find_handle if I have the objdump right. 

I'm unable to reproduce this. I currently have f145660 installed on my Sansa Clip Zip and no MicroSD card. I played the track twice from the root directory in built-in storage, first time after disconnecting USB and second time after shutting down and starting back up. This is the build I'm using.

[saratoga]

Interesting.  Here is the build I'm using:

http://mit.edu/mgg6/www/rockbox-clipzip_map.7z

and its map:

http://mit.edu/mgg6/www/rockbox-clipzip.map

If it is memory corruption, it may be sensitive to small changes in the binary layout. 

[dreamlayers]

Interesting.  Here is the build I'm using:

http://mit.edu/mgg6/www/rockbox-clipzip_map.7z

There was no crash with that b130b50 build either. I wonder if some settings are causing it? I had no custom settings besides volume, and deleted config.cfg and restarted before this last test.