Alaska Software Inc. - XppFatal
Alaska Software Inc. - XppFatal
Username: Password:
AuthorTopic: XppFatal
Carlos a Beling XppFatal
on Wed, 30 May 2018 11:42:37 -0300
Hello:
Good morning.
Please, what means the XppFatal below?
Is there some documentation about XppFatal?
It is hard for me - frequently not possible - to determine the cause of 
the error without it.

FATAL ERROR LOG
Not recoverable Error!
SYS Thread-ID: 704
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (528):
@CABPUSHBOX_@I@SETPOS(149)

Fraternally
Beling
Jim LeeRe: XppFatal
on Wed, 30 May 2018 17:55:42 +0200
hi,

are you using VIO or GUI Mode ?
it seems me that you have a GUI Problem
Carlos a Beling Re: XppFatal
on Wed, 30 May 2018 14:49:26 -0300
Hi Jim.
Good afternoon.
Many thanks.
It is a XbpStatic() shown in a XbpCrt().
This problem occurs from time to time, rarely.
The worse thing is that XppFatal does not give informations about the 
problem and I never can correct it if it is caused by my fault.
I do not know if it happens with you, but for me XppFatal has been 
almost useless.
Have you any clue about the XppFatal that I posted?

Fraternally
Beling

Em 30/05/2018 12:55, Jim Lee escreveu:
> hi,
>
> are you using VIO or GUI Mode ?
> it seems me that you have a GUI Problem
>
>
Andreas Gehrs-Pahl
Re: XppFatal
on Wed, 30 May 2018 14:08:35 -0400
Carlos,

>Is there some documentation about XppFatal?

Not officially.

>Please, what means the XppFatal below?
>FATAL ERROR LOG
>Not recoverable Error!
>SYS Thread-ID: 704
>Module: EH
>Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
>Call Stack of Thread 1 (528):
>@CABPUSHBOX_@I@SETPOS(149)

This Fatal Error Log is incomplete, so there is possibly some information 
missing that might be relevant. All individual Fatal Error Log entries 
normally start with the line: "FATAL ERROR LOG" and end with the line: 
"End of FATAL ERROR LOG."

This error occurred in an Xbase++ Thread (with Thread-ID 704), for which no 
call stack is listed. At the time of the Fatal Error Log, the application's 
Main() Thread -- Thread 1 (with Thread-ID 528) -- was executing line 149 of 
the Method "SetPos()" of the Class "CabPushBox_".

Some notes on Call Stack entries:

Call Stack lines that start with an "@" denote code belonging to a class, 
followed by the Class Name and then either "@I@" followed by an Instance 
Method Name or "@C@" followed by a Class Method Name.

A leading "(B)" indicates the execution of a Code Block, followed by the 
Name of the Function, Procedure, or Method, where the Code Block was 
defined. This could be followed by an "@" and a (usually four-digit) number, 
before the line number (in parenthesis). I'm not sure what those (4-digit) 
numbers indicates, though.

Some additional Error Code details:

>Module: EH
The error occurred in the Xbase++ "Error Handler" module.

>Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
The Error Codes indicate that the Xbase++ Sub-Error Code was: "900", with 
error description: "(Fatal) Error in EH during Unwind".

The four different types of Error Codes are:
EH: 900   -- This shows the Xbase++ Sub-Error Code (in Decimal)
Sub: 0(0) -- This sometimes shows/repeats either the OS Error Code or the 
             Xbase++ General Error Code in both Decimal (and Hex)
OS: 0     -- This shows the OS Error Code (in Decimal)
XPP: 0    -- This shows the Xbase++ General Error Code (in Decimal)

You can download a list of possible Modules (Codes and Names) and various 
Error Codes and their Descriptions from my web site here:

	http://www.AbsoluteSoftwareLLC.com/Downloads/Xb_Codes.zip

The most likely reason for such "900 Error" XppFatal Logs is that the 
thread in which the (original) error/exception was caused had already ended 
(or couldn't be found) when the error handler was done and wanted to return 
to the offending code.

Sometimes the call stacks of the other threads help in determining where 
(and why) a fatal error occurred, but if the Call Stack is empty for the 
thread that (supposedly) caused the error, then this isn't possible.

Depending on your (custom) Error Handler and the actual reason for the 
(underlying) error, such "900" Fatal Errors are sometimes preceded by a 
standard Error Log, which might detail the actually root-error, from which 
Xbase++ wasn't able to recover. Using the Date-Time Stamp at the end of each 
Fatal Log entry might help with correlating such log entries.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC
Carlos a Beling Re: XppFatal
on Wed, 30 May 2018 15:41:02 -0300
Hello Andreas:
good afternoon.
Many thanks.
Very good your explanation. It helped me to understand something.
The ommited part of XppFatal is the application call stack.
In time: the statment that gave the error is executed many times and 
sudenly crashes.
If the application find an Error.log in its folder it sends the 
Error.log file by e-mail to the suport's boys.

Fraternally
Beling

Em 30/05/2018 15:08, Andreas Gehrs-Pahl escreveu:
> Carlos,
>
>> Is there some documentation about XppFatal?
>
> Not officially.
>
>> Please, what means the XppFatal below?
>> FATAL ERROR LOG
>> Not recoverable Error!
>> SYS Thread-ID: 704
>> Module: EH
>> Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
>> Call Stack of Thread 1 (528):
>> @CABPUSHBOX_@I@SETPOS(149)
>
> This Fatal Error Log is incomplete, so there is possibly some information
> missing that might be relevant. All individual Fatal Error Log entries
> normally start with the line: "FATAL ERROR LOG" and end with the line:
> "End of FATAL ERROR LOG."
>
> This error occurred in an Xbase++ Thread (with Thread-ID 704), for which no
> call stack is listed. At the time of the Fatal Error Log, the application's
> Main() Thread -- Thread 1 (with Thread-ID 528) -- was executing line 149 of
> the Method "SetPos()" of the Class "CabPushBox_".
>
> Some notes on Call Stack entries:
>
> Call Stack lines that start with an "@" denote code belonging to a class,
> followed by the Class Name and then either "@I@" followed by an Instance
> Method Name or "@C@" followed by a Class Method Name.
>
> A leading "(B)" indicates the execution of a Code Block, followed by the
> Name of the Function, Procedure, or Method, where the Code Block was
> defined. This could be followed by an "@" and a (usually four-digit) number,
> before the line number (in parenthesis). I'm not sure what those (4-digit)
> numbers indicates, though.
>
> Some additional Error Code details:
>
>> Module: EH
> The error occurred in the Xbase++ "Error Handler" module.
>
>> Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
> The Error Codes indicate that the Xbase++ Sub-Error Code was: "900", with
> error description: "(Fatal) Error in EH during Unwind".
>
> The four different types of Error Codes are:
> EH: 900   -- This shows the Xbase++ Sub-Error Code (in Decimal)
> Sub: 0(0) -- This sometimes shows/repeats either the OS Error Code or the
>               Xbase++ General Error Code in both Decimal (and Hex)
> OS: 0     -- This shows the OS Error Code (in Decimal)
> XPP: 0    -- This shows the Xbase++ General Error Code (in Decimal)
>
> You can download a list of possible Modules (Codes and Names) and various
> Error Codes and their Descriptions from my web site here:
>
> 	http://www.AbsoluteSoftwareLLC.com/Downloads/Xb_Codes.zip
>
> The most likely reason for such "900 Error" XppFatal Logs is that the
> thread in which the (original) error/exception was caused had already ended
> (or couldn't be found) when the error handler was done and wanted to return
> to the offending code.
>
> Sometimes the call stacks of the other threads help in determining where
> (and why) a fatal error occurred, but if the Call Stack is empty for the
> thread that (supposedly) caused the error, then this isn't possible.
>
> Depending on your (custom) Error Handler and the actual reason for the
> (underlying) error, such "900" Fatal Errors are sometimes preceded by a
> standard Error Log, which might detail the actually root-error, from which
> Xbase++ wasn't able to recover. Using the Date-Time Stamp at the end of each
> Fatal Log entry might help with correlating such log entries.
>
> Hope that helps,
>
> Andreas
>