Rockbox.org home
Downloads
Release release
Dev builds dev builds
Extras extras
themes themes
Documentation
Manual manual
Wiki wiki
Device Status device status
Support
Forums forums
Mailing lists mailing lists
IRC IRC
Development
Bugs bugs
Patches patches
Dev Guide dev guide
Search



Donate

Rockbox Technical Forums


Login with username, password and session length
Home Help Search Staff List Login Register
News:

Thank You for your continued support and contributions!

+  Rockbox Technical Forums
|-+  Support and General Use
| |-+  Hardware
| | |-+  Clip Zip Divide by Zero 30083AC0
« previous next »
  • Print
Pages: [1] 2

Author Topic: Clip Zip Divide by Zero 30083AC0  (Read 6563 times)

Offline ngoni

  • Member
  • *
  • Posts: 3
Clip Zip Divide by Zero 30083AC0
« on: April 11, 2015, 11:55:21 AM »
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.
Logged

Offline gevaerts

  • Administrator
  • Member
  • *
  • Posts: 1062
Re: Clip Zip Divide by Zero 30083AC0
« Reply #1 on: April 11, 2015, 02:25:34 PM »
I'd try checking the filesystem for corruption
Logged

Offline ngoni

  • Member
  • *
  • Posts: 3
Re: Clip Zip Divide by Zero 30083AC0
« Reply #2 on: April 11, 2015, 05:30:39 PM »
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.
Logged

Offline dreamlayers

  • Developer
  • Member
  • *
  • Posts: 425
  • Boris Gjenero
    • My Blog
Re: Clip Zip Divide by Zero 30083AC0
« Reply #3 on: April 12, 2015, 11:44:19 PM »
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

Quote from: ngoni on April 11, 2015, 11:55:21 AM
"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.
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 9136
Re: Clip Zip Divide by Zero 30083AC0
« Reply #4 on: April 13, 2015, 09:02:22 AM »
Our divide by zero exception prints the address of the exception and not the caller ?
Logged

Offline ngoni

  • Member
  • *
  • Posts: 3
Re: Clip Zip Divide by Zero 30083AC0
« Reply #5 on: April 13, 2015, 10:14:37 PM »
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?
Logged

Offline dreamlayers

  • Developer
  • Member
  • *
  • Posts: 425
  • Boris Gjenero
    • My Blog
Re: Clip Zip Divide by Zero 30083AC0
« Reply #6 on: April 14, 2015, 12:42:02 AM »
Quote from: saratoga on April 13, 2015, 09:02:22 AM
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.

Quote from: ngoni on April 11, 2015, 11:55:21 AM
"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:
Quote
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.
Logged

Offline mudlord

  • Member
  • *
  • Posts: 3
Re: Clip Zip Divide by Zero 30083AC0
« Reply #7 on: April 22, 2015, 08:58:18 PM »
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.
« Last Edit: April 23, 2015, 09:21:11 AM by mudlord »
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 9136
Re: Clip Zip Divide by Zero 30083AC0
« Reply #8 on: April 22, 2015, 11:31:26 PM »
Can you post a link to it?
Logged

Offline mudlord

  • Member
  • *
  • Posts: 3
Re: Clip Zip Divide by Zero 30083AC0
« Reply #9 on: April 23, 2015, 09:09:18 AM »
Its a commercial title so I suppose I can PM you a link.
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 9136
Re: Clip Zip Divide by Zero 30083AC0
« Reply #10 on: April 23, 2015, 12:35:11 PM »
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.
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 9136
Re: Clip Zip Divide by Zero 30083AC0
« Reply #11 on: April 23, 2015, 01:25:11 PM »
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. 
Logged

Offline dreamlayers

  • Developer
  • Member
  • *
  • Posts: 425
  • Boris Gjenero
    • My Blog
Re: Clip Zip Divide by Zero 30083AC0
« Reply #12 on: April 23, 2015, 03:34:18 PM »
Quote from: saratoga on April 23, 2015, 01:25:11 PM
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.
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 9136
Re: Clip Zip Divide by Zero 30083AC0
« Reply #13 on: April 23, 2015, 03:38:08 PM »
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. 
Logged

Offline dreamlayers

  • Developer
  • Member
  • *
  • Posts: 425
  • Boris Gjenero
    • My Blog
Re: Clip Zip Divide by Zero 30083AC0
« Reply #14 on: April 23, 2015, 03:52:21 PM »
Quote from: saratoga on April 23, 2015, 03:38:08 PM
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.
Logged

  • Print
Pages: [1] 2
« previous next »
+  Rockbox Technical Forums
|-+  Support and General Use
| |-+  Hardware
| | |-+  Clip Zip Divide by Zero 30083AC0
 

  • SMF 2.0.18 | SMF © 2021, Simple Machines
  • Rockbox Privacy Policy
  • XHTML
  • RSS
  • WAP2

Page created in 1.006 seconds with 23 queries.