Tim, All,
As I work to downgrade my R14 test boxes to troubleshoot what caused the kate/kwrite crash, I ran into a question I would like to get your thoughts on. All my day-to-day boxes run fully updated Archlinux (with one openSuSE box), and TDE 3.5.12 as the desktop (3.5.10 on SuSE).
QUESTION:
If the crash is due to an Arch update -- "They why do kate/kwrite continue to function normally in 3.5.12?"
It just strikes me that 3.5.12 would be much more susceptible to break due to Arch updates that R14. Would we not expect to see this same crash in 3.5.12 if this was due to an Arch update?
What say the experts? If this was Arch, wouldn't 3.5.12 have broken too?
As I work to downgrade my R14 test boxes to troubleshoot what caused the kate/kwrite crash, I ran into a question I would like to get your thoughts on. All my day-to-day boxes run fully updated Archlinux (with one openSuSE box), and TDE 3.5.12 as the desktop (3.5.10 on SuSE).
QUESTION:
If the crash is due to an Arch update -- "They why do kate/kwrite continue to function normally in 3.5.12?"
It just strikes me that 3.5.12 would be much more susceptible to break due to Arch updates that R14. Would we not expect to see this same crash in 3.5.12 if this was due to an Arch update?
What say the experts? If this was Arch, wouldn't 3.5.12 have broken too?
I can't speak for the experts. I can share that today I tried to run kwrite in my fresh Trinity build in Slackware Current 32-bit. Current is not raw bleeding edge (libpng 1.4.9), but is quite recent with most apps and uses gcc 4.7.
Kwrite won't work. Kate does.
I noticed the problem when I tried to launch kwrite through Konqueror to edit a text file. Kwrite started to open, a window "frame" appeared and then toast. I could not log out. I had to use Ctrl-Alt-Delete.
I started a new session. This time I started kwrite from the mini cli. No problems. Likewise from the menu. But opening through konqueror resulted in a freeze.
When I tried opening a file from within kwrite, the moment I started performing any cursor movements, the app froze and Ctrl-Alt-Backspace to the rescue.
I exited the session. I renamed the kwriterc file and removed the ksycoca cache and started a new session. Same results.
Interestingly, I have no problems using kate. I edited several files.
I disabled the Trinity compositing just in case. No difference.
This is a not a total session freeze. I could open konsole and konqueror. I could not logout but I did not try all methods. Possibly only the Ctrl-Alt-Delete shortcut was affected.
I'm unsure where we go next. We both experience kwrite issues but not kate issues. Gcc 4.7 is common but what else? NVidia? Slackware 13.1 uses xorg-server 1.7.7, Both Slackware 13.37 and Current use xorg-server 1.9.5.
I did not perform any exhaustive testing, therefore no conclusions. This all happened in a real machine and not a virtual machine. I have not tested with Current 64-bit (I haven't yet tried to build).
I use Trinity GIT in Slackware 13.1 quite a bit and never noticed anything like this. I have not noticed this with my recent Slackware 13.37 builds, but that means little because I haven't been looking for this kind of thing. That is, I don't know whether I have even used kate/kwrite in those systems because I just started building them. I will have to test more.
The only thing I can offer at this point is kwrite is toast in Slackware Current 32-bit.
Unless somebody has some clever suspicions to narrow the debugging, this could take a long while to unfold.
Darrell
On 04/29/2012 03:31 PM, Darrell Anderson wrote:
As I work to downgrade my R14 test boxes to troubleshoot what caused the kate/kwrite crash, I ran into a question I would like to get your thoughts on. All my day-to-day boxes run fully updated Archlinux (with one openSuSE box), and TDE 3.5.12 as the desktop (3.5.10 on SuSE).
QUESTION:
If the crash is due to an Arch update -- "They why do kate/kwrite continue to function normally in 3.5.12?"
It just strikes me that 3.5.12 would be much more susceptible to break due to Arch updates that R14. Would we not expect to see this same crash in 3.5.12 if this was due to an Arch update?
What say the experts? If this was Arch, wouldn't 3.5.12 have broken too?
I can't speak for the experts. I can share that today I tried to run kwrite in my fresh Trinity build in Slackware Current 32-bit. Current is not raw bleeding edge (libpng 1.4.9), but is quite recent with most apps and uses gcc 4.7.
Kwrite won't work. Kate does.
I noticed the problem when I tried to launch kwrite through Konqueror to edit a text file. Kwrite started to open, a window "frame" appeared and then toast. I could not log out. I had to use Ctrl-Alt-Delete.
I started a new session. This time I started kwrite from the mini cli. No problems. Likewise from the menu. But opening through konqueror resulted in a freeze.
When I tried opening a file from within kwrite, the moment I started performing any cursor movements, the app froze and Ctrl-Alt-Backspace to the rescue.
I exited the session. I renamed the kwriterc file and removed the ksycoca cache and started a new session. Same results.
Interestingly, I have no problems using kate. I edited several files.
I disabled the Trinity compositing just in case. No difference.
This is a not a total session freeze. I could open konsole and konqueror. I could not logout but I did not try all methods. Possibly only the Ctrl-Alt-Delete shortcut was affected.
I'm unsure where we go next. We both experience kwrite issues but not kate issues. Gcc 4.7 is common but what else? NVidia? Slackware 13.1 uses xorg-server 1.7.7, Both Slackware 13.37 and Current use xorg-server 1.9.5.
I did not perform any exhaustive testing, therefore no conclusions. This all happened in a real machine and not a virtual machine. I have not tested with Current 64-bit (I haven't yet tried to build).
I use Trinity GIT in Slackware 13.1 quite a bit and never noticed anything like this. I have not noticed this with my recent Slackware 13.37 builds, but that means little because I haven't been looking for this kind of thing. That is, I don't know whether I have even used kate/kwrite in those systems because I just started building them. I will have to test more.
The only thing I can offer at this point is kwrite is toast in Slackware Current 32-bit.
Unless somebody has some clever suspicions to narrow the debugging, this could take a long while to unfold.
Darrell
Tim, Darrell,
The kwrite/katepart crash is DEFINITIVELY TDE. I wiped out my tde install on x86_64 and went back to my build point from 3/29 and everything works perfectly. This is with everything built on gcc47. The only difference is with tdebase. For the 3/29 build I used -fpermissive. Where the newer builds were without it due to the kicker-easyvector patch. I'm not saying that had anything to do with it, I'm just telling you the differences between the 3/29 and current builds on my end for packages up to, and including, tdebase (eg: tqt3 through tdebase)
I don't know how to look at all the commits in the packages, but it seems like we should be able to look at commits in only the dependency tree of tdebase. That would leave the commits in question to be:
'dependencies/tqt3' 'dependencies/tqtinterface' 'dependencies/arts' 'dependencies/dbus-tqt' 'dependencies/dbus-1-tqt' 'dependencies/tqca-tls' 'dependencies/libart-lgpl' 'dependencies/avahi-tqt' 'dependencies/libcaldav' 'dependencies/libcarddav' 'dependencies/sip4-tqt' 'dependencies/python-tqt' 'tdelibs' 'tdebase'
Of those packages, we can probably eliminate everything but:
'dependencies/tqt3' 'dependencies/tqtinterface' 'tdelibs' 'tdebase'
(maybe the dbus packages should be in there too). Anyway, how can you get a list of all commits in those 4 packages from 3/29 to present? Then we can narrow it down that way. I'll try and narrow the gap a little more by going though and installing the couple of sets of binaries I have in between 3/29 and today.
I'm glad to know I'm not the only one that sees symptoms. (that doesn't mean I'm happy your kwrite crashed Darrell :) Just always good to have good company :)
On Sun, 29 Apr 2012 16:27:04 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 04/29/2012 03:31 PM, Darrell Anderson wrote:
As I work to downgrade my R14 test boxes to troubleshoot what caused the kate/kwrite crash, I ran into a question I would like to get your thoughts on. All my day-to-day boxes run fully updated Archlinux (with one openSuSE box), and TDE 3.5.12 as the desktop (3.5.10 on SuSE).
QUESTION:
If the crash is due to an Arch update -- "They why do kate/kwrite continue to function normally in 3.5.12?"
It just strikes me that 3.5.12 would be much more susceptible to break due to Arch updates that R14. Would we not expect to see this same crash in 3.5.12 if this was due to an Arch update?
What say the experts? If this was Arch, wouldn't 3.5.12 have broken too?
I can't speak for the experts. I can share that today I tried to run kwrite in my fresh Trinity build in Slackware Current 32-bit. Current is not raw bleeding edge (libpng 1.4.9), but is quite recent with most apps and uses gcc 4.7.
Kwrite won't work. Kate does.
I noticed the problem when I tried to launch kwrite through Konqueror to edit a text file. Kwrite started to open, a window "frame" appeared and then toast. I could not log out. I had to use Ctrl-Alt-Delete.
I started a new session. This time I started kwrite from the mini cli. No problems. Likewise from the menu. But opening through konqueror resulted in a freeze.
When I tried opening a file from within kwrite, the moment I started performing any cursor movements, the app froze and Ctrl-Alt-Backspace to the rescue.
I exited the session. I renamed the kwriterc file and removed the ksycoca cache and started a new session. Same results.
Interestingly, I have no problems using kate. I edited several files.
I disabled the Trinity compositing just in case. No difference.
This is a not a total session freeze. I could open konsole and konqueror. I could not logout but I did not try all methods. Possibly only the Ctrl-Alt-Delete shortcut was affected.
I'm unsure where we go next. We both experience kwrite issues but not kate issues. Gcc 4.7 is common but what else? NVidia? Slackware 13.1 uses xorg-server 1.7.7, Both Slackware 13.37 and Current use xorg-server 1.9.5.
I did not perform any exhaustive testing, therefore no conclusions. This all happened in a real machine and not a virtual machine. I have not tested with Current 64-bit (I haven't yet tried to build).
I use Trinity GIT in Slackware 13.1 quite a bit and never noticed anything like this. I have not noticed this with my recent Slackware 13.37 builds, but that means little because I haven't been looking for this kind of thing. That is, I don't know whether I have even used kate/kwrite in those systems because I just started building them. I will have to test more.
The only thing I can offer at this point is kwrite is toast in Slackware Current 32-bit.
Unless somebody has some clever suspicions to narrow the debugging, this could take a long while to unfold.
Darrell
Tim, Darrell,
The kwrite/katepart crash is DEFINITIVELY TDE. I wiped out my tde install on x86_64 and went back to my build point from 3/29 and everything works perfectly. This is with everything built on gcc47. The only difference is with tdebase. For the 3/29 build I used -fpermissive. Where the newer builds were without it due to the kicker-easyvector patch. I'm not saying that had anything to do with it, I'm just telling you the differences between the 3/29 and current builds on my end for packages up to, and including, tdebase (eg: tqt3 through tdebase)
I don't know how to look at all the commits in the packages, but it seems like we should be able to look at commits in only the dependency tree of tdebase. That would leave the commits in question to be:
'dependencies/tqt3' 'dependencies/tqtinterface' 'dependencies/arts' 'dependencies/dbus-tqt' 'dependencies/dbus-1-tqt' 'dependencies/tqca-tls' 'dependencies/libart-lgpl' 'dependencies/avahi-tqt' 'dependencies/libcaldav' 'dependencies/libcarddav' 'dependencies/sip4-tqt' 'dependencies/python-tqt' 'tdelibs' 'tdebase'Of those packages, we can probably eliminate everything but:
'dependencies/tqt3' 'dependencies/tqtinterface' 'tdelibs' 'tdebase'(maybe the dbus packages should be in there too). Anyway, how can you get a list of all commits in those 4 packages from 3/29 to present? Then we can narrow it down that way. I'll try and narrow the gap a little more by going though and installing the couple of sets of binaries I have in between 3/29 and today.
You can also try git bisect.
I'm glad to know I'm not the only one that sees symptoms. (that doesn't mean I'm happy your kwrite crashed Darrell :) Just always good to have good company :)
On 04/29/2012 04:34 PM, /dev/ammo42 wrote:
You can also try git bisect.
I'm not sure quite how to go about the bisect when building in an Archlinux chroot. If I understand correctly, the git bisect allows quick rebuilds of only those point that have changed. Unless I can make the --noextract work with tdelibs and tdebase, bisecting could take a very, very long time... Hopefully, it's easier than I think it is :)
On Sun, 29 Apr 2012 17:02:37 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 04/29/2012 04:34 PM, /dev/ammo42 wrote:
You can also try git bisect.
I'm not sure quite how to go about the bisect when building in an Archlinux chroot. If I understand correctly, the git bisect allows quick rebuilds of only those point that have changed. Unless I can make the --noextract work with tdelibs and tdebase, bisecting could take a very, very long time... Hopefully, it's easier than I think it is :)
Or you could try to build only tdebase, without using Arch packages but with an install prefix somewhere in your home directory (and using directly make install), with an appropriate $PATH of course ;)
On 04/29/2012 04:27 PM, David C. Rankin wrote:
Kwrite won't work. Kate does.
Ah, you just haven't tried hard enough yet :) Did you try the 1-2 word at a time paste into line 1 until it wrapped in kate? That's what killed everything for me (kwrite/kate/quanta). However as I mentioned in the other post, all work fine in my build from 3/29.
I noticed the problem when I tried to launch kwrite through Konqueror to edit a text file. Kwrite started to open, a window "frame" appeared and then toast. I could not log out. I had to use Ctrl-Alt-Delete.
I have only experienced one desktop lockup that I documented in the other post. All of the other crashes just concerned the editor at the time (kate/kwrite/etc..) When I was using katepart preview in konqueror, that did bring konqueror down and that was my only system lockup.
I started a new session. This time I started kwrite from the mini cli. No problems. Likewise from the menu. But opening through konqueror resulted in a freeze.
When I tried opening a file from within kwrite, the moment I started performing any cursor movements, the app froze and Ctrl-Alt-Backspace to the rescue.
I exited the session. I renamed the kwriterc file and removed the ksycoca cache and started a new session. Same results.
Interestingly, I have no problems using kate. I edited several files.
I cannot explain this. I too have had varying results with kate. I have opened it and been able to start picking through the help documentation and had no crash until I opened a file for editing. Once the editor part of kate is running, if there are lines that wrap, or if I paste something that makes a line wrap, then I can kill kate every time.
I too have had documents with long lines open in kate and had it not crash immediately, but when I start editing, it crashes.
I disabled the Trinity compositing just in case. No difference.
Never even turned on in my desktop, so I can confirm this is unrelated.
This is a not a total session freeze. I could open konsole and konqueror. I could not logout but I did not try all methods. Possibly only the Ctrl-Alt-Delete shortcut was affected.
Yep, same here. It's just the app that crashes (unless opened from konqueror - damn windows explorer...) That is how I was able to get the backtraces. I usually had konsole already running, so I would just type:
gdb --pid $(pidof kwrite)
and get gdb running, it would load the symbols, then I just typed 'bt'
I would be interested in seeing your backtrace, even without line numbers to see if you are crashing with some of the same calls.
I'm unsure where we go next. We both experience kwrite issues but not kate issues. Gcc 4.7 is common but what else? NVidia? Slackware 13.1 uses xorg-server 1.7.7, Both Slackware 13.37 and Current use xorg-server 1.9.5.
gcc 4.7
xorg packages: <snip> xorg-font-util 1.3.0-1 xorg-font-utils 7.6-3 xorg-fonts-alias 1.0.2-2 xorg-fonts-encodings 1.0.4-3 xorg-fonts-misc 1.0.1-2 <snip> xorg-mkfontdir 1.0.7-1 xorg-mkfontscale 1.1.0-1 xorg-server 1.12.1-1 xorg-server-common 1.12.1-1 <snip>
video is provided by Virtualbox Video driver (I think Tim knows what this emulates)
Looking at the list of packages that I updated are Arch between the time all was "good" and when I started getting the crashes - there was absolutely NOTHING that looked related. No xorg changes, no font changes, no nothing, basically the only 3rd-party packages that had changes were USB libraries and gstreamer stuff.
I did not perform any exhaustive testing, therefore no conclusions. This all happened in a real machine and not a virtual machine. I have not tested with Current 64-bit (I haven't yet tried to build).
I have seen the same crash in Virtualbox in both i686 and x86_64 installs. So it has been consistent and 100% repeatable for me.
I use Trinity GIT in Slackware 13.1 quite a bit and never noticed anything like this. I have not noticed this with my recent Slackware 13.37 builds, but that means little because I haven't been looking for this kind of thing. That is, I don't know whether I have even used kate/kwrite in those systems because I just started building them. I will have to test more.
I didn't notice anything until my post on 4/25. I did see some "weirdness" in my builds from 4/12 (as a matter of fact, I moved the binaries to a directory named: 'x86_64-0412-weird') I'll go load the core packages from that build and report back on the kwrite issue.
The only thing I can offer at this point is kwrite is toast in Slackware Current 32-bit.
Unless somebody has some clever suspicions to narrow the debugging, this could take a long while to unfold.
If we keep comparing notes and mentally eliminating things that are not related, we can shorten this process considerably. If I was better at reading backtraces and had a better feel for what they were telling us, then that might shorten the search as well. Unfortunately, Tim doesn't find any smoking gun in them, so I'm not sure how useful they are.
If you can capture a few backtraces of the crashes you see, then that at least might point to something in common.
Darrell
keep the faith :)
I would be interested in seeing your backtrace, even without line numbers to see if you are crashing with some of the same calls.
If you can capture a few backtraces of the crashes you see, then that at least might point to something in common.
I can't do backtraces right now. :-(
One, I have been focused on getting the build process running for the new environments. I did not need nor want that overhead during this phase.
Second, now that I can build without incident in these new environments, something is messed up with my build scripts. For a while I was building separate debug packages and they worked just fine. A couple of weeks ago I noticed none of them worked. That is, several times I could not obtain backtraces (TDM has a habit of crashing on my system). I likely can temporarily build the packages with debugging built in, but that makes for huge packages.
Darrell
<snip>
I don't know how to look at all the commits in the packages
<snip>
http://trinitydesktop.org/patches
Tim
<snip> > I don't know how to look at all the commits in the packages <snip>
http://trinitydesktop.org/patches
Tim
Also, I really, really hope this is NOT the cause (as it would indicate TDE is somehow confusing gcc; i.e. gcc has a very hard to trace bug), but try reversing this patch to see if the random crashes stop:
http://git.trinitydesktop.org/cgit/tdebase/commit/kdesktop/desktop.cc?id=306...
Tim
On 04/29/2012 05:04 PM, Timothy Pearson wrote:
Also, I really, really hope this is NOT the cause (as it would indicate TDE is somehow confusing gcc; i.e. gcc has a very hard to trace bug), but try reversing this patch to see if the random crashes stop:
http://git.trinitydesktop.org/cgit/tdebase/commit/kdesktop/desktop.cc?id=306...
Tim
On it - will rebuild with all debugging in place and report back. Should be within 40 minutes or so...
Also, I really, really hope this is NOT the cause (as it would indicate TDE is somehow confusing gcc; i.e. gcc has a very hard to trace bug), but try reversing this patch to see if the random crashes stop:
http://git.trinitydesktop.org/cgit/tdebase/commit/kdesktop/desktop.cc?id=306...
I'm starting X with startx and useSAK is irrelevant in that run level. Not arguing, just noting. :-)
Nonetheless, I'll try a reverse patch and see what happens.
Darrell
On 04/29/2012 05:04 PM, Timothy Pearson wrote:
<snip> > I don't know how to look at all the commits in the packages <snip>
http://trinitydesktop.org/patches
Tim
Also, I really, really hope this is NOT the cause (as it would indicate TDE is somehow confusing gcc; i.e. gcc has a very hard to trace bug), but try reversing this patch to see if the random crashes stop:
http://git.trinitydesktop.org/cgit/tdebase/commit/kdesktop/desktop.cc?id=306...
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
Tim,
That might have been part of it, because this time the text actually wrapped in the kwrite window (to the next line), before it crashed, but it did crash. However, the last line before the backtrace makes reference to a missing katerenderer.cpp file. What's up with that?? Could this be the BUG?? It looks like there may be an extra 'er' at the end of the filename? (guessing)
Also, why do you encouragingly say "I really, really how this is NOT the cause..."? Just curious. Here is the backtrace with the funky line right before bt:
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 0x00007fbafa2a814b in KateRenderer::textWidth (this=0x15029d0, textLine=..., startcol=0, maxwidth=758, needWrap=0x7fffe10976b8, endX=0x7fffe10976ac) at /build/src/tdelibs/kate/part/katerenderer.cpp:819 819 /build/src/tdelibs/kate/part/katerenderer.cpp: No such file or directory. (gdb) bt #0 0x00007fbafa2a814b in KateRenderer::textWidth (this=0x15029d0, textLine=..., startcol=0, maxwidth=758, needWrap=0x7fffe10976b8, endX=0x7fffe10976ac) at /build/src/tdelibs/kate/part/katerenderer.cpp:819 #1 0x00007fbafa289674 in KateViewInternal::range (this=this@entry=0x15142a0, realLine=13, previous=previous@entry=0x0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331 #2 0x00007fbafa28b0b6 in KateViewInternal::range (this=this@entry=0x15142a0, realCursor=...) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1403 #3 0x00007fbafa28b160 in KateViewInternal::currentRange (this=this@entry=0x15142a0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1370 #4 0x00007fbafa2902ee in KateViewInternal::updateCursor (this=this@entry=0x15142a0, newCursor=..., force=force@entry=true, center=center@entry=false, calledExternally=calledExternally@entry=false) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2226 #5 0x00007fbafa2944c0 in KateViewInternal::editEnd (this=0x15142a0, editTagLineStart=13, editTagLineEnd=<optimized out>, tagFrom=<optimized out>) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:3385 #6 0x00007fbafa230ef0 in KateDocument::editEnd (this=0x140be30) at /build/src/tdelibs/kate/part/katedocument.cpp:1032 #7 0x00007fbafa22af5b in KateDocument::paste (this=0x140be30, view=0x154df50) at /build/src/tdelibs/kate/part/katedocument.cpp:3249 #8 0x00007fbafa262a53 in KateView::paste (this=0x154df50) at /build/src/tdelibs/kate/part/kateview.cpp:1597 #9 0x00007fbafa292102 in KateViewInternal::mouseReleaseEvent (this=0x15142a0, e=0x7fffe1097d60) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2965 #10 0x00007fbb032f1343 in TQWidget::event (this=0x15142a0, e=0x7fffe1097d60) at kernel/qwidget.cpp:4725 #11 0x00007fbb0325b559 in TQApplication::internalNotify (this=0x7fffe10985c0, receiver=0x15142a0, e=0x7fffe1097d60) at kernel/qapplication.cpp:2638 #12 0x00007fbb0325abe3 in TQApplication::notify (this=0x7fffe10985c0, receiver=0x15142a0, e=0x7fffe1097d60) at kernel/qapplication.cpp:2424 #13 0x00007fbb03bb28c4 in KApplication::notify (this=0x7fffe10985c0, receiver=0x15142a0, event=0x7fffe1097d60) at /build/src/tdelibs/tdecore/kapplication.cpp:583 #14 0x00007fbb031ed6b3 in TQApplication::sendSpontaneousEvent (receiver=0x15142a0, event=0x7fffe1097d60) at kernel/ntqapplication.h:526 #15 0x00007fbb031e6f53 in TQETWidget::translateMouseEvent (this=0x15142a0, event=0x7fffe1098270) at kernel/qapplication_x11.cpp:4380 #16 0x00007fbb031e4871 in TQApplication::x11ProcessEvent (this=0x7fffe10985c0, event=0x7fffe1098270) at kernel/qapplication_x11.cpp:3557 #17 0x00007fbb031ffc44 in TQEventLoop::processEvents (this=0x12edad0, flags=4) at kernel/qeventloop_x11.cpp:195 #18 0x00007fbb0326e818 in TQEventLoop::enterLoop (this=0x12edad0) at kernel/qeventloop.cpp:201 #19 0x00007fbb0326e6e9 in TQEventLoop::exec (this=0x12edad0) at kernel/qeventloop.cpp:148 #20 0x00007fbb0325b689 in TQApplication::exec (this=0x7fffe10985c0) at kernel/qapplication.cpp:2761 #21 0x00007fbafc62d3a8 in kdemain (argc=1, argv=0x1292b20) at /build/src/tdebase/kate/app/kwritemain.cpp:692 #22 0x00007fbafc8378c0 in tdeinitmain (argc=1, argv=0x1292b20) at /build/src/build/kate/app/kwrite_tdeinit_module.cpp:3 #23 0x00000000004094ee in launch (argc=argc@entry=1, _name=<optimized out>, _name@entry=0x1292298 "kwrite", args=<optimized out>, args@entry=0x129229f "\001", cwd=cwd@entry=0x0, envc=envc@entry=1, envs=<optimized out>, envs@entry=0x12922a7 "DISPLAY=:0", reset_env=false, tty=tty@entry=0x0, avoid_loops=false, startup_id_str=startup_id_str@entry=0x12922ba "valkyrie;1335740572;489878;1159_TIME4851635") at /build/src/tdelibs/kinit/kinit.cpp:673 #24 0x000000000040a5ee in handle_launcher_request (sock=9) at /build/src/tdelibs/kinit/kinit.cpp:1240 #25 0x000000000040abda in handle_requests (waitForPid=waitForPid@entry=0) at /build/src/tdelibs/kinit/kinit.cpp:1443 #26 0x0000000000406b26 in main (argc=5, argv=0x7fff0000000b, envp=0x7fffe1099698) ---Type <return> to continue, or q <return> to quit--- at /build/src/tdelibs/kinit/kinit.cpp:1908
On 04/29/2012 06:08 PM, David C. Rankin wrote:
Also, why do you encouragingly say "I really, really [hope] this is NOT the cause..."? Just curious. Here is the backtrace with the funky line right before bt:
Geez! Now I see why you say that.... I just did diffs of different points in the tdebase code:
-rw-r--r-- 1 david david 142792 Apr 29 18:48 0329-0410_tdebase.diff -rw-r--r-- 1 david david 97205 Apr 29 18:51 0410-0420_tdebase.diff -rw-r--r-- 1 david david 76893 Apr 29 18:52 0420-0425_tdebase.diff
That's almost 310k in diffs between 3/29 and 4/25. Wow.. That's the point that might make it a bit difficult to find...
Oh well, How do you eat a whale ---> one bite at a time. Let's start eating...
Oh well, How do you eat a whale ---> one bite at a time. Let's start eating...
David, as you tend to update your system routinely, because that is somewhat the nature of a rolling release, what system packages did you update at about the time you started to notice the problems? Perhaps that short list might provide a clue as what is also installed here.
At the moment I want to ignore nvidia and xorg server because I am using the same versions for 13.37 as well.
Oh, and I tried the same kwrite test with the vesa driver. My screen looked like silly putty but kwrite froze again. So probably not nvidia or xorg.
Darrell
On 04/29/2012 07:12 PM, Darrell Anderson wrote:
Oh well, How do you eat a whale ---> one bite at a time. Let's start eating...
David, as you tend to update your system routinely, because that is somewhat the nature of a rolling release, what system packages did you update at about the time you started to notice the problems? Perhaps that short list might provide a clue as what is also installed here.
At the moment I want to ignore nvidia and xorg server because I am using the same versions for 13.37 as well.
Oh, and I tried the same kwrite test with the vesa driver. My screen looked like silly putty but kwrite froze again. So probably not nvidia or xorg.
Darrell
Not much, but here it is. I can't see anything related:
[2012-04-02 16:34] installed libcddb (1.3.2-3) [2012-04-02 16:34] installed libcdio (0.83-1) [2012-04-12 07:57] installed gstreamer0.10 (0.10.36-1) [2012-04-12 07:57] installed gstreamer0.10-base (0.10.36-1) [2012-04-12 13:25] installed libmtp (1.1.3-1) [2012-04-14 17:54] installed mutagen (1.20-4) [2012-04-14 17:54] installed sg3_utils (1.33-1) [2012-04-14 17:54] installed libplist (1.4-1) [2012-04-14 17:54] installed usbmuxd (1.0.7-2) [2012-04-14 17:54] installed libimobiledevice (1.1.1-2) [2012-04-14 17:54] installed libgpod (0.8.2-4) [2012-04-20 16:35] installed faad2 (2.7-3) [2012-04-20 16:35] installed faac (1.28-3) [2012-04-20 16:35] installed libquicktime (1.2.4-1) [2012-04-20 16:35] installed recode (3.6-7) [2012-04-20 16:35] installed enca (1.13-2) [2012-04-20 16:35] installed a52dec (0.7.4-6) [2012-04-20 16:35] installed libdca (0.0.5-3) [2012-04-20 16:35] installed libass (0.10.0-3) [2012-04-20 16:35] installed libbluray (0.2.1-1) [2012-04-20 16:35] installed mencoder (34799-1) [2012-04-20 16:35] installed libftdi (0.20-1) [2012-04-20 16:35] installed libirman (0.4.5-3) [2012-04-20 16:35] installed lirc-utils (1:0.9.0-15) [2012-04-20 16:35] installed aalib (1.4rc5-9) [2012-04-20 16:35] installed libvdpau (0.4.1-2) [2012-04-20 16:35] installed libcaca (0.99.beta17-2) [2012-04-20 16:35] installed mplayer (34799-1) [2012-04-20 16:35] installed xdg-utils (1.1.0rc1-3) [2012-04-20 16:35] installed xine-ui (0.99.6-5) [2012-04-25 01:02] installed libwmf (0.2.8.4-9) [2012-04-25 01:02] installed babl (0.1.6-1) [2012-04-25 01:02] installed gegl (0.1.8-2) [2012-04-25 01:03] installed gimp (2.6.12-1) [2012-04-25 01:03] installed gimp-dbp (1.1.9-3) [2012-04-25 01:03] installed gimp-gap (2.6.0-3) [2012-04-25 01:03] installed gimp-help-en (2.6.1-1) [2012-04-25 01:03] installed gtkimageview (1.6.4-3) [2012-04-25 01:03] installed gimp-ufraw (0.18-4) [2012-04-25 01:03] installed gimp-plugin-fblur (3.2.6-3) [2012-04-25 01:03] installed blas (3.4.0-1) [2012-04-25 01:03] installed lapack (3.4.0-1) [2012-04-25 01:03] installed gimp-plugin-gmic (1.5.1.2-1) [2012-04-25 01:03] installed liblqr (0.4.1-3) [2012-04-25 01:03] installed gimp-plugin-lqr (0.7.1-4) [2012-04-25 01:03] installed gsl (1.15-2) [2012-04-25 01:03] installed gtksourceview2 (2.10.5-2) [2012-04-25 01:03] installed gimp-plugin-mathmap (1.3.5-2) [2012-04-25 01:03] installed gimp-plugin-wavelet-decompose (0.1.2-2) [2012-04-25 01:03] installed gimp-plugin-wavelet-denoise (0.3.1-2) [2012-04-25 01:03] installed gimp-refocus (0.9.0-3)
Not much, but here it is. I can't see anything related:
[2012-04-02 16:34] installed libcddb (1.3.2-3) [2012-04-02 16:34] installed libcdio (0.83-1) [2012-04-12 07:57] installed gstreamer0.10 (0.10.36-1) [2012-04-12 07:57] installed gstreamer0.10-base (0.10.36-1) [2012-04-12 13:25] installed libmtp (1.1.3-1) [2012-04-14 17:54] installed mutagen (1.20-4) [2012-04-14 17:54] installed sg3_utils (1.33-1) [2012-04-14 17:54] installed libplist (1.4-1) [2012-04-14 17:54] installed usbmuxd (1.0.7-2) [2012-04-14 17:54] installed libimobiledevice (1.1.1-2) [2012-04-14 17:54] installed libgpod (0.8.2-4) [2012-04-20 16:35] installed faad2 (2.7-3) [2012-04-20 16:35] installed faac (1.28-3) [2012-04-20 16:35] installed libquicktime (1.2.4-1) [2012-04-20 16:35] installed recode (3.6-7) [2012-04-20 16:35] installed enca (1.13-2) [2012-04-20 16:35] installed a52dec (0.7.4-6) [2012-04-20 16:35] installed libdca (0.0.5-3) [2012-04-20 16:35] installed libass (0.10.0-3) [2012-04-20 16:35] installed libbluray (0.2.1-1) [2012-04-20 16:35] installed mencoder (34799-1) [2012-04-20 16:35] installed libftdi (0.20-1) [2012-04-20 16:35] installed libirman (0.4.5-3) [2012-04-20 16:35] installed lirc-utils (1:0.9.0-15) [2012-04-20 16:35] installed aalib (1.4rc5-9) [2012-04-20 16:35] installed libvdpau (0.4.1-2) [2012-04-20 16:35] installed libcaca (0.99.beta17-2) [2012-04-20 16:35] installed mplayer (34799-1) [2012-04-20 16:35] installed xdg-utils (1.1.0rc1-3) [2012-04-20 16:35] installed xine-ui (0.99.6-5) [2012-04-25 01:02] installed libwmf (0.2.8.4-9) [2012-04-25 01:02] installed babl (0.1.6-1) [2012-04-25 01:02] installed gegl (0.1.8-2) [2012-04-25 01:03] installed gimp (2.6.12-1) [2012-04-25 01:03] installed gimp-dbp (1.1.9-3) [2012-04-25 01:03] installed gimp-gap (2.6.0-3) [2012-04-25 01:03] installed gimp-help-en (2.6.1-1) [2012-04-25 01:03] installed gtkimageview (1.6.4-3) [2012-04-25 01:03] installed gimp-ufraw (0.18-4) [2012-04-25 01:03] installed gimp-plugin-fblur (3.2.6-3) [2012-04-25 01:03] installed blas (3.4.0-1) [2012-04-25 01:03] installed lapack (3.4.0-1) [2012-04-25 01:03] installed gimp-plugin-gmic (1.5.1.2-1) [2012-04-25 01:03] installed liblqr (0.4.1-3) [2012-04-25 01:03] installed gimp-plugin-lqr (0.7.1-4) [2012-04-25 01:03] installed gsl (1.15-2) [2012-04-25 01:03] installed gtksourceview2 (2.10.5-2) [2012-04-25 01:03] installed gimp-plugin-mathmap (1.3.5-2) [2012-04-25 01:03] installed gimp-plugin-wavelet-decompose (0.1.2-2) [2012-04-25 01:03] installed gimp-plugin-wavelet-denoise (0.3.1-2) [2012-04-25 01:03] installed gimp-refocus (0.9.0-3)
I don't see anything obvious there either.
Looks a like a TDE patch or an oddball build conflict.
Darrell
On 04/29/2012 08:48 PM, Darrell Anderson wrote:
I don't see anything obvious there either.
Looks a like a TDE patch or an oddball build conflict.
Darrell
Yep, it's got to be. I'll go through the various binaries I have to try and narrow down when the bug was introduced. I don't even have a guess at what it is. All we can do is follow Tim's lead that it is most likely tdelibs, tdebase or tqt3. Will report back. If you have any old binaries, then you can do the same and we can hopefully bracket the changes to within a day or two.
On 04/29/2012 06:08 PM, David C. Rankin wrote:
Also, why do you encouragingly say "I really, really [hope] this is NOT the cause..."? Just curious. Here is the backtrace with the funky line right before bt:
Geez! Now I see why you say that.... I just did diffs of different points in the tdebase code:
-rw-r--r-- 1 david david 142792 Apr 29 18:48 0329-0410_tdebase.diff -rw-r--r-- 1 david david 97205 Apr 29 18:51 0410-0420_tdebase.diff -rw-r--r-- 1 david david 76893 Apr 29 18:52 0420-0425_tdebase.diff
That's almost 310k in diffs between 3/29 and 4/25. Wow.. That's the point that might make it a bit difficult to find...
Oh well, How do you eat a whale ---> one bite at a time. Let's start eating...
I'd look at tqt3, arts, tdelibs, and *maybe* tdebase, but honestly I think the problem is in tdelibs (http://git.trinitydesktop.org/cgit/tdelibs/log/). Easiest way to debug this is: 1.) Check out and rebuild/reinstall tqt3, arts, tdelibs, and tdebase from the last known working date. 2.) Update, rebuild, and reinstall each module in turn, checking for the failure after each module has been reinstalled with the latest sources. 3.) Once the module is known (e.g. tdelibs or tdebase causes the problem), bisect the commits between the known working date and the latest HEAD.
Tedious, but you should get the faulty commit fastest this way.
Tim
Also, I really, really hope this is NOT the cause (as it would indicate TDE is somehow confusing gcc; i.e. gcc has a very hard to trace bug), but try reversing this patch to see if the random crashes stop:
http://git.trinitydesktop.org/cgit/tdebase/commit/kdesktop/desktop.cc?id=306...
That patch is not the problem here. I just finished a rebuild with the patch reversed and I saw the same weirdness.
Darrell
-
/dev/ammo42 -
Darrell Anderson -
David C. Rankin -
Timothy Pearson