3 May
2012
3 May
'12
2 a.m.
Tim, Darrell, all
It's confirmed - the same kwrite crash occurs when the 3/29 sources are
rebuilt on gcc 4.7. We are challenged with what will be a fun bug hunt that will
take a skilled dev who is familiar with this type of debug. I did have full
debug built into the packages and here is the backtrace. I'm at a standstill. I
know not where to go next. Experts, please weigh in....
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
#5 0x00007f5853f444c9 in KateViewInternal::viewLineOffset
(this=this@entry=0x1a66ce0,
virtualCursor=..., offset=0, keepX=keepX@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1578
#6 0x00007f5853f47d25 in KateViewInternal::makeVisible
(this=this@entry=0x1a66ce0, c=...,
endCol=115, force=force@entry=false, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:781
#7 0x00007f5853f48352 in KateViewInternal::updateCursor (this=this@entry=0x1a66ce0,
newCursor=..., force=force@entry=true, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2204
#8 0x00007f5853f4c4c0 in KateViewInternal::editEnd (this=0x1a66ce0,
editTagLineStart=0,
editTagLineEnd=<optimized out>, tagFrom=<optimized out>)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:3385
#9 0x00007f5853ee8ef0 in KateDocument::editEnd (this=0x199d150)
at /build/src/tdelibs/kate/part/katedocument.cpp:1032
#10 0x00007f5853ee2f5b in KateDocument::paste (this=0x199d150, view=0x1aa6630)
at /build/src/tdelibs/kate/part/katedocument.cpp:3249
#11 0x00007f5853f1aa53 in KateView::paste (this=0x1aa6630)
at /build/src/tdelibs/kate/part/kateview.cpp:1597
#12 0x00007f5853f4a102 in KateViewInternal::mouseReleaseEvent (this=0x1a66ce0,
e=0x7fffc96067b0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2965
#13 0x00007f5859de2343 in TQWidget::event (this=0x1a66ce0, e=0x7fffc96067b0)
at kernel/qwidget.cpp:4725
#14 0x00007f5859d4c559 in TQApplication::internalNotify (this=0x7fffc9607010,
receiver=
0x1a66ce0, e=0x7fffc96067b0) at kernel/qapplication.cpp:2638
#15 0x00007f5859d4bbe3 in TQApplication::notify (this=0x7fffc9607010,
receiver=0x1a66ce0,
e=0x7fffc96067b0) at kernel/qapplication.cpp:2424
#16 0x00007f585ad045c4 in KApplication::notify (this=0x7fffc9607010,
receiver=0x1a66ce0,
event=0x7fffc96067b0) at /build/src/tdelibs/tdecore/kapplication.cpp:583
#17 0x00007f5859cde6b3 in TQApplication::sendSpontaneousEvent (receiver=0x1a66ce0,
event=0x7fffc96067b0) at kernel/ntqapplication.h:526
#18 0x00007f5859cd7f53 in TQETWidget::translateMouseEvent (this=0x1a66ce0,
event=0x7fffc9606cc0) at kernel/qapplication_x11.cpp:4380
#19 0x00007f5859cd5871 in TQApplication::x11ProcessEvent (this=0x7fffc9607010,
event=0x7fffc9606cc0) at kernel/qapplication_x11.cpp:3557
#20 0x00007f5859cf0c44 in TQEventLoop::processEvents (this=0x18e3e80, flags=4)
at kernel/qeventloop_x11.cpp:195
#21 0x00007f5859d5f818 in TQEventLoop::enterLoop (this=0x18e3e80)
at kernel/qeventloop.cpp:201
#22 0x00007f5859d5f6e9 in TQEventLoop::exec (this=0x18e3e80) at
kernel/qeventloop.cpp:148
#23 0x00007f5859d4c689 in TQApplication::exec (this=0x7fffc9607010)
at kernel/qapplication.cpp:2761
#24 0x00007f585e0303a8 in kdemain (argc=1, argv=0x7fffc96075e8)
at /build/src/tdebase/kate/app/kwritemain.cpp:692
#25 0x000000000040082c in main (argc=1, argv=0x7fffc96075e8)
at /build/src/build/kate/app/kwrite_tdeinit_executable.cpp:2
(gdb)
--
David C. Rankin, J.D.,P.E.
3 May
3 May
2:10 a.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/02/2012 09:00 PM, David C. Rankin wrote:
I'm at a standstill. I
know not where to go next. Experts, please weigh in....
I've also posted the issue to both the opensuse-kde3 and opensuse-factory lists
to apprise them of the potential gcc 4.7 issue. Hopefully, with more eyes on the
issue, the greater the potential for swift resolution...
--
David C. Rankin, J.D.,P.E.
4:11 a.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
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.
7:51 a.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On Wed, 02 May 2012 23:11:20 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
On 05/02/2012 09:00 PM, David C. Rankin wrote:
1) This seems to be an infinite loop in
katerenderer.cpp
2) The z which governs the loop isn't changed inside the loop*
so it looks like a code generation bug.
Can you do
$ gcc -S -fverbose-asm -I??? <FLAGS> katerenderer.cpp
where I??? are the include paths needed to make the file compile,
FLAGS are the CXXFLAGS you usually use to compile and then send
katerenderer.s to the list ?
*If somebody isn't convinced they can apply this patch:
diff --git a/kate/part/katerenderer.cpp b/kate/part/katerenderer.cpp
index 48b73d7..bbe5426 100644
--- a/kate/part/katerenderer.cpp
+++ b/kate/part/katerenderer.cpp
@@ -790,9 +790,10 @@ uint KateRenderer::textWidth(const KateTextLine::Ptr &textLine,
uint startcol, u
const TQChar *unicode = textLine->text();
const TQString &textString = textLine->string();
- uint z = startcol;
- for (; z < len; z++)
+ uint zz = startcol;
+ for (; zz < len; zz++)
{
+ const uint z = zz;
KateAttribute* a = attribute(textLine->attribute(z));
int width = a->width(*fs, textString, z, m_tabWidth);
Q_ASSERT(width);
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?
7:52 a.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On Thu, 3 May 2012 09:51:19 +0200
/dev/ammo42 <mickeytintincolle(a)yahoo.fr> wrote:
On Wed, 02 May 2012 23:11:20 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
It obviously reads
$ g++ ...
On 05/02/2012 09:00 PM, David C. Rankin wrote:
1) This seems to be an infinite loop in
katerenderer.cpp
2) The z which governs the loop isn't changed inside the loop*
so it looks like a code generation bug.
Can you do
$ gcc -S -fverbose-asm -I??? <FLAGS> katerenderer.cpp 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? where I??? are the include paths needed to make the
file compile,
FLAGS are the CXXFLAGS you usually use to compile and then send
katerenderer.s to the list ?
*If somebody isn't convinced they can apply this patch:
diff --git a/kate/part/katerenderer.cpp b/kate/part/katerenderer.cpp
index 48b73d7..bbe5426 100644
--- a/kate/part/katerenderer.cpp
+++ b/kate/part/katerenderer.cpp
@@ -790,9 +790,10 @@ uint KateRenderer::textWidth(const
KateTextLine::Ptr &textLine, uint startcol, u const TQChar *unicode =
textLine->text(); const TQString &textString = textLine->string();
- uint z = startcol;
- for (; z < len; z++)
+ uint zz = startcol;
+ for (; zz < len; zz++)
{
+ const uint z = zz;
KateAttribute* a = attribute(textLine->attribute(z));
int width = a->width(*fs, textString, z, m_tabWidth);
Q_ASSERT(width);
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
6:53 a.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
This might be a stupid question, but did you try to run kwirte with valgrind?
Nik
Am Donnerstag, 3. Mai 2012 schrieb David C. Rankin:
Tim, Darrell, all
It's confirmed - the same kwrite crash occurs when the 3/29 sources are
rebuilt on gcc 4.7. We are challenged with what will be a fun bug hunt that
will take a skilled dev who is familiar with this type of debug. I did have
full debug built into the packages and here is the backtrace. I'm at a
standstill. I know not where to go next. Experts, please weigh in....
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
#5 0x00007f5853f444c9 in KateViewInternal::viewLineOffset
(this=this@entry=0x1a66ce0,
virtualCursor=..., offset=0, keepX=keepX@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1578
#6 0x00007f5853f47d25 in KateViewInternal::makeVisible
(this=this@entry=0x1a66ce0, c=...,
endCol=115, force=force@entry=false, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:781
#7 0x00007f5853f48352 in KateViewInternal::updateCursor
(this=this@entry=0x1a66ce0, newCursor=..., force=force@entry=true,
center=center@entry=false, calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2204
#8 0x00007f5853f4c4c0 in KateViewInternal::editEnd (this=0x1a66ce0,
editTagLineStart=0,
editTagLineEnd=<optimized out>, tagFrom=<optimized out>)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:3385
#9 0x00007f5853ee8ef0 in KateDocument::editEnd (this=0x199d150)
at /build/src/tdelibs/kate/part/katedocument.cpp:1032
#10 0x00007f5853ee2f5b in KateDocument::paste (this=0x199d150,
view=0x1aa6630) at /build/src/tdelibs/kate/part/katedocument.cpp:3249
#11 0x00007f5853f1aa53 in KateView::paste (this=0x1aa6630)
at /build/src/tdelibs/kate/part/kateview.cpp:1597
#12 0x00007f5853f4a102 in KateViewInternal::mouseReleaseEvent
(this=0x1a66ce0, e=0x7fffc96067b0) at
/build/src/tdelibs/kate/part/kateviewinternal.cpp:2965 #13
0x00007f5859de2343 in TQWidget::event (this=0x1a66ce0, e=0x7fffc96067b0) at
kernel/qwidget.cpp:4725
#14 0x00007f5859d4c559 in TQApplication::internalNotify
(this=0x7fffc9607010, receiver=
0x1a66ce0, e=0x7fffc96067b0) at kernel/qapplication.cpp:2638
#15 0x00007f5859d4bbe3 in TQApplication::notify (this=0x7fffc9607010,
receiver=0x1a66ce0,
e=0x7fffc96067b0) at kernel/qapplication.cpp:2424
#16 0x00007f585ad045c4 in KApplication::notify (this=0x7fffc9607010,
receiver=0x1a66ce0,
event=0x7fffc96067b0) at
/build/src/tdelibs/tdecore/kapplication.cpp:583 #17 0x00007f5859cde6b3 in
TQApplication::sendSpontaneousEvent (receiver=0x1a66ce0,
event=0x7fffc96067b0) at kernel/ntqapplication.h:526
#18 0x00007f5859cd7f53 in TQETWidget::translateMouseEvent (this=0x1a66ce0,
event=0x7fffc9606cc0) at kernel/qapplication_x11.cpp:4380
#19 0x00007f5859cd5871 in TQApplication::x11ProcessEvent
(this=0x7fffc9607010, event=0x7fffc9606cc0) at
kernel/qapplication_x11.cpp:3557
#20 0x00007f5859cf0c44 in TQEventLoop::processEvents (this=0x18e3e80,
flags=4) at kernel/qeventloop_x11.cpp:195
#21 0x00007f5859d5f818 in TQEventLoop::enterLoop (this=0x18e3e80)
at kernel/qeventloop.cpp:201
#22 0x00007f5859d5f6e9 in TQEventLoop::exec (this=0x18e3e80) at
kernel/qeventloop.cpp:148
#23 0x00007f5859d4c689 in TQApplication::exec (this=0x7fffc9607010)
at kernel/qapplication.cpp:2761
#24 0x00007f585e0303a8 in kdemain (argc=1, argv=0x7fffc96075e8)
at /build/src/tdebase/kate/app/kwritemain.cpp:692
#25 0x000000000040082c in main (argc=1, argv=0x7fffc96075e8)
at /build/src/build/kate/app/kwrite_tdeinit_executable.cpp:2
(gdb)
12:38 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 01:53 AM, Mag. Dr. Nikolaus Klepp wrote:
This might be a stupid question, but did you try to
run kwirte with valgrind?
Nik
There are no stupid questions when it comes to "did I do something?" The answer
is probably no... I'm a great monkey on this side of the keyboard, but I'm not a
career developer, so you guys that have ideas of what needs to be done, just ask
and I can carry it out on this end. I'll give valgrind a go and let you know as
well as the g++ command suggested by /dev/ammo42.
--
David C. Rankin, J.D.,P.E.
1:28 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 07:38 AM, David C. Rankin wrote:
On 05/03/2012 01:53 AM, Mag. Dr. Nikolaus Klepp
wrote:
OK,
What tool in valgrind is the one we want? I tried cachegrind and that didn't
produce anything:
08:09 valkyrie:~> valgrind --tool=cachegrind kwrite
==1042== Cachegrind, a cache and branch-prediction profiler
==1042== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==1042== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==1042== Command: kwrite
==1042==
Killed
The strange thing was I could open long files in kwrite and cursor down
without a crash when running in valgrind. However, pasting until the line
wrapped caused the crash as normal. Let me know what the valgrind command line
should look like. Or, is trying to run valgrind in virtualbox not going to work
to begin with?
--
David C. Rankin, J.D.,P.E.
This might be a stupid question, but did you try
to run kwirte with valgrind?
Nik
There are no stupid questions when it comes to "did I do something?" The
answer
is probably no... I'm a great monkey on this side of the keyboard, but I'm not a
career developer, so you guys that have ideas of what needs to be done, just ask
and I can carry it out on this end. I'll give valgrind a go and let you know as
well as the g++ command suggested by /dev/ammo42.
3:31 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
08:09 valkyrie:~> valgrind --tool=cachegrind
kwrite
==1042== Cachegrind, a cache and branch-prediction profiler
==1042== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et
al. ==1042== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
info ==1042== Command: kwrite
==1042==
Killed
The strange thing was I could open long files in kwrite and cursor down
without a crash when running in valgrind. However, pasting until the line
wrapped caused the crash as normal. Let me know what the valgrind command
line should look like. Or, is trying to run valgrind in virtualbox not
going to work to begin with?
Could you try "helgrind" as a tool? What you see is most likely a crash in an
other thread.
I usually work my way through all tools that in valgrind, beginning with
memcheck (the default), then helgring, callgrind ... simply down the list
http://www.valgrind.org/docs/manual/manual.html - and I do not use virtualbox
for debugging (but I don't know if it matters).
Nik
5:55 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 07:38 AM, David C. Rankin wrote:
<snip>
I would use the default memchecker tool, as my initial guess would be
memory corruption based on the widely varied backtraces.
Tim
On 05/03/2012 01:53 AM, Mag. Dr. Nikolaus Klepp
wrote:
OK,
What tool in valgrind is the one we want? I tried cachegrind and that
didn't
produce anything: This might be a stupid question, but did you try
to run kwirte with
valgrind?
Nik
There are no stupid questions when it comes to "did I do something?" The
answer
is probably no... I'm a great monkey on this side of the keyboard, but
I'm not a
career developer, so you guys that have ideas of what needs to be done,
just ask
and I can carry it out on this end. I'll give valgrind a go and let you
know as
well as the g++ command suggested by /dev/ammo42.
6:16 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 12:55 PM, Timothy Pearson wrote:
Tim, Doc, will do,
I should have more time this evening to work with valgrind. I have little
familiarity with it, so I'll just run it successively with the various tools and
post any output I get.
Any other tests you can think of, just let me know.
--
David C. Rankin, J.D.,P.E.
On 05/03/2012
07:38 AM, David C. Rankin wrote:
<snip>
I would use the default memchecker tool, as my initial guess would be
memory corruption based on the widely varied backtraces.
Tim
On 05/03/2012 01:53 AM, Mag. Dr. Nikolaus Klepp
wrote:
OK,
What tool in valgrind is the one we want? I tried cachegrind and that
didn't
produce anything: This might be a stupid question, but did you try
to run kwirte with
valgrind?
Nik
There are no stupid questions when it comes to "did I do something?" The
answer
is probably no... I'm a great monkey on this side of the keyboard, but
I'm not a
career developer, so you guys that have ideas of what needs to be done,
just ask
and I can carry it out on this end. I'll give valgrind a go and let you
know as
well as the g++ command suggested by /dev/ammo42.
6:50 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 12:55 PM, Timothy Pearson wrote:
Tim, Doc, will do,
I should have more time this evening to work with valgrind. I have
little
familiarity with it, so I'll just run it successively with the various
tools and
post any output I get.
Any other tests you can think of, just let me know.
Just make sure you have the debugging symbols installed so that we can get
line numbers, and that you have compiled from either the latest GIT head
or a recent revision, preferably one with the gcc 4.7 fixes in place.
It would be a good idea to post the valgrind output to the bug report.
Tim
On
05/03/2012 07:38 AM, David C. Rankin wrote:
<snip>
I would use the default memchecker tool, as my initial guess would be
memory corruption based on the widely varied backtraces.
Tim
On 05/03/2012 01:53 AM, Mag. Dr. Nikolaus Klepp
wrote:
> This might be a stupid question, but did you try to run kwirte with
> valgrind?
>
> Nik
There are no stupid questions when it comes to "did I do something?"
The
answer
is probably no... I'm a great monkey on this side of the keyboard, but
I'm not a
career developer, so you guys that have ideas of what needs to be
done,
just ask
and I can carry it out on this end. I'll give valgrind a go and let
you
know as
well as the g++ command suggested by /dev/ammo42.
OK,
What tool in valgrind is the one we want? I tried cachegrind and that
didn't
produce anything:
7:15 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 01:50 PM, Timothy Pearson wrote:
Just make sure you have the debugging symbols
installed so that we can get
line numbers, and that you have compiled from either the latest GIT head
or a recent revision, preferably one with the gcc 4.7 fixes in place.
It would be a good idea to post the valgrind output to the bug report.
Tim
How do I turn debugging on for tqt3?
I have:
./configure \
-prefix ${_prefix} \
-sysconfdir /etc/tqt \
-I/usr/include/mysql \
-I/usr/include/postgresql/server \
-I/usr/include/libiodbc \
<snip>
-no-ipv6 \
-debug
But I don't get line numbers for tqt3. I get them for tdelibs, etc..:
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
What's the trick for tqt3?
--
David C. Rankin, J.D.,P.E.
7:20 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On Thu, 03 May 2012 14:15:43 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
On 05/03/2012 01:50 PM, Timothy Pearson wrote:
If you can mandate custom CXXFLAGS, just adding
"-g" to them should
suffice.
Just make sure you have the debugging symbols
installed so that we
can get line numbers, and that you have compiled from either the
latest GIT head or a recent revision, preferably one with the gcc
4.7 fixes in place.
It would be a good idea to post the valgrind output to the bug
report.
Tim
How do I turn debugging on for tqt3?
I have:
./configure \
-prefix ${_prefix} \
-sysconfdir /etc/tqt \
-I/usr/include/mysql \
-I/usr/include/postgresql/server \
-I/usr/include/libiodbc \
<snip>
-no-ipv6 \
-debug
But I don't get line numbers for tqt3. I get them for tdelibs, etc..:
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
What's the trick for tqt3?
7:34 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On Thu, 3 May 2012 21:26:50 +0200
"Mag. Dr. Nikolaus Klepp" <office(a)klepp.biz> wrote:
and turn any optimisation off :-)
According to the GCC manual pages -O1 implies -fomit-frame-pointer only
if it doesn't interfere with debugging, so it should be safe.
Also -fomit-frame-pointer can be reversed by -fno-omit-frame-pointer.
What's the trick for tqt3?
If you can mandate custom CXXFLAGS, just adding "-g" to them should
suffice.
nik
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
7:56 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 02:34 PM, /dev/ammo42 wrote:
On Thu, 3 May 2012 21:26:50 +0200
"Mag. Dr. Nikolaus Klepp"<office(a)klepp.biz> wrote:
OK, got it CXXFLAGS="${CXXFLAGS} -g -01"
Any other tweaks yo can think of and I'll add them. Thanks.
--
David C. Rankin, J.D.,P.E.
>> > > > What's the trick
for tqt3?
> > >
> > > If you can mandate custom CXXFLAGS, just adding "-g" to them
should
> > > suffice.
>
> and turn any optimisation off :-)
According to the GCC manual pages -O1
implies -fomit-frame-pointer only
if it doesn't interfere with debugging, so it should be safe.
Also -fomit-frame-pointer can be reversed by -fno-omit-frame-pointer.
> >
> > nik
> >
8:04 p.m.
New subject: [trinity-devel] kwrite crash - it's gcc 4.7 - rebuilt 3/29 sources on gcc 4.7 - same crash
On 05/03/2012 02:56 PM, David C. Rankin wrote:
On 05/03/2012 02:34 PM, /dev/ammo42 wrote:
What about the QMAKE variables. Is there any need to specify them as well in a
patch or something?
QMAKE_CFLAGS = -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden
QMAKE_CFLAGS_DEPS = -M
QMAKE_CFLAGS_WARN_ON = -Wall -W
QMAKE_CFLAGS_WARN_OFF = -w
QMAKE_CFLAGS_RELEASE = -O2
QMAKE_CFLAGS_DEBUG = -O0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
QMAKE_CFLAGS_SHLIB = -fPIC
QMAKE_CFLAGS_YACC = -Wno-unused -Wno-parentheses
QMAKE_CFLAGS_THREAD = -D_REENTRANT
QMAKE_CXX = g++
QMAKE_CXXFLAGS = $$QMAKE_CFLAGS
QMAKE_CXXFLAGS_DEPS = $$QMAKE_CFLAGS_DEPS
QMAKE_CXXFLAGS_WARN_ON = $$QMAKE_CFLAGS_WARN_ON
QMAKE_CXXFLAGS_WARN_OFF = $$QMAKE_CFLAGS_WARN_OFF
QMAKE_CXXFLAGS_RELEASE = $$QMAKE_CFLAGS_RELEASE
QMAKE_CXXFLAGS_DEBUG = $$QMAKE_CFLAGS_DEBUG
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
QMAKE_CXXFLAGS_SHLIB = $$QMAKE_CFLAGS_SHLIB
QMAKE_CXXFLAGS_YACC = $$QMAKE_CFLAGS_YACC
QMAKE_CXXFLAGS_THREAD = $$QMAKE_CFLAGS_THREAD
--
David C. Rankin, J.D.,P.E.
On Thu, 3 May 2012 21:26:50 +0200
"Mag. Dr. Nikolaus Klepp"<office(a)klepp.biz> wrote:
OK, got it CXXFLAGS="${CXXFLAGS} -g -01"
Any other tweaks yo can think of and I'll add them. Thanks.
>> > > > What's the trick for
tqt3?
> > >
> > > If you can mandate custom CXXFLAGS, just adding "-g" to them
should
> > > suffice.
>
> and turn any optimisation off :-)
According to the GCC manual pages -O1
implies -fomit-frame-pointer only
if it doesn't interfere with debugging, so it should be safe.
Also -fomit-frame-pointer can be reversed by -fno-omit-frame-pointer.
> >
> > nik
> >
4387
days inactive
4387
days old
17 comments
4 participants
participants (4)
-
/dev/ammo42 -
David C. Rankin -
Mag. Dr. Nikolaus Klepp -
Timothy Pearson