Hi Xavi, > Sorry but ... What this issue has to do with this code?
No, the mentioned code serves just WinDbg, I tested it with DbgView too. But after the latest commits it's obsolete. > Please, to which I can understand and sorry for my bad English. > Do you saying that windbg generate issue because the string does not end with CR/LF. No, you misunderstood me, sorry. The mentioned crash is related to an another patch, trying to solve the case when inside a HB_TRACE an another HB_TRACE is activated. Best regards, István -----Original Message----- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Xavi Sent: 2009. december 28. 1:18 To: Harbour Project Main Developer List. Subject: Re: [Harbour] Re: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c El 27/12/2009 23:12, Bisz István escribió: > 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. Sorry but ... What this issue has to do with this code? ... /* * Normalize buffer2 with ending CR/LF/NUL */ p = buffer2; p += (n < 0) ? sizeof( buffer2 ) - 3 : n; while ( p > buffer2 && isspace( p[-1] ) ) { *--p = '\0'; } *p++ = '\r'; *p++ = '\n'; *p = '\0'; ... > If it is necessary we can generate here a flexible solution with and without > CR/LF, selectable by the existing HB_TR_WINOUT envvar. Please, to which I can understand and sorry for my bad English. Do you saying that windbg generate issue because the string does not end with CR/LF. TIA, -- Xavi El 28/12/2009 0:43, Bisz István escribió: > Hi Viktor, > >> I'd appreciate if you could describe it, as I don't have such >> official debugger on my system, I used DbgView() for tests. > > The windbg in a component of "Microsoft Windows SDK for Windows 7 and .NET > Framework 3.5 SP1" / "Debugging tools for Windows". > Dbgview is just a very useful viewer. I tested it and I cannot see any > differences comparing with the previous solution without CR/LF insertion. > If it is necessary we can generate here a flexible solution with and without > CR/LF, selectable by the existing HB_TR_WINOUT envvar. > >> 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. > > An any optimized solution is welcome, with the original solution the debug > messages are shown without line-feeds. > >> 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. > > We need here a general solution taking into consideration the all possible > situations when HB_TRACE is called indirectly in HB_TRACE. > > Best regards, > István > _______________________________________________ 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
