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)
Change History (8)
comment:1 Changed 16 years ago by
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
comment:2 Changed 16 years ago by
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
Milestone: | unknown → 0.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
Owner: | changed from Isaac Richards to danielk |
---|---|
Status: | new → assigned |
comment:5 Changed 15 years ago by
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
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.
A crash backtrace