Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 40345 - After installing /usr/share/apps/ksgmltools2 all help fails with kio_help SIGSEGV
After installing /usr/share/apps/ksgmltools2 all help fails with kio_help SIG...
Product: Red Hat Raw Hide
Classification: Retired
Component: kdebase (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-05-12 05:59 EDT by j. alan eldridge
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-12 06:00:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description j. alan eldridge 2001-05-12 05:59:58 EDT
Description of Problem:

After fixing bug 40087, help is non-functional (kio_help dies with 
SIGSEGV, resulting in a dialog saying that the help process "died 
unexpectedly"). This happens no matter how KHelpcenter is invoked, 
whether from shell, kicker, or app help menu. Help is 100% 
non-functional. (Of course, before fixing 40087 help was 100% 
non-functional, too, so it's not like it got worse.)

How Reproducible:

Apply patch for 40087 and reinstall or just copy the dirs from the source 
tree into place.

Run Khelpcenter. 

Additional Information:

This is due to a bug in the copy of libxslt supplied with the kdebase 
source rpm. The function xsltApplyTemplates(), in transform.c, has a 
local pointer var "list" that ends up as NULL, and gets dereferenced at 
(depending on your compile-time defines) either line 2101 or 2109. 
Hijinks ensue.

Problem is that there is no check for "if (!list) error();" before it 
gets used. This is fixed in later versions of libxslt. Given that libxslt 
is approaching a 1.0 release (it's at 0.9.0 now), I recommend modifying 
kioslave/help/Makefile.am so that it references an already installed 
libxslt.so, and simply adding libxslt-0.9.0.i386.rpm and 
libxslt-devel-0.9.0.i386.rpm to the list of RPMS in rawhide, and to the 
prereqs, of course.

Failing that course of action, updating the snapshot of libxslt that is 
bundled in the source tree (to 0.9.0 version) should be sufficient. There 
may be an earlier version that works; I didn't see a reason to find out.

BTW although I didn't track it down, with libxml2-2.3.5, the help worked 
for some cases, but for KWord, it went on a runaway malloc spree (I 
killed it when the process size was about 800M). So recommend prereq 
being libxml2-devel >= 2.3.6, not >= 2.3.5.

I have submitted this bug to bugs.kde.org as well. I don't have a patch 
yet because a correct patch would entail fixing configure so it checks 
for libxslt. I haven't got around to doing that yet, and I'm not going to 
submit a half-assed patch that will not be (and should not be) accepted.

BTW it's a *bitch* to debug this. As a hint to anyone else faced with 
debugging a kioslave, I used:

pid=""; while true; do pid=$(ps -f -u $USER |grep '[k]io_help' |awk 
'{print $1;}'); [[ $pid ]] && break; sleep 1; done; gdb kdeinit $pid

in order to trap the process in the debugger. It's brute force, but it 

Oh, if debug is set to 1 in the spec file, the code that strips the 
binaries should not be executed. Just wrap it in "%if %{!debug}/%endif".

And you might want to remove that "core" from the source tree, too. :)
Comment 1 j. alan eldridge 2001-05-13 01:38:06 EDT
Already fixed in KDE CVS. They're using a newer version of libxslt now than 
0.9.0 and patched.

Note You need to log in before you can comment on or make changes to this bug.