Author | Topic: Fatal error log - any idea | |
---|---|---|
Adrian Wykrota | Fatal 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 Wykrota | Re: 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 Ziegler | Re: 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. |