On Tue, 12 Feb 2008, Pritpal Bedi wrote:
> This message is asked in this group because I never received any
> clarification from xHarbour DL even after posting it for 3 times. Sorry, but
> it is urgent to be resolved as the large application of the organization I
> am employed with getting worst day-by-day. Again it is a "shifting" type of
> bug.
> The error info is like this:
> |-------------|GFR|X0607210E83E|Ar_32_18.exe|02/01/08|09:42:23|Site:08|Loc:40|
> Description #14: Variable does not exist
> Operation PRPREMIUM
> Alias() ESTIMATE, 140636, 0,
> .
> Called from: CN 3205
> Called from: PRE_REPLACE 1580
> Called from: REPLACE_REC 3762
> Called from: SAVE_RECORD 4315
> Called from: ADD 1316
> Called from: ARMENU:FNMENU_4 1278
> Called from: ARMENU:DO_MENU 1208
> Called from: ARMENU:CREATE 423
> Called from: ARMAINMENU 148
> Called from: MAIN_MENU 98
> Called from: APPLICATION 694
> |-------------------------------------------------|
> In the sources offending line is this:
> dbSelectArea( "estimate" )
> IF system('LOCK RECORD') // Just issues RLock()
> REPLACE prpremium WITH 0 // PPO: _FIELD->prpremium := 0
> REPLACE prrate WITH 0
> REPLACE prinsure WITH ' '
> REPLACE crprinsura WITH 0
> REPLACE subdep WITH ' '
> UNLOCK
> ENDIF
> The workaround is :
> SELECT estimate
> IF system('LOCK RECORD')
> Fieldput( nFieldNo, xValue )
> REPLACE prrate WITH 0
> REPLACE prinsure WITH ' '
> REPLACE crprinsura WITH 0
> REPLACE subdep WITH ' '
> UNLOCK
> ENDIF
> Fieldput() in place of REPLACE solves the issue. But then error shits to
> next REPLACE. After replacing for function call in this IF/ENDIF block,
> error shits its base.
Looks like dynamic symbol table corruption or sth wrong in
RDD you are using. I'm also not familiar with recent xHarbour
modifications so I cannot say if sth in core code was not
changed. Check what shows:
? fieldpos("prpremium"), "["+fieldname(nFieldNo)+"]"
before 1-st replace. Maybe it will help to locate more precisely
where is the problem.
Such problem can be result of some memory corruption. It's
possible that the same wrong code in Harbour causes the RT
error with destructor your reported. BTW do you use any
hb_gcAlloc() in your code?
> Because this application is so monester, it is hard to modify along these
> lines, a very tedious job plus lack of readability is preventing the
> management to go for this change. The error is so scattered and surfaces at
> so many places.
> I have almost finished of porting to Harbour but still due to some minor
> issues, I am not been able to post the application on production servers.
> Can you please guide me to locate what inside the compiler is causing this
> error ?
I'm afraid that I cannot give you any valuable information.
When Rodrigo reported that it has the problem in XHGTK code
I simply made:
grep -r hb_gcAlloc *
in XHGTK CVS tree and I've found an answer 10 seconds later.
But it was explicit call to hb_gcAlloc() wrongly used. If your
problem is caused by some memory corruption in other places
then it could be any C code you have in your project.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
