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.
Thanks.
Darrell
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!
Darrell
On Fri, 19 Oct 2012 17:43:11 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
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!
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.
On Fri, 19 Oct 2012 17:43:11 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
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!
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
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).
Thanks for looking. My apologies for not posting a followup to the question:
I filed a bug report:
http://bugs.trinitydesktop.org/show_bug.cgi?id=1279
In the bug report I identified the problematic line and posted a simple work-around. I don't know the root cause, but I guess a problem parsing the regex.
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.
I don't know what valgrind is [search...search...search]. Okay, a debugging tool, but I'm still out of my league. :)
Darrell
-
Darrell Anderson -
E. Liddell -
Timothy Pearson