Hi Viktor, > 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.
> 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. Best regards, István -----Original Message----- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts Sent: 2009. december 27. 22:40 To: Harbour Project Main Developer List. Subject: Re: [Harbour] Re: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c Hi, > Hi Viktor, > > This solution strips the trailing isspace characters from the debug info and > inserts the necessary CR/LF for windbg, not more. > Maybe we can define here a lot of similar solutions for the same thing. One problem with this is that it's now implemented as a Windows-only solution. (BTW I don't really understand why Windows debugging needs are _always_ different from any other platforms...). Overall I'm not sure this function should alter passed trace string in any ways. Proper fix IMO is to change those trace calls which pass ending spaces. There is probably not too many of them. 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. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
