RE: [Harbour] Harbour random GPFs
-Original Message- From: Heinz V Bergen [mailto:hber...@ops.phl.ca] Sent: Thursday, May 06, 2010 11:41 PM To: harbour@harbour-project.org Subject: Re: [Harbour] Harbour random GPFs Whew! My problem has been resolved by fix in Revision 14441. [...] Przemysław Czerpak for the encouragement and final fix. Heinz My problem with GPF too was resolved. Many, many thanks :) Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Whew! My problem has been resolved by fix in Revision 14441. Thanks all for the insight, code reducing experience and extra thanks to Przemysław Czerpak for the encouragement and final fix. Heinz Heinz V Bergen wrote: Viktor Szakáts wrote: Hi All, Lately I mentioned having random GPFs with my live apps since changing to Harbour r14336. I also mentioned they are gone. This turned out not to be true, they are still present. ... Viktor Hello all, not sure if this is related but I have been fighting with random GPFs also. -was gui gtwvt app, and app would just close with no error, sometimes processing 1 iteration of an Import/Export process, sometimes crash after second. -compiled as non gui without GTWVT, but still got crashes, but now got an error message: Unrecoverable error 9019: Stack underflow and always on the same Return() statement, sometimes on 1st iteration, usually on the second one, but sometimes (rarely) 3rd or more. -compiled with debugger, now get different error: Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0041F2A3 EAX:ABB4 EBX:000D ECX: EDX:0004 ESI:00BC3874 EDI: EBP:0001 CS:EIP:001B:0041F2A3 SS:ESP:0023:0022F540 DS:0023 ES:0023 FS:003B GS: Flags:00010206 CS:EIP: 80 3B B4 0F 86 B4 00 00 00 C7 44 24 0C 00 00 00 SS:ESP: 00C331D8 03CF 000D 00C226B4 00CAD 7CC 0002 0001 0001 0052C81A 00CAD7CC 0002 00BC33DC 00C56A30 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... I don't really understand what this means, my guess is some process appears to be damaging the stack. If this is not related to issue, any idea what I need to look at to resolve issue? Thanks, Heinz -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28479877.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
On Mon, 03 May 2010, Heinz V Bergen wrote: Hi, OK, using latest Harbour (r14422) and did a mingw32-make clean install, then recompiled my app with hbmk2 as console app, no GTs and tested, still got error. When Windows dialog to send error report, I clicked on debug window opening VS2005 debugger, showed error in disassembled code as Unhandled exception at 0x0041f2a3 in Hb2Ftr.exe: 0xC005: Access violation reading location 0x000d, in case this helps? [...] -recompiled my app with Harbour release 2.0 and tested, had no errors. Clipper also has no errors. -tryed various combinations and discovered issue is caused by latest HBMK2, as using HBMK2 from Version 2.0 distro, copying it to with latest SVN Harbour\Bin, rebuild app, test and appears to run fine with no more errors, does that make sense? Can you send here the body of function which creates this problem? If possible please try to reduce it removing all code which can be deleted and the error is still generated. HBMK2 is linked with Harbour compiler library and such errors can be caused by wrong code generated by compiler. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Result in Hb_Out.Log after executing app twice, first time got error 9019, second time got error 6005: Application Internal Error - C:\op_new\Hb2Ftr.exe Terminated at: 2010.05.04 09:10:28 Unrecoverable error 9019: Stack underflow Called from EXPORT(973) in ../BREXPORT.prg Called from EXPORTEXCP(182) in ../BREXPORT.prg Called from (b)EVAL(2321) Called from COMMBROW(2852) in ../../hvblib/HVBLIB.prg Called from BREXPORT(153) in ../BREXPORT.prg Called from FTRMEN1(77) in ../FTRMEN1.prg Called from FTRMAIN(150) in ../FTRMAIN.prg Called from FTRMENU(467) in ../FTRMENU.prg Application Internal Error - C:\op_new\Hb2Ftr.exe Terminated at: 2010.05.04 09:10:49 Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:004198C3 EAX:6A99 EBX:000D ECX: EDX:0004 ESI:00B7E444 EDI: EBP:0001 CS:EIP:001B:004198C3 SS:ESP:0023:0022F540 DS:0023 ES:0023 FS:003B GS: Flags:00010206 CS:EIP: 80 3B B4 0F 86 B4 00 00 00 C7 44 24 0C 00 00 00 SS:ESP: 00B9CC90 0007 0054B880 0006 00B88D44 00B9E56C 0002 0001 0001 005224DA 00B9E56C 0002 00B7DFEC 00BCC888 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... Modules: 0x0040 0x001F6000 C:\op_new\Hb2Ftr.exe 0x7C90 0x000B2000 C:\WINDOWS\system32\ntdll.dll 0x7C80 0x000F6000 C:\WINDOWS\system32\kernel32.dll 0x77DD 0x0009B000 C:\WINDOWS\system32\ADVAPI32.DLL 0x77E7 0x00092000 C:\WINDOWS\system32\RPCRT4.dll 0x77FE 0x00011000 C:\WINDOWS\system32\Secur32.dll 0x77C1 0x00058000 C:\WINDOWS\system32\msvcrt.dll 0x7E41 0x00091000 C:\WINDOWS\system32\USER32.dll 0x77F1 0x00049000 C:\WINDOWS\system32\GDI32.dll 0x7639 0x0001D000 C:\WINDOWS\system32\IMM32.DLL 0x77B4 0x00022000 C:\WINDOWS\system32\Apphelp.dll 0x77C0 0x8000 C:\WINDOWS\system32\VERSION.dll Called from EXPORT(973) in ../BREXPORT.prg Called from EXPORTEXCP(182) in ../BREXPORT.prg Called from (b)EVAL(2321) Called from COMMBROW(2852) in ../../hvblib/HVBLIB.prg Called from BREXPORT(153) in ../BREXPORT.prg Called from FTRMEN1(77) in ../FTRMEN1.prg Called from FTRMAIN(150) in ../FTRMAIN.prg Called from FTRMENU(467) in ../FTRMENU.prg Final app is GUI and contains GtWvt and GtWin, but I have removed and still produce error, code is in form that directly compiles in clipper also. I use a .hbm file to compile the app via hbmk2 @hb2ftr.hbm, file contents below: -oHb2Ftr -prgflag=/m /n /dHASCHAR031 -pause -trace -main=Ftrmenu -workdir=Output -instpath=c:\op_new\ -info -plat=win -comp=mingw ..\FTRMENU.prg ..\FTRMAIN.prg ..\MAINPROC.prg ..\FTRMEN1.prg ..\TRIPIMPT.prg ..\BREXPORT.prg ..\BRIMPORT.prg ..\BRIMPSRV.prg ..\BRIMPWHD.prg ..\BRIMPSYN.prg ..\BRIMPCLU.prg ..\EXEUPDTS.prg ..\FIXRQST.prg ..\CLOSEPER.prg ..\CLOSEPAY.prg ..\BRIMPCLB.prg ..\BKIMPORT.prg ..\BKIMP2.prg ..\BKIMPSI.prg ..\BRIMPBRS.prg ..\BRIMPWOS.prg ..\BREXPWOS.prg ..\IMPFUNCS.prg ..\IMPFUNC2.prg ..\UASSIGN.prg ..\PURGETX.PRG ..\..\UNIT\TIREFIXB.PRG ..\..\txlog\tx_log.prg ..\..\hvblib\HVBLIB.prg ..\..\hvblib\HVBLIB2.prg Thanks, Heinz Viktor Szakáts wrote: Could you post your complete hb_out.log? What extra libs do you use (-l hbmk2 options)? Viktor On 2010 May 3, at 22:15, Heinz V Bergen wrote: OK, using latest Harbour (r14422) and did a mingw32-make clean install, then recompiled my app with hbmk2 as console app, no GTs and tested, still got error. When Windows dialog to send error report, I clicked on debug window opening VS2005 debugger, showed error in disassembled code as Unhandled exception at 0x0041f2a3 in Hb2Ftr.exe: 0xC005: Access violation reading location 0x000d, in case this helps? 0041F259 sub esp,0ACh 0041F25F mov edi,dword ptr [esp+0C4h] 0041F266 mov ebx,dword ptr [esp+0C0h] 0041F26D mov dword ptr [esp+68h],ebp 0041F271 testedi,edi 0041F273 je 0041F28A 0041F275 mov eax,dword ptr [esp+0C4h] 0041F27C movsx eax,word ptr [eax+4] 0041F280 shr eax,0Ah 0041F283 and eax,1 0041F286 mov dword ptr [esp+68h],eax 0041F28A xor ebp,ebp 0041F28C lea esi,[esi] 0041F290 mov eax,dword ptr ds:[00624278h] 0041F295 dec eax 0041F296 testeax,eax 0041F298 mov dword ptr ds:[00624278h],eax 0041F29D je 0041F36A 0041F2A3 cmp byte ptr [ebx],0B4h 0041F2A6 jbe 0041F360 0041F2AC mov dword ptr [esp+0Ch],0 0041F2B4 mov dword ptr [esp+8],0 0041F2BC mov dword ptr [esp+4],0 0041F2C4 mov dword ptr [esp],2336h 0041F2CB call0048C830 0041F2D0 movzx eax,word ptr ds:[6240F4h] 0041F2D7 testeax,eax 0041F2D9 je
Re: [Harbour] Harbour random GPFs
Hello, Error occurs on the Return() of the function and all processes within were completed successfully. The function creates Directories, copies files, creates an FTP script, calls external RUN to PkZip and FTP and then erases files and removes directories, thought maybe RUN calls were the culprit, so I have bypassed PKZIP and FTP calls, just replacing with Copy File so process can continue, and error still occurs. Not sure if posting function in a usable form will be possible, but I will continue trying to narrow it down and see if I can come up with something. One item of note though, is that the latest SVN hbmk2 and release 2.0 hbmk2 do create different application EXE sizes. Heinz Przemysław Czerpak wrote: On Mon, 03 May 2010, Heinz V Bergen wrote: Hi, OK, using latest Harbour (r14422) and did a mingw32-make clean install, then recompiled my app with hbmk2 as console app, no GTs and tested, still got error. When Windows dialog to send error report, I clicked on debug window opening VS2005 debugger, showed error in disassembled code as Unhandled exception at 0x0041f2a3 in Hb2Ftr.exe: 0xC005: Access violation reading location 0x000d, in case this helps? [...] -recompiled my app with Harbour release 2.0 and tested, had no errors. Clipper also has no errors. -tryed various combinations and discovered issue is caused by latest HBMK2, as using HBMK2 from Version 2.0 distro, copying it to with latest SVN Harbour\Bin, rebuild app, test and appears to run fine with no more errors, does that make sense? Can you send here the body of function which creates this problem? If possible please try to reduce it removing all code which can be deleted and the error is still generated. HBMK2 is linked with Harbour compiler library and such errors can be caused by wrong code generated by compiler. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28447766.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Error occurs on the Return() of the function and all processes within were completed successfully. The function creates Directories, copies files, creates an FTP script, calls external RUN to PkZip and FTP and then erases files and removes directories, thought maybe RUN calls were the culprit, so I have bypassed PKZIP and FTP calls, just replacing with Copy File so process can continue, and error still occurs. Not sure if posting function in a usable form will be possible, but I will continue trying to narrow it down and see if I can come up with something. One item of note though, is that the latest SVN hbmk2 and release 2.0 hbmk2 do create different application EXE sizes. Change of executable size or even change in the checksum of the generated executable by itself isn't an indication of a problem. hbmk2 is using Harbour libs, which change size all the time, plus it sometimes happens that C compiler options used by hbm2 change over time. The final executable will be created by C linker, which may have its own side of the story. Point is to have a consistently and freshly rebuilt Harbour, 3rd party and local libs, and app, when doing tests. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
The offending line 973 code is: Return( lOK ) The executable is running where intended. Heinz Pritpal Bedi wrote: Heinz V Bergen wrote: Called from EXPORT(973) in ../BREXPORT.prg Can you show the offending line code ? I suspect, you are executing the .exe from a different location other than it is intended to. Right ? Line # 973 in export.prg may provide us a clue. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Harbour-random-GPFs-tp4968103p5003799.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28450523.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
On Tue, 04 May 2010, Heinz V Bergen wrote: Hi, Error occurs on the Return() of the function and all processes within were completed successfully. The function creates Directories, copies files, creates an FTP script, calls external RUN to PkZip and FTP and then erases files and removes directories, thought maybe RUN calls were the culprit, so I have bypassed PKZIP and FTP calls, just replacing with Copy File so process can continue, and error still occurs. Not sure if posting function in a usable form will be possible, but I will continue trying to narrow it down and see if I can come up with something. One item of note though, is that the latest SVN hbmk2 and release 2.0 hbmk2 do create different application EXE sizes. I know that the error appears on RETURN but it means that somewhere earlier some value was wrongly removed from HVM stack. It can be _any_ PRG construction executed before the RETURN statement. If you can remove some code from your function then it may help to locate the place where is the critical code which is the reason of problem. You can also send this function to me and maybe I'll be able to find the problem without code reduction only looking at PRG constructions used by you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Agreed, my thought is that hbmk2 in the two versions are using different compiler options, as the only difference is the two different versions of hbmk2 that I used to compile my app. Of course I'm probably looking at this in a somewhat less knowledgable direction. Based on the same hbm script, same Harbour.exe and Libs, same Mingw GCC and Libs, I thought both hbmk2 versions would make the same App EXE in the end. Well I took a look at the source for hbmk2 and Viktor, that is some piece of artificial intelligence! Viktor Szakáts wrote: Change of executable size or even change in the checksum of the generated executable by itself isn't an indication of a problem. hbmk2 is using Harbour libs, which change size all the time, plus it sometimes happens that C compiler options used by hbm2 change over time. The final executable will be created by C linker, which may have its own side of the story. Point is to have a consistently and freshly rebuilt Harbour, 3rd party and local libs, and app, when doing tests. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28451558.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Agreed, my thought is that hbmk2 in the two versions are using different compiler options, as the only difference is the two different versions of You can verify the exact options/arguments used if you add '-trace' option to hbmk2. hbmk2 that I used to compile my app. Of course I'm probably looking at this in a somewhat less knowledgable direction. Based on the same hbm script, same Harbour.exe and Libs, same Mingw GCC and Libs, I thought both hbmk2 versions would make the same App EXE in the end. Well I took a look at the source for hbmk2 and Viktor, that is some piece of artificial intelligence! It's just emulated AI :) Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Hi, First retest your app using latest Harbour (r14412 or newer) and see if it fixes these problems. Viktor On 2010 May 2, at 21:39, Heinz V Bergen wrote: Viktor Szakáts wrote: Hi All, Lately I mentioned having random GPFs with my live apps since changing to Harbour r14336. I also mentioned they are gone. This turned out not to be true, they are still present. ... Viktor Hello all, not sure if this is related but I have been fighting with random GPFs also. -was gui gtwvt app, and app would just close with no error, sometimes processing 1 iteration of an Import/Export process, sometimes crash after second. -compiled as non gui without GTWVT, but still got crashes, but now got an error message: Unrecoverable error 9019: Stack underflow and always on the same Return() statement, sometimes on 1st iteration, usually on the second one, but sometimes (rarely) 3rd or more. -compiled with debugger, now get different error: Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0041F2A3 EAX:ABB4 EBX:000D ECX: EDX:0004 ESI:00BC3874 EDI: EBP:0001 CS:EIP:001B:0041F2A3 SS:ESP:0023:0022F540 DS:0023 ES:0023 FS:003B GS: Flags:00010206 CS:EIP: 80 3B B4 0F 86 B4 00 00 00 C7 44 24 0C 00 00 00 SS:ESP: 00C331D8 03CF 000D 00C226B4 00CAD 7CC 0002 0001 0001 0052C81A 00CAD7CC 0002 00BC33DC 00C56A30 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... I don't really understand what this means, my guess is some process appears to be damaging the stack. If this is not related to issue, any idea what I need to look at to resolve issue? Thanks, Heinz -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28429001.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
OK, using latest Harbour (r14422) and did a mingw32-make clean install, then recompiled my app with hbmk2 as console app, no GTs and tested, still got error. When Windows dialog to send error report, I clicked on debug window opening VS2005 debugger, showed error in disassembled code as Unhandled exception at 0x0041f2a3 in Hb2Ftr.exe: 0xC005: Access violation reading location 0x000d, in case this helps? 0041F259 sub esp,0ACh 0041F25F mov edi,dword ptr [esp+0C4h] 0041F266 mov ebx,dword ptr [esp+0C0h] 0041F26D mov dword ptr [esp+68h],ebp 0041F271 testedi,edi 0041F273 je 0041F28A 0041F275 mov eax,dword ptr [esp+0C4h] 0041F27C movsx eax,word ptr [eax+4] 0041F280 shr eax,0Ah 0041F283 and eax,1 0041F286 mov dword ptr [esp+68h],eax 0041F28A xor ebp,ebp 0041F28C lea esi,[esi] 0041F290 mov eax,dword ptr ds:[00624278h] 0041F295 dec eax 0041F296 testeax,eax 0041F298 mov dword ptr ds:[00624278h],eax 0041F29D je 0041F36A 0041F2A3 cmp byte ptr [ebx],0B4h 0041F2A6 jbe 0041F360 0041F2AC mov dword ptr [esp+0Ch],0 0041F2B4 mov dword ptr [esp+8],0 0041F2BC mov dword ptr [esp+4],0 0041F2C4 mov dword ptr [esp],2336h 0041F2CB call0048C830 0041F2D0 movzx eax,word ptr ds:[6240F4h] 0041F2D7 testeax,eax 0041F2D9 je 0041F290 0041F2DB testal,4 0041F2DD je 0041F37F 0041F2E3 testebp,ebp 0041F2E5 je 0041F34C 0041F2E7 mov ebx,dword ptr ds:[6240F0h] 0041F2ED lea esi,[esi] 0041F2F0 mov ecx,dword ptr ds:[6240C8h] 0041F2F6 lea ebx,[ecx+ebx*4] 0041F2F9 mov eax,dword ptr ds:[006240C0h] 0041F2FE xchgax,ax 0041F300 cmp ebx,eax 0041F302 jae 0041F325 0041F304 sub eax,4 -recompiled my app with Harbour release 2.0 and tested, had no errors. Clipper also has no errors. -tryed various combinations and discovered issue is caused by latest HBMK2, as using HBMK2 from Version 2.0 distro, copying it to with latest SVN Harbour\Bin, rebuild app, test and appears to run fine with no more errors, does that make sense? Heinz Hi, First retest your app using latest Harbour (r14412 or newer) and see if it fixes these problems. Viktor -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28439752.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Could you post your complete hb_out.log? What extra libs do you use (-l hbmk2 options)? Viktor On 2010 May 3, at 22:15, Heinz V Bergen wrote: OK, using latest Harbour (r14422) and did a mingw32-make clean install, then recompiled my app with hbmk2 as console app, no GTs and tested, still got error. When Windows dialog to send error report, I clicked on debug window opening VS2005 debugger, showed error in disassembled code as Unhandled exception at 0x0041f2a3 in Hb2Ftr.exe: 0xC005: Access violation reading location 0x000d, in case this helps? 0041F259 sub esp,0ACh 0041F25F mov edi,dword ptr [esp+0C4h] 0041F266 mov ebx,dword ptr [esp+0C0h] 0041F26D mov dword ptr [esp+68h],ebp 0041F271 testedi,edi 0041F273 je 0041F28A 0041F275 mov eax,dword ptr [esp+0C4h] 0041F27C movsx eax,word ptr [eax+4] 0041F280 shr eax,0Ah 0041F283 and eax,1 0041F286 mov dword ptr [esp+68h],eax 0041F28A xor ebp,ebp 0041F28C lea esi,[esi] 0041F290 mov eax,dword ptr ds:[00624278h] 0041F295 dec eax 0041F296 testeax,eax 0041F298 mov dword ptr ds:[00624278h],eax 0041F29D je 0041F36A 0041F2A3 cmp byte ptr [ebx],0B4h 0041F2A6 jbe 0041F360 0041F2AC mov dword ptr [esp+0Ch],0 0041F2B4 mov dword ptr [esp+8],0 0041F2BC mov dword ptr [esp+4],0 0041F2C4 mov dword ptr [esp],2336h 0041F2CB call0048C830 0041F2D0 movzx eax,word ptr ds:[6240F4h] 0041F2D7 testeax,eax 0041F2D9 je 0041F290 0041F2DB testal,4 0041F2DD je 0041F37F 0041F2E3 testebp,ebp 0041F2E5 je 0041F34C 0041F2E7 mov ebx,dword ptr ds:[6240F0h] 0041F2ED lea esi,[esi] 0041F2F0 mov ecx,dword ptr ds:[6240C8h] 0041F2F6 lea ebx,[ecx+ebx*4] 0041F2F9 mov eax,dword ptr ds:[006240C0h] 0041F2FE xchgax,ax 0041F300 cmp ebx,eax 0041F302 jae 0041F325 0041F304 sub eax,4 -recompiled my app with Harbour release 2.0 and tested, had no errors. Clipper also has no errors. -tryed various combinations and discovered issue is caused by latest HBMK2, as using HBMK2 from Version 2.0 distro, copying it to with latest SVN Harbour\Bin, rebuild app, test and appears to run fine with no more errors, does that make sense? Heinz Hi, First retest your app using latest Harbour (r14412 or newer) and see if it fixes these problems. Viktor -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28439752.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Viktor Szakáts wrote: Hi All, Lately I mentioned having random GPFs with my live apps since changing to Harbour r14336. I also mentioned they are gone. This turned out not to be true, they are still present. ... Viktor Hello all, not sure if this is related but I have been fighting with random GPFs also. -was gui gtwvt app, and app would just close with no error, sometimes processing 1 iteration of an Import/Export process, sometimes crash after second. -compiled as non gui without GTWVT, but still got crashes, but now got an error message: Unrecoverable error 9019: Stack underflow and always on the same Return() statement, sometimes on 1st iteration, usually on the second one, but sometimes (rarely) 3rd or more. -compiled with debugger, now get different error: Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0041F2A3 EAX:ABB4 EBX:000D ECX: EDX:0004 ESI:00BC3874 EDI: EBP:0001 CS:EIP:001B:0041F2A3 SS:ESP:0023:0022F540 DS:0023 ES:0023 FS:003B GS: Flags:00010206 CS:EIP: 80 3B B4 0F 86 B4 00 00 00 C7 44 24 0C 00 00 00 SS:ESP: 00C331D8 03CF 000D 00C226B4 00CAD 7CC 0002 0001 0001 0052C81A 00CAD7CC 0002 00BC33DC 00C56A30 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... I don't really understand what this means, my guess is some process appears to be damaging the stack. If this is not related to issue, any idea what I need to look at to resolve issue? Thanks, Heinz -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28429001.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Hello Viktor,
On Apr 27, 2010, at 6:39 AM, Viktor Szakáts wrote:
Hi All,
Lately I mentioned having random GPFs with my live apps
since changing to Harbour r14336. I also mentioned they are
gone. This turned out not to be true, they are still present.
I have about 100KB of local .c code, which has been pretty
much static with only one benign change done in parallel with
Harbour upgrade, plus USHORT - HB_USHORT type migration.
The app uses GTWVT and it's built with mingw (tdm latest),
just as before.
GPF happens at random places, even in kernel, so it must
be some sort of memory corruption. Users report that many
times the problem happens when pasting into the application.
They experience that the app just closes, and I can't see
a GPF logged for all of these occasions. GPF can happen even
after short period of time spent in the application, with
little amount of activity.
It looks like something is lurking inside Harbour code,
and just by hunch one of my suspects is UNICODE mode build,
in relation with copy/paste, keyboard handling, or run
operations.
This is a very long shoot.
I had an GPF problem with an GUI app; this app is meant to run
mainly on Windows and using UNICODE,
The users reported a random GPF with different intervals of
running app time, places and so. I was unable to reproduce the
problem under Windows so I setup an Linux workstation meant
to run the Linux version of the app, and builded in debug mode
( at C/C++ level ) that's when the GPF showed in gdb.
The problem was originated by a wrong parameter call to the
'hb_cdpUTF8StringLength' function, and the program
sometimes stopped when executing that function and sometimes
in some other different places, so the conclusion was that it was
corrupting memory.
Bellow is the code snippet when the above funct is used:
c++ code
wxString wxh_CTowxString( const char * szStr, bool convOEM )
{
#ifdef _UNICODE
const wxMBConv mbConv = wxConvUTF8;
if( convOEM szStr )
{
ULONG ulStrLen = strlen( szStr );
PHB_CODEPAGE pcp = hb_vmCDP();
if( ulStrLen 0 pcp )
{
wxString wxStr;
ULONG ulUTF8Len = hb_cdpUTF8StringLength( szStr, ulStrLen );
char *strUTF8 = (char *) hb_xgrab( ulUTF8Len + 1 );
hb_cdpStrToUTF8( pcp, false, szStr, ulStrLen, (char *) strUTF8,
ulUTF8Len + 1 );
wxStr = wxString( strUTF8, mbConv );
hb_xfree( strUTF8 );
return wxStr;
}
}
#else
/c++ code
The wrong call was due to calling the function with an NIL
as parameter without checking for a valid CHAR param
passed:
c++ code
wxString wxh_parc( int param )
{
return wxh_CTowxString( hb_parc( param ), TRUE );
}
/c++ code
The fix was to check for a valid parameter ( not NIL ) being
send to the above function. In fact this problem would be solved
at PRG level but an protection at C++ level was also added too.
Any idea what to check, or where the problem can be?
I've reviewed some Harbour code, but could not yet spot
anything.
HTH
best regards,
Teo
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Hi Teo and All,
Thank you for your input. My code doesn't use any UTF8
calls, nor does it make any direct OS calls, or 3rd
party lib calls, it's pretty simple stuff, with extend/item
and GT API calls, only few .c level string manipulation,
and it has been checked using valgrind, too. It's not
very high suspect. (though I'd be happiest with zero line
of local .c code). I also use hbwin, but again only simple
stuff (no OLE, .dlls), and only in isolated places.
I will switch to non-UNICODE to see if this changes anything.
Viktor
On 2010 Apr 27, at 16:28, Teo Fonrouge wrote:
Hello Viktor,
On Apr 27, 2010, at 6:39 AM, Viktor Szakáts wrote:
Hi All,
[...]
It looks like something is lurking inside Harbour code,
and just by hunch one of my suspects is UNICODE mode build,
in relation with copy/paste, keyboard handling, or run
operations.
This is a very long shoot.
I had an GPF problem with an GUI app; this app is meant to run
mainly on Windows and using UNICODE,
The users reported a random GPF with different intervals of
running app time, places and so. I was unable to reproduce the
problem under Windows so I setup an Linux workstation meant
to run the Linux version of the app, and builded in debug mode
( at C/C++ level ) that's when the GPF showed in gdb.
The problem was originated by a wrong parameter call to the
'hb_cdpUTF8StringLength' function, and the program
sometimes stopped when executing that function and sometimes
in some other different places, so the conclusion was that it was
corrupting memory.
Bellow is the code snippet when the above funct is used:
c++ code
wxString wxh_CTowxString( const char * szStr, bool convOEM )
{
#ifdef _UNICODE
const wxMBConv mbConv = wxConvUTF8;
if( convOEM szStr )
{
ULONG ulStrLen = strlen( szStr );
PHB_CODEPAGE pcp = hb_vmCDP();
if( ulStrLen 0 pcp )
{
wxString wxStr;
ULONG ulUTF8Len = hb_cdpUTF8StringLength( szStr, ulStrLen );
char *strUTF8 = (char *) hb_xgrab( ulUTF8Len + 1 );
hb_cdpStrToUTF8( pcp, false, szStr, ulStrLen, (char *) strUTF8,
ulUTF8Len + 1 );
wxStr = wxString( strUTF8, mbConv );
hb_xfree( strUTF8 );
return wxStr;
}
}
#else
/c++ code
The wrong call was due to calling the function with an NIL
as parameter without checking for a valid CHAR param
passed:
c++ code
wxString wxh_parc( int param )
{
return wxh_CTowxString( hb_parc( param ), TRUE );
}
/c++ code
The fix was to check for a valid parameter ( not NIL ) being
send to the above function. In fact this problem would be solved
at PRG level but an protection at C++ level was also added too.
Any idea what to check, or where the problem can be?
I've reviewed some Harbour code, but could not yet spot
anything.
HTH
best regards,
Teo
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
