Difference between revisions of "Talk:Error handling"

From WikiPrizm
Jump to navigationJump to search
(Bypassing system error dialogs with [EXE])
 
(2 intermediate revisions by 2 users not shown)
Line 6: Line 6:
 
= [EXE] on System Errors =
 
= [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.  -- [[User:Ahelper|Ahelper]] ([[User talk:Ahelper|talk]]) 04:39, 3 December 2014 (EST)
 
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.  -- [[User:Ahelper|Ahelper]] ([[User talk: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). -- [[User:Ahelper|Ahelper]] ([[User talk: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... --[[User:Gbl08ma|Gbl08ma]] ([[User talk: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.
 +
 +
[[User:Ahelper|Ahelper]] ([[User talk:Ahelper|talk]]) 04:27, 10 December 2014 (EST)

Latest revision as of 05:27, 10 December 2014

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)