<div>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. </div><div>
<br></div><div>The error is very immediate to the point that I can't even run something like "mythfrontend --help" without an immediate failure.</div><div><br></div><div>$ mythfrontend </div><div>Segmentation fault (core dumped)</div>
<div><br></div><div>If I run with gdb, I get the following backtrace.</div><div><br></div><div>(gdb) start</div><div>Temporary breakpoint 1 at 0x8068f30: file main.cpp, line 1481.</div><div>Starting program: /usr/bin/mythfrontend </div>
<div><br></div><div>Program received signal SIGSEGV, Segmentation fault.</div><div>elf_dynamic_do_Rela (skip_ifunc=0, nrelative=558710, relsize=6793428, reladdr=<optimized out>, map=0xb7fd08d8, lazy=<optimized out>) at do-rel.h:121</div>
<div>121<span class="Apple-tab-span" style="white-space:pre"> </span> DO_ELF_MACHINE_REL_RELATIVE (map, l_addr, relative);</div><div>(gdb) bt</div><div>#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</div>
<div>#1 _dl_relocate_object (scope=0xb7fd0a90, reloc_mode=1, consider_profiling=<optimized out>) at dl-reloc.c:295</div><div>#2 0x49c5c5c9 in dl_main (phdr=0x8048034, phnum=8, user_entry=0xbffff0fc, auxv=0xbffff288) at rtld.c:2285</div>
<div>#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</div><div>#4 0x49c5e031 in _dl_start_final (arg=0xbffff190) at rtld.c:336</div>
<div>#5 _dl_start (arg=0xbffff190) at rtld.c:562</div><div>#6 0x49c5a0f7 in _start () from /lib/ld-linux.so.2</div><div><br></div><div>One odd thing 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.</div>
<div><br></div><div><div># yum whatprovides '/usr/lib/ld-linux.so.2'</div><div>Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit</div><div>glibc-2.15-37.fc17.i686 : The GNU libc libraries</div>
<div>Repo : @fedora</div><div>Matched from:</div><div>Filename : /usr/lib/ld-linux.so.2</div><div><br></div><div>However, if I do a repoquery on that package, all I see is the instance that should be in /lib.</div>
<div><br></div><div># repoquery --list glibc-2.15-37.fc17.i686 | grep ld-linux.so.2</div><div>/lib/ld-linux.so.2</div><div>I could be barking up the wrong tree here, but if I run the myth frontend as</div><div><br></div><div>
LD_LIBRARY_PATH=/lib mythfrontend</div><div><br></div><div>the frontend actually comes up, although it seems to hang after I first tell it what optical drive to use.</div><div><br></div><div>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. That being said, 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. Any advice is a appreciated.</div>
<div><br></div><div>Thanks,</div><div>Michael</div></div><div><br></div>