Hi Istvan, >> Overall I'm not sure this function should alter passed trace string in any > ways. > It can easily checked by reverting the change and trying to debug with > windbg, as I know the 'official' GUI debugger.
I'd appreciate if you could describe it, as I don't have such official debugger on my system, I used DbgView() for tests. If extra line ending (/r or /n or both) is required for windbg, it's easy to add it to printf() calls, although I'm still not sure why ending space trimming is required, or in which calls does this exactly causes problems. >> As for the anti-reentrance logic, it probably needs to be >> changed to mutexes, as in ST I can't see any way it can be >> called in recursive fashion, and in MT current solution will >> just delay problems by causing lost trace messages. > The original logic generates "stack overflow events" for example: > 1. " HB_TRACE( HB_TR_DEBUG, ( " new_QApplication > %i B %i KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );" > If fm.c and QApplication.cpp is build with -DHB_TR_LEVEL_DEBUG. > 2. If fm.c is requested with -DHB_TR_LEVEL_DEBUG. The HB_TCHAR_CONVTO macro > calls indirectly HB_TRACE, generating in this way the mentioned stack > overflow. Fortunately debugged with windbg. > 3. Generally we should not call inside the HB_TRACE a call to itself. You're right, now it's clear. In this case the solution is to replace HB_TCHAR_* macros with something native. I'll try to do it. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
