Alaska Software Inc. - Fatal error log - any idea
Username: Password:
AuthorTopic: Fatal error log - any idea
Adrian WykrotaFatal error log - any idea
on Wed, 30 Apr 2008 09:25:41 +0200
FATAL ERROR LOG
System-Error
SYS Thread-ID: 756
Module: EVM
Error Codes: EH: 4 Sub: 6(6) OS: 6 XPP: 40
Call Stack of Thread 1 (656):
MYAPPEVENT(408)
MYMENU(0)
MAIN(0)
Call Stack of Thread 2 (852):
Call Stack of Thread 3 (932):
@TOOLBAR@I@EXECUTE(157)
Call Stack of Thread 4 (1196):
Call Stack of Thread 5 (1248):
Call Stack of Thread 6 (1532):
Call Stack of Thread 7 (3260):
Call Stack of Thread 8 (3036):
Call Stack of Thread 9 (2384):
Call Stack of Thread 10 (2476):
MYAPPEVENT(408)
PANELKASY(278)
(B)RaportyKasowe(67)
RAPORTYKASOWE(137)
OPENPACZKAKASY(1066)
(B)PaczkiKas(74)
@XBPBROWSE@I@HANDLEEVENT(1474)
PACZKIKAS(150)
DLL_PROC(260)
(B)GETTABMENU@0099(0)
Call Stack of Thread 11 (2616):
Call Stack of Thread 12 (2948):
Call Stack of Thread 13 (4308):
Call Stack of Thread 14 (4432):
Call Stack of Thread 15 (3864):
Call Stack of Thread 16 (4544):
Call Stack of Thread 17 (4528):
Call Stack of Thread 18 (3920):
Call Stack of Thread 19 (3852):
Call Stack of Thread 20 (3604):
File: C:\ADVANTEC\Program.exe
TimeStamp: 20080430 08:06
End of FATAL ERROR LOG.


404: FUNCTION MyAppEvent(mp1, mp2, oXbp, nTime)
405: LOCAL nRet := 0, bErr := {|| NIL}
406: bErr := ErrorBlock({|e|Break(e)})
407: BEGIN SEQUENCE
408:   nRet := AppEvent(@mp1, @mp2, @oXbp, nTime)
409: RECOVER USING oE
410:   ErrorBlock(bErr)
411:   nRet := 0
412:   oXbp := NIL
413: END SEQUENCE
414: ErrorBlock(bErr)
415: RETURN (nRet)

::ReadTime := 20

151: METHOD ToolBar:Execute
152: LOCAL nEvent := 0, mp1 := 0, mp2 := 0, oXbp := NIL, nSec := 0, bErr := 
{|| NIL}
153: //SaveLogSys("ToolBar:Start -> " + var2char(::Run))
154: DO WHILE ::Run
155:   bErr := ErrorBlock({|e|Break(e)})
156:   BEGIN SEQUENCE
157:     Sleep(NumNum(::ReadTime))
158:   RECOVER USING oE
159:     ErrorBlock(bErr)
160:      TODO: place your recover code here
161:   END SEQUENCE
162:   ErrorBlock(bErr)
163:   nSec := SECONDS()
(....)
245: RETURN (self)

FUNCTION NumNum(nNum)
LOCAL nRet := 0
IF nNum <> NIL .AND. VALTYPE(nNum) = "N"
  nRet := nNum
ELSEIF nNum <> NIL .AND. VALTYPE(nNum) = "C"
  nRet := VAL(nNum)
ENDIF
RETURN (nRet)

Alaska 1.90.00331 + xbTools + OdbcDbe + ActiveX
with all HotFixes
Windows XP with SP2

Please help.

Z powaaniem/Best regards
Adrian Wykrota
www.advantec-software.com.pl
Andreas Gehrs-Pahl
Re: Fatal error log - any idea
on Wed, 30 Apr 2008 05:03:53 -0400
Adrian,

>FATAL ERROR LOG
>System-Error
>SYS Thread-ID: 756
>Module: EVM
>Error Codes: EH: 4 Sub: 6(6) OS: 6 XPP: 40

This error occurred in a System Thread (with ID 756) in the Event Manager 
Module (EVM) of the Xbase++ Runtime. It did not happen in your code! There
is no way for you to determine what caused it. The actually Error that 
occurred is an OS Error and has something to do with (File or Memory) 
Handles, and it happens quite often in multi-threaded Xbase++ applications. 

The Xbase++ General Error Code is (XPP: 40), which means "Operating System 
Error", while the Xbase++ Sub-System Error Code is "EH: 4" (which also 
means "Operating System Error"). The actual OS Error Code "Sub: 6(6)" and 
"OS: 6" means simply: "Invalid Handle". If you can actually reproduce this 
error at will, you should send an example to Alaska, so they can try to 
fix it. Otherwise, you will just have to live with those occasional fatal 
errors (like everyone else using Xbase++).

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---
Adrian WykrotaRe: Fatal error log - any idea
on Wed, 30 Apr 2008 11:46:48 +0200
I can't reproduce but my client can very often on 30 workstations.

FATAL ERROR LOG
System-Error
SYS Thread-ID: 1288
Module: EVM
Error Codes: EH: 4 Sub: 6(6) OS: 6 XPP: 40
Call Stack of Thread 1 (1396):
MYAPPEVENT(408)
MYMENU(0)
MAIN(0)
Call Stack of Thread 2 (1192):
Call Stack of Thread 3 (1144):
@TOOLBAR@I@EXECUTE(157)
Call Stack of Thread 4 (936):
Call Stack of Thread 5 (664):
Call Stack of Thread 6 (236):
Call Stack of Thread 7 (2280):
Call Stack of Thread 8 (2324):
Call Stack of Thread 9 (2416):
Call Stack of Thread 10 (2524):
Call Stack of Thread 11 (2472):
Call Stack of Thread 12 (2440):
MYAPPEVENT(408)
DOKUMENTMAG(110)
DLL_PROC(260)
DLL_DOKUMENTMAG(464)
(B)GETTABMENU@0113(0)
Call Stack of Thread 13 (2788):
Call Stack of Thread 14 (2504):
Call Stack of Thread 15 (3360):
Call Stack of Thread 16 (2616):
Call Stack of Thread 17 (3528):
MYAPPEVENT(408)
ANALIZAMAG(1971)
DLL_PROC(260)
DLL_ANALIZAMAG(468)
(B)GETTABMENU@0131(0)
Call Stack of Thread 18 (3744):
Call Stack of Thread 19 (4200):
Call Stack of Thread 20 (32):
File: C:\Advantec\Program.exe
TimeStamp: 20080430 10:51
End of FATAL ERROR LOG.

Z powazaniem/Best regards
Adrian Wykrota
www.advantec-software.com.pl

Uzytkownik "Andreas Gehrs-Pahl" <Andreas@DDPSoftware.com> napisal w 
wiadomosci news:1j25cai5fe4x7$.9z4cbaaeijl4$.dlg@40tude.net...
> Adrian,
>
>>FATAL ERROR LOG
>>System-Error
>>SYS Thread-ID: 756
>>Module: EVM
>>Error Codes: EH: 4 Sub: 6(6) OS: 6 XPP: 40
>
> This error occurred in a System Thread (with ID 756) in the Event Manager
> Module (EVM) of the Xbase++ Runtime. It did not happen in your code! There
> is no way for you to determine what caused it. The actually Error that
> occurred is an OS Error and has something to do with (File or Memory)
> Handles, and it happens quite often in multi-threaded Xbase++ 
> applications.
>
> The Xbase++ General Error Code is (XPP: 40), which means "Operating System
> Error", while the Xbase++ Sub-System Error Code is "EH: 4" (which also
> means "Operating System Error"). The actual OS Error Code "Sub: 6(6)" and
> "OS: 6" means simply: "Invalid Handle". If you can actually reproduce this
> error at will, you should send an example to Alaska, so they can try to
> fix it. Otherwise, you will just have to live with those occasional fatal
> errors (like everyone else using Xbase++).
>
> -- Andreas
>
> ---                                                                      ---
>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>  415 Gute Street                     or: Andreas@DDPSoftware.com
>  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---
Clayton Jones Re: Fatal error log - any idea
on Thu, 01 May 2008 08:46:05 -0400
Hello Andreas,

>The actually Error that occurred is an OS Error and has something to do 
>with (File or Memory) Handles, and it happens quite often in multi-threaded 
>Xbase++ applications. 
>
>...Otherwise, you will just have to live with those occasional fatal 
>errors (like everyone else using Xbase++).

I find these statements to be curious.  All my apps use
multi-threading extensively and I never have these kinds of errors.
The only compile or runtime errors I get are caused by things in my
code.  Once they are fixed the apps run without problems.  In
addition, I occasionally get problem reports from TD users and in
almost every case it turns out to be a coding error of some sort.  My
experience is that Xpp is very stable and I do not associate
multi-threading with any sort of problem.

Since his fatal log contained this

 @TOOLBAR@I@EXECUTE(157)

I'm wondering if this is an activeX toolbar and if so, perhaps that is
introducing the seed of the problem...


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement
Andreas Gehrs-Pahl
Re: Fatal error log - any idea
on Thu, 01 May 2008 17:07:31 -0400
Clayton,

>I find these statements to be curious. All my apps use
>multi-threading extensively and I never have these kinds of errors.

I didn't intend to blame the errors on (the use of) multi-threading, 
but wanted to simply point out that most of the XppFatal logs that I 
have seen that show those kinds of errors are in fact in multi-threaded 
applications. The reason for this is probably that most complex Xbase++ 
programs are indeed multi-threaded -- at least mine are.

If you search (all) the news groups (including the post's bodies), you 
will find quite a few of those particular XppFatal error logs being 
reported here. Most were caused (at least in 1.82) by threads that were 
shut(ting) down while there were still Events pending for them. This 
should have been fixed in the current 1.9 version, though. Frank++ and 
even Steffen at one point substantiated and verified this! For some time,
the ToolTip thread of eXpress++ was involved in the majority of this 
particular type of error. 

>The only compile or runtime errors I get are caused by things in my
>code. Once they are fixed the apps run without problems. 

Are you sure that you would even know about any XppFatal logs that your
applications create? They are very often simply overlooked and their 
existence isn't advertised in any way, so the average user will not 
even know about or report them. Only if you pro-actively look for them
or your program sends or archives them for you, will you probably be
aware of their occurrence.

>In addition, I occasionally get problem reports from TD users and in
>almost every case it turns out to be a coding error of some sort. My
>experience is that Xpp is very stable and I do not associate
>multi-threading with any sort of problem.

Yes, most compile and runtime errors can be traced back to coding errors, 
but we are talking here about XppFatal errors that occur in the Xbase++ 
runtime and not actually in your code. There are obviously reasons for 
those errors and they are obviously triggered by some Xbase++ Code in 
the application, but I highly doubt that one can consider (most of) them 
programming errors. Many of those errors are highly environment-dependent
and I personally (virtually) never get any of those XppFatal errors on my
development or test machines. But our clients get them "all the time". 

And with "all the time" I mean some specific clients and some specific 
workstations at some specific client sites get an XppFatal.log (of one 
type or another) every other month (and sometimes every other week) or so. 
I don't have any exact numbers, but I'd say that with the introduction of 
Xbase++ 1.90.331, the number of XppFatal errors has slightly decreased. 
And because they are so relatively seldom, and usually non-reproducible, 
they aren't even reported very often. The users just shrug them off, 
restart the program, and go on with their work.

>Since his fatal log contained this
>@TOOLBAR@I@EXECUTE(157)
>I'm wondering if this is an activeX toolbar and if so, perhaps that is
>introducing the seed of the problem...

That could very well be the case. But as I said, I have several such 
XppFatal.log files here, and I don't use any ToolBars. And some of the 
logs predate my use of any Active-X components in the program. So, even 
though the error might very well be related to the ToolBar, the actual 
error occurred in the Xbase++ Event Manager Module, a runtime Thread, 
which is indeed completely out of the control of the Xbase++ programmer!

The point is that we (the Xbase++ program developers) have usually no (or 
very limited) control over the environment in which our programs run, and 
we rely on the Alaska Xbase++ development team to make the Runtime stable 
enough to deal with such varied environments without creating XppFatal log 
errors, which are completely out of our (programming) control. 

For example, any Xbase++ program that is compiled with a version prior to 
1.9 will create an XppFatal error log (and won't run) when DEP is not 
disabled. There is nothing we (as programmers) can do about this, but 
changing the environment in which the program runs -- or upgrade to Xbase++ 
1.9, where Alaska has fixed this issue. There were (and still are) many 
similar issues, like the memory exhaustion (or GC-lockup) problems, some 
of which have still not been resolved.

Nevertheless, as I said before, Xbase++ programmers just have to live with 
those occasional XppFatal errors, and as far as I can tell, everybody does.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---
Hannes ZieglerRe: Fatal error log - any idea
on Fri, 02 May 2008 02:31:27 +0200
Clayton,

>Otherwise, you will just have to live with those occasional fatal
>errors (like everyone else using Xbase++).

PMFYI: "To live with those occasional fatal errors"

this is an absolutely unacceptable situation for a software product that 
claims to be "mature". (Xbase++)

FYI, I am about to announce "The YUKON Project" avalability soon, and I can 
tell you one thing: I have NEVER been confronted with more XPPFATAL.LOGs and 
more IDSCs before, than during the development of "The YUKON Project" (I've 
got zillions of IDSCs 

Xbase++ is absolutely intolerant towards errors occurring on the C-API or 
DLLFUNCTION level. There is absolutely no way to isolate the cause of error 
when it happens on the DLLFUNCTION or C-API level.

FWIW, the Xbase++ error handling sytem is NOT mature enough to isolate non 
PRG-code errors. This applies espescially for data exchange between Xbase++ 
multi-threaded applications and external multi-threaded processes.

IMO, Andreas, Steffen and Till should better do their homework and improve 
Xbase++'s error handling routines. They know this must be done since a 
minimum of 8 (EIGHT) years, but they have done NOTHING to improve error 
handling with Xbase++, ever.

IMO, your statemet is a question of pushing Alaska Software Inc. towards the 
needs of "Xbase++ users". Your statement is normally responded with "shit 
happens" from Alaska Software Inc.

Question to you: Who else "but us" can push "Alaska Software Inc." towards 
the right directon?

Don't you think it's the Xbase++ users who can turn Alaska Softare to think 
twice?

My 2cnts
--
Hannes


"Clayton Jones" <topdown@cjcom.net> schrieb im Newsbeitrag 
news:pudj14phq3m59ev8n6g98fejdjh89cg9p9@4ax.com...
> Hello Andreas,
>
>>The actually Error that occurred is an OS Error and has something to do
>>with (File or Memory) Handles, and it happens quite often in 
>>multi-threaded
>>Xbase++ applications.
>>
>>...Otherwise, you will just have to live with those occasional fatal
>>errors (like everyone else using Xbase++).
>
> I find these statements to be curious.  All my apps use
> multi-threading extensively and I never have these kinds of errors.
> The only compile or runtime errors I get are caused by things in my
> code.  Once they are fixed the apps run without problems.  In
> addition, I occasionally get problem reports from TD users and in
> almost every case it turns out to be a coding error of some sort.  My
> experience is that Xpp is very stable and I do not associate
> multi-threading with any sort of problem.
>
> Since his fatal log contained this
>
> @TOOLBAR@I@EXECUTE(157)
>
> I'm wondering if this is an activeX toolbar and if so, perhaps that is
> introducing the seed of the problem...
>
>
> Regards,
> Clayton
>
> Clayton Jones   www.cjcom.net
> Top-Down Library for Xbase++
> X-DBU Database Utility
> X-MEMO Memo Field Replacement
>
Carlos Beling Re: Fatal error log - any idea
on Wed, 30 Apr 2008 09:13:54 -0300
Hi Adrian:
good morning.
Is not the line 410 in your function that may be causing the error?
Normally I restore the ErrorBlock after the END SEQUENCE.

Beling
HTH

Adrian Wykrota escreveu:
> FATAL ERROR LOG
> System-Error
> SYS Thread-ID: 756
> Module: EVM
> Error Codes: EH: 4 Sub: 6(6) OS: 6 XPP: 40
> Call Stack of Thread 1 (656):
> MYAPPEVENT(408)
> MYMENU(0)
> MAIN(0)
> Call Stack of Thread 2 (852):
> Call Stack of Thread 3 (932):
> @TOOLBAR@I@EXECUTE(157)
> Call Stack of Thread 4 (1196):
> Call Stack of Thread 5 (1248):
> Call Stack of Thread 6 (1532):
> Call Stack of Thread 7 (3260):
> Call Stack of Thread 8 (3036):
> Call Stack of Thread 9 (2384):
> Call Stack of Thread 10 (2476):
> MYAPPEVENT(408)
> PANELKASY(278)
> (B)RaportyKasowe(67)
> RAPORTYKASOWE(137)
> OPENPACZKAKASY(1066)
> (B)PaczkiKas(74)
> @XBPBROWSE@I@HANDLEEVENT(1474)
> PACZKIKAS(150)
> DLL_PROC(260)
> (B)GETTABMENU@0099(0)
> Call Stack of Thread 11 (2616):
> Call Stack of Thread 12 (2948):
> Call Stack of Thread 13 (4308):
> Call Stack of Thread 14 (4432):
> Call Stack of Thread 15 (3864):
> Call Stack of Thread 16 (4544):
> Call Stack of Thread 17 (4528):
> Call Stack of Thread 18 (3920):
> Call Stack of Thread 19 (3852):
> Call Stack of Thread 20 (3604):
> File: C:\ADVANTEC\Program.exe
> TimeStamp: 20080430 08:06
> End of FATAL ERROR LOG.
> 
> 
> 404: FUNCTION MyAppEvent(mp1, mp2, oXbp, nTime)
> 405: LOCAL nRet := 0, bErr := {|| NIL}
> 406: bErr := ErrorBlock({|e|Break(e)})
> 407: BEGIN SEQUENCE
> 408:   nRet := AppEvent(@mp1, @mp2, @oXbp, nTime)
> 409: RECOVER USING oE
> 410:   ErrorBlock(bErr)
> 411:   nRet := 0
> 412:   oXbp := NIL
> 413: END SEQUENCE
> 414: ErrorBlock(bErr)
> 415: RETURN (nRet)
> 
> ::ReadTime := 20
> 
> 151: METHOD ToolBar:Execute
> 152: LOCAL nEvent := 0, mp1 := 0, mp2 := 0, oXbp := NIL, nSec := 0, bErr := 
> {|| NIL}
> 153: //SaveLogSys("ToolBar:Start -> " + var2char(::Run))
> 154: DO WHILE ::Run
> 155:   bErr := ErrorBlock({|e|Break(e)})
> 156:   BEGIN SEQUENCE
> 157:     Sleep(NumNum(::ReadTime))
> 158:   RECOVER USING oE
> 159:     ErrorBlock(bErr)
> 160:      TODO: place your recover code here
> 161:   END SEQUENCE
> 162:   ErrorBlock(bErr)
> 163:   nSec := SECONDS()
> (....)
> 245: RETURN (self)
> 
> FUNCTION NumNum(nNum)
> LOCAL nRet := 0
> IF nNum <> NIL .AND. VALTYPE(nNum) = "N"
>   nRet := nNum
> ELSEIF nNum <> NIL .AND. VALTYPE(nNum) = "C"
>   nRet := VAL(nNum)
> ENDIF
> RETURN (nRet)
> 
> Alaska 1.90.00331 + xbTools + OdbcDbe + ActiveX
> with all HotFixes
> Windows XP with SP2
> 
> Please help.