Przemek,
Many thanks for the sample, It should be fixed after: 2009-03-13 23:58
UTC-0430 Ron Pinkas <ron/at/xharbour.com>. Please let me know if I missed
something.
In my tests of Clipper's protection of GetList, I did encounter some
unexplainable results, but sadly I did not keep those tests. IIRC some of
the oddities involved using the ADDITIVE clause, with and without a
restorable value for GetList. Additionally it seems I confused CLEAR ALL
with CLEAR MEMORY, in some tests, which apparently threw me off, due to
inclusion of GetList := {} in translation of that command.
Again, many thanks for your assistance.
Ron
--------------------------------------------------
From: "Przemyslaw Czerpak" <dru...@acn.waw.pl>
Sent: Thursday, March 12, 2009 11:28 AM
To: "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>
Subject: Re: [xHarbour-developers] Upper() and codepage.
> 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
>
------------------------------------------------------------------------------
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
