> Hi Viktor,
>
> Maybe reverting the hack for non win code too is useful temporarily, until
> the final solution designing. Maybe an RTE mechanism should be defined in non
> win part to avoid the reentrant call of the trace engine.
> This will signal the trap residing in the following code:
> HB_TRACE( HB_TR_DEBUG, ( " new_QApplication %i B
> %i KB", ( int )hb_xquery( 1001 ), hbqt_getmemused() ) );
> As I mentioned in one of my previous mail, the hb_xquery() calls the trace
> engine too, generating undesired behavior.
In this case hb_xquery() is evaluated _before_ calling trace engine,
so it shouldn't cause any problems.
Above code is equivalent to:
tmp = hb_xquery( 1001 )
HB_TRACE( HB_TR_DEBUG, ( "%i", tmp ) );
> The va_end() issue:
>
> Please analyze the following code snippets:
> …
> if( s_enabled && level <= hb_tr_level() )
> {
> va_list ap;
> va_start( ap, fmt );
> hb_tracelog_( level, file, line, proc, fmt, ap );
> va_end( ap );
> }
> …
> if( s_enabled )
> {
> va_list ap;
> va_start( ap, fmt );
> hb_tracelog_( hb_tr_level_, hb_tr_file_, hb_tr_line_, NULL, fmt, ap );
> va_end( ap );
> …
> So we can leave the:
> /*
> * Print the name and arguments for the function.
> */
> vfprintf( s_fp, fmt, ap );
>
> /* if( s_winout ) this is not necessary here */
> /* TOFIX: va_end() is _required_ here according to all available
> documentation. */
> /* va_end( ap ); Generates access violation in the subsequent hb_vsnprintf
> */
>
> without va_end();
Okay I get it, there is no va_start() in hb_tracelog_(),
so va_end() is not necessary. Thanks!
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
