Red Hat Bugzilla – Bug 204516
alacarte gets segmentation fault
Last modified: 2007-11-30 17:11:41 EST
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
hmm, doesn't happen here. maybe more glibc issues? what version of glibc do you have installed?
> 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 ?? ()
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.
Well, let's close it and if the problem resurfaces we can open it again.