20 Oct
2012
20 Oct
'12
3:49 p.m.
On Fri, 19 Oct 2012 17:43:11 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I wouldn't exactly consider myself a guru, but I had a look, and I can't
see anything
obviously wrong with the file. As far as I can tell by means of Mark I
Eyeball, it
is in compliance with the language.dtd file included in the same
directory, and therefore
has correct syntax (although a recheck with a proper parser might turn up
something
that I missed).
The file does not exist on my KDE3 system and was apparently added to
Trinity at
the beginning of this year, but I have other Kate syntax highlighting
schemas of
similar vintage that aren't causing any problems, so it anything is up
with this
file, it's either peculiar to it or peculiar to Trinity.
Or it could just be that .kcrash files are difficult to parse for some
reason--I
don't have a sample handy to check.
Can anyone here try to run kwrite under kcachegrind, open a kcrash file,
and post the results? This will help us figure out what section of the
code kwrite is "stuck" in.
Here is a quick tutorial:
valgrind --tool=callgrind kwrite
<open the kcrash file, wait for it to show up in kwrite, then immediately
close kwrite>
Then post the generated callgrind.out.<pid> file to this list.
Thanks!
Tim
Latest
R14.
Would somebody please confirm this behavior?
Run crashtest.
Save the backtrace.
Open the file with kate or kwrite. Open directly from within
or through konqueror.
On my dual core system with SATA II drives, opening a
*.kcrash file takes more than a minute to open, creating the
impression the app has stalled or locked.
The problem is caused by the katepart syntax/gdb.xml. The stalls
disappears when removing the gdb.xml file.
I haven't found an updated file on the web, including the KDE4 sources.
:(
Any xml gurus want to look at this file? The installed location is
/opt/trinity/share/apps/katepart/syntax/gdb.xml.
In the GIT sources the location is tdelibs/kate/data/gdb.xml.
Thanks much!