Message: previous - next
Month: April 2012

qunicodetables_p.h? [was Re: [trinity-devel] Re: New kwrite crashes with yesterdays builds of tdelibs/tdebase]

From: "David C. Rankin" <drankinatty@...>
Date: Sat, 28 Apr 2012 01:54:35 -0500
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


  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?:

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

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.