On 04/26/2012 01:20 AM, Timothy Pearson wrote:
>> On 04/25/2012 11:08 PM, Calvin Morrison wrote:
>>> Err but if you're having problem getting line numbers, you should enable
>>> debugging with cmake flags. -DCMAKE_BUILD_TYPE i think it is and set it
>>> to equal
>>> DEBUG. that works for me at least.
>>
>> Crud, I forgot all about that. I'll check. The x updates make sense. If
>> fonts
>> are rendering differently then some possible buffer overrun... Who knows,
>> but I
>> can't explain the hang causing kwrite CPU use to spike to nearly 90%. That
>> little app?
> 
> Could be an Xorg glitch, an ABI problem in Xorg, or an indication of a
> more serious problem in TDE.  If you continue to experience problems after
> rebuilding and reinstalling tqt3 a bug report will need to be filed with
> detailed Xorg information from your system.
> 
> Tim
> 
> 

Tim,

  Testing different crash scenarios, I ran across another few entries in a
backtrace that I don't understand if the code is doing something wrong. I've
added the info to bug 979. What I found odd in the backtrace (crash occurred
simply opening a text file) was:

(gdb) bt
#0  0x00007f02d9b1c60e in isSpace (ch=...) at tools/qunicodetables_p.h:217
#1  0x00007f02d9b10a6c in TQChar::isSpace (this=0xed2b18) at tools/qstring.cpp:475

 What I don't understand is the char 9-13 range. I may be reading this wrong,
but the unicode chars 9-13 are (\t : tab, Unicode 9,  \n : linefeed, Unicode 10,
\v : vertical tab, Unicode 11, \f : formfeed, Unicode 12, \r : return, Unicode 13)

Why would 'isSpace' be returning 'TRUE' when the chars are not spaces or whitespace?

Well, what about the qstring.cpp error?:

	case Z_DATA_ERROR:
#if defined(QT_CHECK_RANGE)
	    tqWarning( "qUncompress: Z_DATA_ERROR: Input data is corrupted." );
475 #endif
	    break;

Could the fact that the isSpace may return something other than a space cause
this?? Something has changed, other than the packages in April, there was a late
March update of fontsproto:

[2012-03-25 02:04] upgraded fontsproto (2.1.1-2 -> 2.1.2-1)

I don't know what this package does, but most all of the crashes are related to
rendering (fonts I guess). If this package made a basic change in font rendering
(size/shape/spacing/etc..) could this cause the crashes we are seeing?

-- 
David C. Rankin, J.D.,P.E.