Segfault in Backend caused by something between trunk 26371 and 26542

[MarcT <myrdhn@…>]

I updated from 26371 to 26542 in order to fix #8990. Now I continually get segfaults every hour or so if nothing is recording. I updated again in hopes it was fixed but it was not.

# mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version   : 26558M
MythTV Branch    : trunk
Network Protocol : 63
Library API      : 0.23.20100917-1
QT Version       : 4.6.2
Options compiled in:
 linux debug using_alsa using_oss using_backend using_bindings_perl using_bindings_python using_dvb using_frontend using_hdpvr using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_ffmpeg_threads using_mheg

Here are 3 of the crashes I am seeing in dmesg.

mythbackend[8184]: segfault at 100000007 ip 00007f3f240e6fb1 sp 00007f3f1cdce570 error 4 in libc-2.11.2.so[7f3f24072000+150000]

mythbackend[14689] general protection ip:7fa214a9fc8c sp:7fa1ff7fb760 error:0 in libc-2.11.2.so[7fa214a2d000+150000]

mythbackend[315]: segfault at 100000007 ip 00007f16d1e73fb1 sp 00007f16cab5b9d0 error 4 in libc-2.11.2.so[7f16d1dff000+150000]

I am attempting to get a gdb trace at this time. Currently recompiling with debug in order to get a full trace.

[robertm]

Marc,

In the future, can you please gather troubleshooting information before opening a ticket? This is how tickets get lost for years until someone figures out that they are invalid, dupes, etc.

This sounds an awful lot like you have new and old copies of the library .so's on the system (ie, you didn't clean out the old ones, whose filenames were recently bumped to reflect the forthcoming .24 release).

Also, what is the "M" in your source? What patches have you applied?

[MarcT <myrdhn@…>]

2 Gentoo specific patches ​http://github.com/MarcT/mt-mythtv/blob/master/media-tv/mythtv/files/mythtv-0.22-sandbox.patch I brought this into my ebuild from the gentoo ebuild. And ​http://github.com/MarcT/mt-mythtv/blob/master/media-tv/mythtv/files/gentoo-myth-config-fix.diff I discovered this one ​http://github.com/MarcT/mt-mythtv/issues/closed#issue/5 The reason for this is that in Gentoo $incdir, $bindir, and $datadir all include $(prefix) in front of the actual location. Because $(prefix) is the same as $(INSTALL_ROOT) it was installing into places like /var/tmp/portage/media-tv/mythtv-9999/image/var/tmp/portage/media-tv/mythtv-9999/imageusr/include/mythtv and causing an install failure.

Then there is this from the ebuild

        # upstream wants the revision number in their version.cpp
        # since the subversion.eclass strips out the .svn directory
        # svnversion in MythTV's build doesn't work
        sed -e "s:\`(svnversion \$\${SVNTREEDIR} 2>\/dev\/null) || echo Unknown\`:${MYTHTV_SVN_REVISION}:" \
                -i "${S}"/version.pro || die "svnversion sed failed"

Also, Gentoo should clean out all the old files as part of the ebuild install, but let me look into that. Currently still building debug, I hadnt had issues in such a long time that I had removed debug from my flags and have no debugging builds installed. My apologies.

[MarcT <myrdhn@…>]

Now that debugging is enabled I can not repro the issue.
I can't tell you what it was, but I can tell you what it was not.
It was not the old .so's
It was not the patches I apply for it to work with Myth.
It is possible that one of the other dependencies which I put into debug mode fixed the issue as some of them were updated in the process of building with debug.
Close this please. If I can recreate it I'll open a new ticket with all the information.

[robertm]

Thanks Marc, please feel free to reopen if you are able to get a backtrace on this.

[MarcT <myrdhn@…>]

Spoke too soon. Unfortunately I was not at home or running gdb at the time this occured. What I have is what was in my backend log.
I'll try to get another one using GDB but I dont know how long it will take.

[robertm]

Dupe of #9005.