Bug 204516

Summary: alacarte gets segmentation fault
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: alacarteAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-05 20:24:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2006-08-29 18:19:14 UTC
Description of problem:

I am not sure when it started, as after an original installation
of version 0.8-8.fc6 it looked that alacarte worked and I did not
try so far 0.9.90-7.fc6 which was installed on August 22nd.
Whatever changed typing now 'alacarte' gets "Segmentation fault"
all the time.  An output of strace ends in this way:

.....
open("/usr/share/pixmaps/pirut.png", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=4092, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaab448b000
read(4, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0000\0\0\0000\10\6\0\0"..., 4096) = 4092
stat("/usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so",
{st_mode=S_IFREG|0755, st_size=19536, ...}) = 0
open("/usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so", O_RDONLY) = 6
read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\32\0\0"..., 832) = 832
fstat(6, {st_mode=S_IFREG|0755, st_size=19536, ...}) = 0
mmap(NULL, 2114776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) =
0x2aaab448c000
mprotect(0x2aaab4490000, 2097152, PROT_NONE) = 0
mmap(0x2aaab4690000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x4000) = 0x2aaab4690000
close(6)                                = 0
lseek(4, 0, SEEK_SET)                   = 0
read(4, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0000\0\0\0000\10\6\0\0"..., 4096) = 4092
brk(0xd1d000)                           = 0xd1d000
close(4)                                = 0
munmap(0x2aaab448b000, 4096)            = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

How you can dereference NULL in Python I am not sure but it appears that
this is possible.

Version-Release number of selected component (if applicable):
alacarte-0.9.90-7.fc6
python-2.4.3-15.fc6

How reproducible:
always

Comment 1 Ray Strode [halfline] 2006-08-29 20:44:59 UTC
hmm, doesn't happen here.  maybe more glibc issues?  what version of glibc do
you have installed?

Comment 2 Michal Jaegermann 2006-08-29 21:39:44 UTC
> what version of glibc do you have installed?

glibc.x86_64 2.4.90-26.  As an effect of a series of updates from today.

With a dumped core I am not that much wiser.  gdb says:

Core was generated by `/usr/bin/python2.4 -OOt /usr/bin/alacarte'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002aaaae220343 in ?? ()

and backtrace gives only a bunch of addresses without any suggestions
where to look but with '#9  0x0000000000000000 in ?? ()' on the top level.
Frame 0 appears to have an address somewhere in libpthread.so.0.
Here is what ldd has to say:

# ldd /usr/bin/python2.4
        libpython2.4.so.1.0 => /usr/lib64/libpython2.4.so.1.0 (0x0000003d6e000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaaacc6000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaaaee0000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00002aaaab0e5000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaab2e8000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaab56b000)
        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)

and a "raw" backtrace:

(gdb) bt
#0  0x00002aaaae220343 in ?? ()
#1  0x00002aaab12af5a8 in ?? ()
#2  0x0000000000000001 in ?? ()
#3  0x00002aaab085bc30 in ?? ()
#4  0x00000000006012d0 in ?? ()
#5  0x00002aaab12a2560 in ?? ()
#6  0x00002aaaaaafcb9e in ?? ()
#7  0x00002aaab1531690 in ?? ()
#8  0x0000003d6e094b9a in ?? ()
#9  0x0000000000000000 in ?? ()


Comment 3 Michal Jaegermann 2006-09-05 20:08:13 UTC
After the latest update to 0.10.0-1.fc6 the problem vanished; but this
is because the issue was fixed or this is coincidental?  The only changelog
note says "- Update to 0.10.0" so it is not entirely clear if this should
be closed.


Comment 4 Ray Strode [halfline] 2006-09-05 20:24:08 UTC
Well, let's close it and if the problem resurfaces we can open it again.