Talk:Error handling

From WikiPrizm
Revision as of 05:27, 10 December 2014 by Ahelper (talk | contribs) (→‎Share System Errors Here: new section)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Exception Handling

I'll put in a section for handling certain types of exceptions once my custom exception handler code matures more. Once ELF loading gets put in, debugging exceptions should be much simpler (I should be able to get a stack trace, filename/line number, register dump, etc.).

Ahelper (talk) 18:48, 2 December 2014 (EST)

[EXE] on System Errors

Some system errors actually are handled by the OS in the error dialog with the [EXE] key. I was testing code and had a bad write (target was in the 0xFEC1nnnn area), causing an ADDRESS(W) error. Hitting [EXE] let the program continue running, although completely unstable with the RAM trashed. The full extent of this key should be examined more safely. -- Ahelper (talk) 04:39, 3 December 2014 (EST)

Internal printf/sprintf/snprintf

The string used for the system error dialog uses a formatting string that is compatible with printf and friends. This might be valuable to find the syscall related that generates that message content rather than including printf and friends in individual addins (or a shared library when ELF loading gets around to working). -- Ahelper (talk) 17:36, 3 December 2014 (EST)

  • That is a very good idea, the sad part is that the printf/sprintf/etc. may not be exposed as syscalls, which means there's not a common way to call them across OS versions, like what happens with the zlib functions. However itoa, for example, is available, so it's really possible that sprintf is too. Would it even be possible that there's a more or less complete libc waiting for us, we just don't know the syscalls? I would think that by now we would have found about them... --Gbl08ma (talk) 19:18, 3 December 2014 (EST)

Share System Errors Here

Looking at getting a list of ways/locations these system errors show up. I have an odd one to add: an INTERRUPT error when dismounting the Prizm. Going to the Main Menu brought me to a badly scrolled menu since the addin cache was cleared. This was due to the FS not being remounted as the memory app reported 0 bytes free an no files in storage memory. (Nearly all of my prizm bugs are from the the USB, reboots, this interrupt error, Linux kernel panics, EFI BIOS lockups, etc.)

Other odd errors I remember from before are connecting the calc to USB when in the setup mode on first calc boot and trying to mount it. Crashes.

Ahelper (talk) 04:27, 10 December 2014 (EST)