trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

Re: [trinity-devel] GOOD BUILD POINT FOUND Re: [trinity-devel] kwrite/kate - why is 3.5.12 not affected (help analyzing)

From: /dev/ammo42 <mickeytintincolle@...>
Date: Sun, 29 Apr 2012 23:34:44 +0200
On Sun, 29 Apr 2012 16:27:04 -0500
"David C. Rankin" <drankinatty@...> 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 :)
> 
> 
>