Bug 204516 - alacarte gets segmentation fault
alacarte gets segmentation fault
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: alacarte (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-29 14:19 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-05 16:24:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-08-29 14:19:14 EDT
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 16:44:59 EDT
hmm, doesn't happen here.  maybe more glibc issues?  what version of glibc do
you have installed?
Comment 2 Michal Jaegermann 2006-08-29 17:39:44 EDT
> 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 16:08:13 EDT
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 16:24:08 EDT
Well, let's close it and if the problem resurfaces we can open it again.

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