On 05/02/2012 09:00 PM, David C. Rankin wrote:
> Loaded symbols for /lib/libnss_files.so.2
> 0x00007f5859c98200 in isSpace () from /opt/tqt3/lib/libtqt-mt.so.3
> (gdb) bt
> #0  0x00007f5859c98200 in isSpace () from /opt/tqt3/lib/libtqt-mt.so.3
> #1  0x00007f585a0a6a6c in TQChar::isSpace (this=0x1c9b010) at tools/qstring.cpp:475
> #2  0x00007f5853f5ffc1 in KateRenderer::textWidth (this=0x1aa9210, textLine=...,
>     startcol=0, maxwidth=817, needWrap=0x7fffc9605ea8, endX=0x7fffc9605e9c)
>     at /build/src/tdelibs/kate/part/katerenderer.cpp:806
> #3  0x00007f5853f41674 in KateViewInternal::range (this=this@entry=0x1a66ce0,
>     realLine=realLine@entry=0, previous=previous@entry=0x0)
>     at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331
> #4  0x00007f5853f42b32 in KateViewInternal::range (this=this@entry=0x1a66ce0,
> realLine=0,
>     viewLine=viewLine@entry=1) at
> /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418

I guess the questions now becomes, given all of the backtraces and strace
information we have been able to collect, where does it point us to begin? IIRC,
Tim's bet is on tdelibs. What about Qt3? tdelibs more probable? Why?

As for looking at the code and looking for code that may violate a gcc coding
standard - what would you look for?

Out of all the backtraces I've looked at, the common entry seems to be:

> #2  0x00007f5853f5ffc1 in KateRenderer::textWidth (this=0x1aa9210, textLine=...,
>     startcol=0, maxwidth=817, needWrap=0x7fffc9605ea8, endX=0x7fffc9605e9c)
>     at /build/src/tdelibs/kate/part/katerenderer.cpp:806

Which, given the symptoms (editor OK until you paste or cursor down to a line
that wraps), seems to point to tdelibs/kate/part/katerenderer.cpp:806

    if (unicode[z].isSpace())

Is there something violative of some gcc standard in the way .isSpace is called?	

What about the TOChar::isSpace call at tools/qstring.cpp:475?

    return ::isSpace( *this );

Same question - anything apparently wrong with this? There were a log of gcc47
FTBFS surrounding needing to add 'this->' to distinguish who's function, etcc..
what being used in the multiple declaration and no forward declaration error.
Could one of those exist that gcc doesn't flag, but confuses the execution of
the code of whose this is the right 'this' for the program to perform without
crashing.

Many times looking at the code, especially where templates were used, gcc47
requires the explicit this-> where there are several templates used side by
side. Those areas look like a likely place for gcc to get confused with which
template is the 'this' template the compiler wants.

That's just ramblings at this point. We will actually need somebody to browse
the files that have veen flagged in the backraces to look at those areas and see
if anything stands out as being noncompliant. I could look all day at the same
file and not be able to tell compliant/noncompliant from a hole in the ground.
So I won't volunteer and give anyone any unjustified hope of me actually picking
something out.

What is the best approach here?


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