Red Hat Bugzilla – Bug 644390
libgegl.so leaks "root" symbol which may cause crashes
Last modified: 2016-07-25 09:17:36 EDT
+++ This bug was initially created as a clone of Bug #642992 +++
abrt version: 1.1.13
Attached file: backtrace
reason: Process /usr/bin/gimp-2.6 was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Goddard)
--- Additional comment from firstname.lastname@example.org on 2010-10-14 08:10:47 EDT ---
Created attachment 453443 [details]
--- Additional comment from email@example.com on 2010-10-14 10:54:47 EDT ---
Changing component to gegl as this is where the crash happens. I'm at a loss though why it would crash -- I don't understand how the "root" variable could ever become "0xffffffff".
What exactly were you doing when the crash happened?
Are you sure your memory (RAM) is okay?
--- Additional comment from firstname.lastname@example.org on 2010-10-15 02:49:57 EDT ---
FYI, I'm able to run memtest this morning. There is no error with my RAM.
The crash happens whenever I run gimp (even after a fresh reboot)
Following is some additional info that may help to resolve this issue. Feel free to ask for more info.
hung@hung-laptop:~$ uname -r
hung@hung-laptop:~$ cat /proc/meminfo
MemTotal: 4109840 kB
MemFree: 2299688 kB
Buffers: 256696 kB
Cached: 997736 kB
SwapCached: 0 kB
Active: 678388 kB
Inactive: 888788 kB
Active(anon): 313880 kB
Inactive(anon): 93824 kB
Active(file): 364508 kB
Inactive(file): 794964 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 3277640 kB
HighFree: 1949724 kB
LowTotal: 832200 kB
LowFree: 349964 kB
SwapTotal: 1622528 kB
SwapFree: 1622528 kB
Dirty: 68 kB
Writeback: 0 kB
AnonPages: 312744 kB
Mapped: 126352 kB
Shmem: 94960 kB
Slab: 195936 kB
SReclaimable: 168144 kB
SUnreclaim: 27792 kB
KernelStack: 2544 kB
PageTables: 10300 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3677448 kB
Committed_AS: 1782476 kB
VmallocTotal: 122880 kB
VmallocUsed: 22004 kB
VmallocChunk: 79368 kB
HardwareCorrupted: 0 kB
Hugepagesize: 2048 kB
DirectMap4k: 10232 kB
DirectMap2M: 897024 kB
--- Additional comment from email@example.com on 2010-10-15 06:13:53 EDT ---
(In reply to comment #3)
> FYI, I'm able to run memtest this morning. There is no error with my RAM.
Just for reference: Which versions of gegl/babl do you have installed?
Maybe one of the gimp/gegl/babl packages is damaged in some way. Please verify these by running this command as root:
rpm -Va gimp\* gegl\* babl\*
--- Additional comment from firstname.lastname@example.org on 2010-10-17 09:11:14 EDT ---
This is the output from yum list installed
# yum list installed | grep gegl
gegl.i686 0.1.2-3.fc13 @updates
gegl-debuginfo.i686 0.1.2-3.fc13 @updates-debuginfo
gegl-devel.i686 0.1.2-3.fc13 @updates
# yum list installed | grep babl
babl.i686 0.1.2-4.fc13 @updates
babl-debuginfo.i686 0.1.2-4.fc13 @updates-debuginfo
babl-devel.i686 0.1.2-4.fc13 @updates
rpm -Va gimp\* gegl\* babl\* displayed nothing on the terminal.
Was: [abrt] gimp-2:2.6.11-1.fc13: timing_find: Process /usr/bin/gimp-2.6 was killed by signal 11 (SIGSEGV)
--- Additional comment from email@example.com on 2010-10-19 11:00:56 EDT ---
This issue is most likely triggered because you have xvnkb installed (which Fedora doesn't ship) and it is preloaded because either the LD_PRELOAD environment variable or /etc/ld.so.preload are set accordingly:
1. Both libgegl.so and xvnkb.so export a symbol named "root".
2. Because xvnkb.so is loaded earlier than libgegl.so, its "root" symbol takes precedence. It is initialized to -1 in xvnkb.so.
3. Because root isn't NULL (0), gegl_instrument() doesn't allocate memory and passes on the value -1 (0xFFFFFFFF) to timing_find().
4. timing_find() tries to dereference root and crashes.
Concluding, both gegl and xvnkb libs are broken: they should not export a symbol named just "root" as this may clash in many places (applications may have global symbols shadowed by this e.g.).
I've already fixed this in gegl upstream: http://git.gnome.org/browse/gegl/commit/?id=75a5c4a5042aa3c531977637e5f0b5e62d14978c
I'll build a new version soon which contains this fix.
You should report this issue to xvnkb upstream so they can fix their library as well.
This issue was proposed for RHEL 6.1 FasTrack but did not get resolved in time.
It has been moved to RHEL 6.2 FasTrack.