On Thu, 12 Mar 2009, Ron Pinkas wrote:
Hi,
> I still noticed some minor incompatibility which appears to be a Clipper
> bug, or at least I haven't been able to decipher the logic. IAE it manifests
> in very rare condition which I doubt any user is even aware of the odd
> behavior
Can you create any .prg example which gives different results in Clipper
then in Harbour?
For me the Clipper behavior is very simple.
CLEAR MEMORY called explicitly or indirectly by RESTORE FROM ...
without ADDITIVE clause clears all private variables and then all
public variables except GetList. That's all. At least in such
way works current Harbour HVM and I cannot find any incompatibilities
to Clipper here. The only one place where Harbour may give different
results then Clipper is fixed CLEAR MEMORY executed when some PRIVATE
variables exist. Clipper is seriously buggy here. xHarbour also though
the results of probably the same bug are different. Clipper gives
wrong values accessing some itmes freed before but not released by GC
and xHarbour usually GPFs though in the last years the GPF place was
changing. It's memory corruption bug so it's expected.
I was reporting this bug over two years ago to this list. You can find it
in the mail list archive.
Here is self contain example from the message I sent:
/*
* Unworking CLEAR MEMORY (this bug exists also in Clipper). In xHarbour
* it may give some unexpected results or GPF. In Harbour has been fixed.
*/
memvar V, V2
proc main()
local oErr
? "Clipper results:"
? "V:1 V:1 V:1"
? "V:2 V:2 V:2"
? "V:2 V:2"
? "V2:1 V2:1 V:3 V2:1"
? "L:1 L:1 V:3 L:1"
? "Variable V does not exist."
?
? "Expected results:"
? "V:1 V:1 V:1"
? "V:2 V:2 V:2"
? "V:2 V:2"
? "V:2 V:2 V:3 V2:1"
? "L:1 L:1 V:3 V2:1"
? "Variable V does not exist."
?
? "Current results:"
private V := "V:1"
f(@v)
errorblock({|oErr|break(oErr)})
? "Variable V "
begin sequence
?? "is:", V
recover using oErr
?? "does not exist."
end sequence
return
func f(l)
local cb:={||l}
? eval(cb), l, v
V := "V:2"
? eval(cb), l, v
CLEAR MEMORY
? eval(cb), l
private V2 := "V2:1"
private V := "V:3"
? eval(cb), l, v, v2
l:="L:1"
? eval(cb), l, v, v2
return cb
Just try this code with current xHarbour version.
Of course Instead of CLEAR MEMORY you can use RESTORE FROM without
ADDITIVE - it makes internally the same job - tries to clear all
existing memvar values.
Please also note that this bug may interact with your results when you are
testing what happens creating some chain of PRIVATE GetList variables and
then calling RESTORE FROM / CLEAR MEMORY.
> I'll be thankful if you can help me understand Clipper results for:
> //-------------------------------------------//
> MEMVAR GetLis
> PROCEDURE Main()
> ? ProcLine(), GetList
> PrivateGet()
> ? ProcLine(), GetList
> RETURN
> PROCEDURE PrivateGet()
> PRIVATE GetList := "Private"
> SAVE TO Test ALL
> OtherPrivateGet()
> ? ProcLine(), GetList
> RETURN // Should we not get back to PUBLIC visibility here?
We are at public visibility here. Just simply the public varible
GetList value is set by RESTORE FROM to "Private".
The problem is that xHarbour does not reset all memvars offsetes
pushed with function frames inside CLEAR MEMORY but releases all
existing memvars and then tries to restore them.
My example above shows what may happen in such case, f.e. it GPFs
with current xHarbour in Linux GCC builds.
> PROCEDURE OtherPrivateGet()
> RESTORE FROM Test //ADDITIVE
> ? ProcLine(), GetList
> RETURN
> INIT PROCEDURE MyInit()
> GetList := "Public"
> RETURN
I think you should start from fixing the xHarbour memvars code so the
example I sent will work without any problems giving expected results.
Below is result of valgrind test.
HTH
best regards,
Przemek
==27759== Invalid read of size 4
==27759== at 0x42735EA: hb_itemUnRef (itemapi.c:1437)
==27759== by 0x4284F52: hb_vmExecute (hvm.c:9309)
==27759== by 0x4285853: hb_vmDoBlock (hvm.c:7720)
==27759== by 0x4286575: hb_vmSend (hvm.c:7576)
==27759== by 0x428379E: hb_vmExecute (hvm.c:2037)
==27759== by 0x8048806: (within /tmp/20/t03)
==27759== by 0x428F571: hb_vmDo (hvm.c:7222)
==27759== by 0x4280DB1: hb_vmExecute (hvm.c:1662)
==27759== by 0x80487E9: (within /tmp/20/t03)
==27759== by 0x428F571: hb_vmDo (hvm.c:7222)
==27759== by 0x4290DA3: hb_vmInit (hvm.c:822)
==27759== by 0x424C52D: main (mainstd.c:86)
==27759== Address 0x0 is not stack'd, malloc'd or (recently) free'd
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
