FS#8815 - mythtv 0.20.2.20071129-1 - mythbackend segmentation fault

Attached to Project: Arch Linux
Opened by Alex Charrett (acharrett) - Sunday, 02 December 2007, 13:42 GMT
Last edited by Paul Mattal (paul) - Monday, 04 February 2008, 04:13 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Paul Mattal (paul)
Architecture i686
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I can replicate a mythbackend segfault every time I use mythweb to go into "backend status". Even with all logging switched on nothing useful appears in mythbackend.log.

The most (not terribly) useful thing I've managed to get is from running strace against mythbackend when it fails:

gettimeofday({1196589504, 470225}, NULL) = 0
gettimeofday({1196589504, 470368}, NULL) = 0
select(14, [6 7 13], [], [], {20, 389404}) = 1 (in [6], left {20, 343333})
accept(6, {sa_family=AF_INET, sin_port=htons(47069), sin_addr=inet_addr("192.168.160.1")}, [16]) = 16
fcntl64(16, F_SETFD, FD_CLOEXEC) = 0
futex(0x81a7b9c, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x818ad14, 0) = 1
futex(0x818ad14, FUTEX_WAKE_PRIVATE, 1) = 1
gettimeofday({1196589504, 519775}, NULL) = 0
gettimeofday({1196589504, 519952}, NULL) = 0
select(14, [6 7 13], [], [], {20, 339820}) = ? ERESTARTNOHAND (To be restarted)
+++ killed by SIGSEGV +++

backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2f8fb90 (LWP 7000)]
0xb5d9936d in fclose@@GLIBC_2.1 () from /lib/libc.so.6
(gdb) bt
#0 0xb5d9936d in fclose@@GLIBC_2.1 () from /lib/libc.so.6
#1 0x0807cca3 in ?? ()
#2 0x080844fc in ?? ()
#3 0x080845f0 in ?? ()
#4 0xb6ef2355 in HttpServer::DelegateRequest () from /usr/lib/libmythupnp-0.20.2.so.0
#5 0xb6ef3345 in HttpWorkerThread::ProcessWork () from /usr/lib/libmythupnp-0.20.2.so.0
#6 0xb6eef4ec in WorkerThread::run () from /usr/lib/libmythupnp-0.20.2.so.0
#7 0xb63bfd85 in QThreadInstance::start () from /opt/qt/lib/libqt-mt.so.3
#8 0xb5f9b162 in start_thread () from /lib/libpthread.so.0
#9 0xb5e0626e in clone () from /lib/libc.so.6
(gdb)

Core dump: http://charrett.com/core.mythbackend.bz2 (2.4MB)
This task depends upon

Closed by  Paul Mattal (paul)
Monday, 04 February 2008, 04:13 GMT
Reason for closing:  Fixed
Comment by Paul Mattal (paul) - Monday, 31 December 2007, 15:51 GMT
Can you tell me what version of lm_sensors you have installed? Versions 3.0.0 and up seem to be giving us fits, and I'm not sure yet if this is a related crash or not.
Comment by Alex Charrett (acharrett) - Monday, 31 December 2007, 16:02 GMT
This was with lm_sensors 3.0.0-1, as I understand it mythtv 0.20.2.20071129-1 should have been patched to use lm_sensors 3?

I've had to roll back to lm_sensors 2.10.5-2 and mythtv 0.20.0.20070131-2 to get my system working again.
Comment by Paul Mattal (paul) - Monday, 31 December 2007, 16:05 GMT
It was indeed patched, but I don't think the patch was complete enough. Funny thing is I don't see anything like those patches (or even related bug reports) appearing upstream at mythtv, which strikes me as odd given that our lm_sensors 3.0.0-1 package is dated over a month ago. I'd expect others would be having this problem.

I'll keep looking into this.
Comment by Paul Mattal (paul) - Thursday, 24 January 2008, 03:12 GMT
Try the new version in testing, 20071129-2. With this version, I think I've removed the dependency on lm_sensors, at least for now until they get this sorted out officially. There's an official way to do this in the 0.21 tree, but not yet in 0.20.x, so I just required that lm_sensors NOT be installed on the build system.
Comment by Alex Charrett (acharrett) - Sunday, 03 February 2008, 08:11 GMT
OK, I've upgraded to 20071129-2 (and removed lm_sensors from my system) and everything seems to be functioning fine.

Thanks!

Loading...