Opened 16 years ago

Closed 15 years ago

#4993 closed defect (worksforme)

Mythbackend crashes frequently

Reported by: anonymous Owned by: danielk
Priority: minor Milestone: 0.22
Component: mythtv Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description

Running svn revision: 16554. Though this has happened for a while now.

I have a DVB-C set-up (Technotrend card) and currently mythbackend just crashes every few hours. EPG data is updated via EIT.

The logs show following errors just before the crash:


2008-03-18 10:16:08.893 DB Error (Looking up chanID): Query was:

No error type from QSqlError? Strange... 2008-03-18 10:16:08.907 DB Error (Looking up chanID): Query was:

No error type from QSqlError? Strange... QSqlQuery::exec: empty query 2008-03-18 10:16:08.910 DB Error (Looking up chanID): Query was:


This is repeated ~hundred times before mythbackend finally crashes with following backtrace:


* glibc detected * /usr/local/bin/mythbackend: double free or corruption (fasttop): 0x082d5618 * ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb597dd65] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb5981800] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb5b46d81] /usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0xb5b46ddd] /usr/lib/libqt-mt.so.3(_ZN11QStringDataD1Ev+0x34)[0xb642ed30] /usr/lib/libqt-mt.so.3(_ZN11QStringData10deleteSelfEv+0x23)[0xb64264b5] /usr/local/lib/libmyth-0.21.so.0(_ZN12MSqlDatabase12KickDatabaseEv+0x55)[0xb6ae4c67] /usr/local/lib/libmyth-0.21.so.0(_ZN9MSqlQuery7InitConEv+0x56)[0xb6ae96b2]


This defect looks similar to the one in ticket #4695.

Attachments (3)

gdb.txt (35.7 KB) - added by anonymous 16 years ago.
A crash backtrace
gdb2.txt (56.3 KB) - added by anonymous 16 years ago.
Another crash
gdb3.txt (134.6 KB) - added by anonymous 16 years ago.
Two more crash backtraces

Download all attachments as: .zip

Change History (8)

Changed 16 years ago by anonymous

Attachment: gdb.txt added

A crash backtrace

comment:1 Changed 16 years ago by anonymous

Attached a gdb.txt file with a backtrace from a segmentation fault that occurred last night. In this case the crash seemed to occur at:


_ts_writing_listeners[j]->ProcessTSPacket(tspacket);



#0 0xb7947a6e in MPEGStreamData::ProcessTSPacket (this=0xa930d4a0, tspacket=@0xa7b4e1d0) at mpeg/mpegstreamdata.cpp:986

j = 0 ok = true

#1 0xb79448b7 in MPEGStreamData::ProcessData? (this=0xa930d4a0, buffer=0xa7b4c008 "G\002", len=13724) at mpeg/mpegstreamdata.cpp:944

pkt = (const TSPacket *) 0xa7b4e1d0 pos = 8648

#2 0xb7d5ed38 in DVBStreamHandler::RunTS (this=0x82ce7e0) at dvbstreamhandler.cpp:334

i = 0 len = 13724 remainder = 0 buffer_size = 2820000 buffer = (unsigned char *) 0xa7b4c008 "G\002" dvr_fd = 15 _error = false fd_select_set = {fds_bits = {32768, 0 <repeats 31 times>}}

#3 0xb7d5f44c in DVBStreamHandler::Run (this=0x82ce7e0) at dvbstreamhandler.cpp:221 No locals. #4 0xb7d5f475 in run_dvb_stream_handler_thunk (param=0x82ce7e0) at dvbstreamhandler.cpp:173

mon = (DVBStreamHandler *) 0x82ce7e0


Changed 16 years ago by anonymous

Attachment: gdb2.txt added

Another crash

Changed 16 years ago by anonymous

Attachment: gdb3.txt added

Two more crash backtraces

comment:2 Changed 16 years ago by anonymous

Some feedback which may be of use to others.

Resolved this type of error message by turning off hyperthreading in the BIOS. Computer is P4 2.8GHz ASUS P4S800D-X running Ubuntu 8.04 desktop with standard Ubuntu MythTV 0.21 packages, ext3 filesystems, UK setup with three Nova T cards, EIT feed only. For info, hyperstreaming was always off in the BIOS.

Other feedback - solved 100% CPU usage by turning off slow deletes - noticed that first auto-expiration after boot made mythbackend go to 100% CPU usage permanently. Turning off slow deletes cured this. Also turned off monit checking of mythtv http socket - suspect this also causes problems in MythTV.

Had one or two seg faults after making these changes (caught by monit), but backend has been stable for 3 days now.

comment:3 Changed 16 years ago by stuartm

Milestone: unknown0.22

First backtrace looks like a null or invalid pointer in the _ts_writing_listeners vector. ProcessTSPacket doesn't get a _listener_lock and possibly should to prevent read a value from the vector which has been deleted?

The second backtrace is a QString segfault which is hopefully fixed in trunk.

Third backtrace is useless.

comment:4 Changed 15 years ago by Dibblah

Owner: changed from Isaac Richards to danielk
Status: newassigned

comment:5 Changed 15 years ago by danielk

Resolution: worksforme
Status: assignedclosed

I can't find the bug for the first backtrace, since this ticket is pretty old it is possible it has been fixed, but I can't be sure. In future please open separate tickets for each backtrace.

Note: See TracTickets for help on using tickets.