Reduced sample that shows GPF running HRB files with FWH

[Patrick Mast]

Hello,

This ZIP file: http://www.xHarbour.net/Test_HRB.zip
Contains a reduced sample that shows a GPF when using HRB files with xHarbour Builder + FWH.

Test.prg try's to run the HRB script 'TestScript.hrb' 20 times. Sometimes the GPF occurs after running the HRB 8 times, sometimes after running it 10 times.

This is what Test.prg contains (Compile to EXE):

Code: Select all  Expand view  RUN

#include "fivewin.ch"

PROCEDURE Main
LOCAL oScript,f

   FOR f=1 TO 10
      ? f
      oScript:=__hrbLoad( "testScript.hrb" )
      __hrbDo( oScript )
      __hrbUnload( oScript )
   NEXT

RETURN


This is TestScript.prg (Compile to a HRB)

Code: Select all  Expand view  RUN

PROCEDURE Test_Static()
   LOCAL aTemp, ff
     
   aTemp:={ {1, "111111111"}, ;
            {2, "222222222"}, ;
            {3, "333333333"}  }

   ff:=Test_AScan(aTemp)
   
   Alert("Test")
   
RETURN

STATIC FUNCTION Test_AScan(aTemp)   
RETURN AScan(aTemp, {|x| x[ 2]="222222222"})


The compiled 'Test.exe' and 'TestScript.HRB' files are here:
http://www.xHarbour.net/Test_HRB_Binaries.zip

If I compile the exact same files without FWH (simple delete the '#include "fivewin.ch"' line and recompile), the GPF does not happen.

Antonio, can you please take a look at this?

Thanks!

Patrick

[Antonio Linares]

Patrick,

Please change Alert() into MsgAlert() and try it again, thanks

[Patrick Mast]

Please change Alert() into MsgAlert() and try it again, thanks

Thanks for looking at it Antonio, but that's not the point. I know, if you change something in the script it does not GPF anymore.

Problem is the GPF itself. Test.exe should NOT GPF. This is a sample that shows that there is something wrong running a HRB in xHarbour Builder + FWH. I'm not blaming FWh, or xHarbour Builder or anyone else, I just try to find the cause and a fix.

If you for example change the STATIC FUNCTION in the script with FUNCTION, it also does not GPF. But again, that's not the point. I have several scripts that GPF in my WinFakt app, it's just random and thus very hard to find why winfakt.exe GPF's. I found out that this reduced sample shows WHY my app GPF's.

So, we don't need to change the script, we need to find WHy it GPF's and than fix that.

Thanks again for looking at it Antonio.

Patrick

[Antonio Linares]

Patrick,

> if you change something in the script it does not GPF anymore.

Then it is not a FWH issue. Its a HRB issue.

You should be able to trace it and fix it. Or aren't you the Patrick Mast that sells commercial xHarbour ?

[Patrick Mast]

> if you change something in the script it does not GPF anymore.

Then it is not a FWH issue. Its a HRB issue.

You should be able to trace it and fix it. Or aren't you the Patrick Mast that sells commercial xHarbour ?

Exact the same code without FWh does not GPF.

Patrick

[Antonio Linares]

Patrick,

I told you to replace Alert() with MsgAlert() and test it. Do it please

FWH is not related to HRB files at all. If you get a GPF is simply because the global symbols table grows and thats a HRB issue not FWH's

[Patrick Mast]

I told you to replace Alert() with MsgAlert() and test it. Do it please

FWH is not related to HRB files at all. If you get a GPF is simply because the global symbols table grows and thats a HRB issue not FWH's

Ok, I will try to make more tests and see where it GPF's in other situations.

Patrick