I have been getting a segmentation fault with any mythtv related programs for the last few days since a yum upgrade. I believe it occurred at the same time as the last kernel upgrade, but I am not positive.
The error is very immediate to the point that I can't even run something like "mythfrontend --help" without an immediate failure.
$ mythfrontend
Segmentation fault (core dumped)
If I run with gdb, I get the following backtrace.
Code:
(gdb) start
Temporary breakpoint 1 at 0x8068f30: file main.cpp, line 1481.
Starting program: /usr/bin/mythfrontend
Program received signal SIGSEGV, Segmentation fault.
elf_dynamic_do_Rela (skip_ifunc=0, nrelative=558710, relsize=6793428, reladdr=<optimized out>, map=0xb7fd08d8, lazy=<optimized out>) at do-rel.h:121
121 DO_ELF_MACHINE_REL_RELATIVE (map, l_addr, relative);
(gdb) bt
#0 elf_dynamic_do_Rela (skip_ifunc=0, nrelative=558710, relsize=6793428, reladdr=<optimized out>, map=0xb7fd08d8, lazy=<optimized out>) at do-rel.h:121
#1 _dl_relocate_object (scope=0xb7fd0a90, reloc_mode=1, consider_profiling=<optimized out>) at dl-reloc.c:295
#2 0x49c5c5c9 in dl_main (phdr=0x8048034, phnum=8, user_entry=0xbffff0fc, auxv=0xbffff288) at rtld.c:2285
#3 0x49c6e026 in _dl_sysdep_start (start_argptr=start_argptr@entry=0xbffff190, dl_main=dl_main@entry=0x49c5aa40 <dl_main>) at ../elf/dl-sysdep.c:244
#4 0x49c5e031 in _dl_start_final (arg=0xbffff190) at rtld.c:336
#5 _dl_start (arg=0xbffff190) at rtld.c:562
#6 0x49c5a0f7 in _start () from /lib/ld-linux.so.2
One odd thing (and really the reason I put this in a fedora oriented forum rather than mythtv) is that there seem to be instances of ld-linux.so.2 in both /lib and /usr/lib. (I'm running the 32-bit version of F17 by the way.) That seemed a bit odd so I checked to see what package was providing the file.
Code:
# yum whatprovides '/usr/lib/ld-linux.so.2'
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
glibc-2.15-37.fc17.i686 : The GNU libc libraries
Repo : @fedora
Matched from:
Filename : /usr/lib/ld-linux.so.2
However, if I do a repoquery on that package, all I see is the instance that should be in /lib.
Code:
# repoquery --list glibc-2.15-37.fc17.i686 | grep ld-linux.so.2
/lib/ld-linux.so.2
I could be barking up the wrong tree here, but if I run the myth frontend as
LD_LIBRARY_PATH=/lib mythfrontend
the frontend actually comes up, although it seems to hang after I first tell it what optical drive to use.
I was wondering if the glibc libraries in /usr/lib are leftovers that should have been cleaned up. I had this exact same issue on F16 when I installed it fresh about a week before F17 released. Everything worked fine till I ran a yum upgrade. The only way I fixed it that time was running a preupgrade to F17 a few days later.
The only programs that I have had this issue on are MythTV related and perhaps Google Chrome. Chrome throws an almost identical error in ABRT.
While I am beating this issue to death, I'll throw in a few other questions that are just bugging me. I also ran a whatprovides on /lib/ld-linux.so.2 that gave me
Code:
# yum whatprovides '/lib/ld-linux.so.2'
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
glibc-2.15-37.fc17.i686 : The GNU libc libraries
Repo : fedora
Matched from:
Filename : /lib/ld-linux.so.2
glibc-2.15-37.fc17.i686 : The GNU libc libraries
Repo : @fedora
Matched from:
Filename : /lib/ld-linux.so.2
I should probably know this, but what is the difference between the "fedora" repo and the "@fedora" repo? I noticed that the /usr/lib/ld-linux.so.2 only shows in the "@fedora" repo.
Any advice is a appreciated.
Thanks,
Michael
