On Tue, 29 Dec 2009, Bisz István wrote:
Hi,
> After testing with and without -DHB_TR_LEVEL_DEBUG cflags, it works as
> it is expected.
Thank you very much for your tests.
> In my test case the QApplication.cpp: line 212-214 contains:
> HB_TRACE( HB_TR_DEBUG, ( " new_QApplication %i B
> %i KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );
> and DbgView shows with HB_TR_LEVEL_DEBUG defined in fm.c:
> 00062246 17:42:34.462 [4612] c:\downloads\harbour\src\vm\fm.c:1187:
> HB_TR_DEBUG hb_xquery(1001)
> 00062247 17:42:34.462 [4612] c:\downloads\harbour\src\vm\fm.c:1187:
> (???) new_QApplication 0 B 3100 KB
> My test results:
> 1. Analyzing the output produced by the line 212 we can see that the file,
> line and level info is altered. Maybe is useful to send here the original
> info instead of hb_xquery trace location.
It's not hb_xquery() problem. The same will happen for any function
which internally calls HB_TRACE() and is used as parameter of some
other HB_TRACE() message.
In general it's side effect of keeping the file name and the line number
in global variables hb_tr_file_ and hb_tr_line_. Also trace massage level
is stored in global variable so it can be overwritten in final message
though fortunately it does not change the message filter condition.
Such solution is neither reentrant safe (problems like above) nor MT
safe. We need it for two reasons:
1. to set file name and line number for memory statistics
2. as workaround for limited C preprocessor functionality
The 1-st one we can ignore. It's not very important in current days
because we have other more precise methods to detect memory leaks
with exact allocation places like valgrind instead of showing the
last place where HB_TRACE() message. Anyhow if someone wants then
we can try to make it MT safe by moving above variables to HVM stack.
The 2-nd one is bigger problem. Only C99 defines macros with variable
number of arguments so it may be hard to find clean portable method
which will not use any global/static variables without allocating
buffer for message on C stack what may cause serious problems for
total C stack usage.
Now in macro HB_TRACE( l, x ) we use x with additional () so for C
preprocessor it's like one parameter and we can define it like:
#define HB_TRACE( l, x ) hb_tr_trace x
and then use it as:
HB_TRACE( HB_TR_INFO, ( "msg %d, %d, %d", 1, 2, 3 ) );
It works but such trick does not allow to insert new parameters to x
so we cannot switch to hb_tracelog() function. This can be done
using ISO C99 __VA_ARGS__ macro, i.e.:
#define hb_tr_trace_( ... ) __VA_ARGS__
#define HB_TRACE( l, x ) hb_tracelog( l, __FILE__, __LINE__, \
NULL, hb_tr_trace_ x )
Some C compilers have their own extensions with macros having variable
number of parameters, i.e. using GCC we can define hb_tr_trace_ as:
#define hb_tr_trace_( args... ) args
but still it's not widely portable solution.
> 2. The insertion of the hb_xtraced function in nortl.c it was necessary
> to build harbour with HB_TR_LEVEL_DEBUG defined:
Yes, it has to be added. I'll commit it in a while, thank you for the info.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
