Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4174 closed defect (fixed)

Pinging backend port causes occasional crash

Reported by: steveskarda@… Owned by: Isaac Richards
Priority: minor Milestone: 0.21
Component: mythtv Version: 0.20.2
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Checking backend status on port 6544 causes the backend to crash 1-2 times a day. This has been reported with monit, mythgrowl, and user written scripts that grab xml data. Nothing shows up in mythbackend log, even in verbose mode.

Backtrace posted here: http://www.gossamer-threads.com/lists/mythtv/users/297060

Additional info here: http://www.gossamer-threads.com/lists/mythtv/users/299696

This problem fist started occurring for me in 0.20.2. It is still present in the latest trunk as of a week ago. I'd be happy to help with testing.

Change History (7)

comment:1 Changed 11 years ago by adam@…

Based on the backtrace at http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=11558;list=mythtv to my rather uninformed eyes this looks like the culprit:

Thread 8 (Thread 1132505424 (LWP 27161)):
#0  0x00002b908f654a61 in QShared::deref () from /usr/lib/libqt-mt.so.3
No symbol table info available.
#1  0x00002b908f72bafb in QObject::~QObject () from /usr/lib/libqt-mt.so.3
No symbol table info available.
#2  0x00002b908f6f0819 in QGuardedPtrPrivate::~QGuardedPtrPrivate () from /usr/lib/libqt-mt.so.3
No symbol table info available.
#3  0x00002b908c56b376 in SelectManagedListItem::~SelectManagedListItem () from /usr/lib/libmyth-0.20.2.so.0
No symbol table info available.
#4  0x00002b908f72bcc2 in QObject::~QObject () from /usr/lib/libqt-mt.so.3
No symbol table info available.
#5  0x00002b908a625714 in SRDupIn::~SRDupIn () from /usr/lib/libmythtv-0.20.2.so.0
No symbol table info available.
#6  0x00002b908c463633 in ConfigurationGroup::~ConfigurationGroup () from /usr/lib/libmyth-0.20.2.so.0
No symbol table info available.
#7  0x00002b908a630382 in ScheduledRecording::~ScheduledRecording () from /usr/lib/libmythtv-0.20.2.so.0
No symbol table info available.
#8  0x00002b908a4eed6b in ProgramInfo::~ProgramInfo () from /usr/lib/libmythtv-0.20.2.so.0
No symbol table info available.
#9  0x000000000042f0e0 in ?? ()
No symbol table info available.
#10 0x0000000000432eb2 in ?? ()
No symbol table info available.
#11 0x000000000043312b in ?? ()
No symbol table info available.
#12 0x00002b908bdd8f73 in HttpServer::DelegateRequest () from /usr/lib/libmythupnp-0.20.2.so.0
No symbol table info available.
#13 0x00002b908bdd9546 in HttpWorkerThread::ProcessWork () from /usr/lib/libmythupnp-0.20.2.so.0
No symbol table info available.
#14 0x00002b908bdd68ce in WorkerThread::run () from /usr/lib/libmythupnp-0.20.2.so.0
No symbol table info available.
#15 0x00002b908f6bc10a in QThreadInstance::start () from /usr/lib/libqt-mt.so.3
No symbol table info available.
#16 0x00002b9090acf317 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#17 0x00002b9091552d5d in clone () from /lib/libc.so.6
No symbol table info available.
#18 0x0000000000000000 in ?? ()
No symbol table info available.

comment:2 Changed 11 years ago by stuartm

Milestone: unknown0.21

comment:3 Changed 11 years ago by Bill <level42@…>

If your using lmsensors to report temperatures or fan speed at all this may be the cause (or related).

I removed lmsensors the problem went away. I haven't had time to figure out why. This was the case when Lmsensors was part of the myth code and also the case with the new code that uses an external script for lmsensors.

comment:4 Changed 11 years ago by anonymous

I really don't see how reading motherboard sensors data could possible cause a crash of mythtv.

On the 0.20.2 line I consistently was able to crash myth simply by running this nagios monitoring command:

/usr/lib/nagios/plugins/check_tcp -H $HOSTADDRESS$ -p 6543

I ended un changing this to use port 6544, and to do a complete HTTP request, (which is better for this purpose anyhow) and things got quite a bit better.

comment:5 Changed 11 years ago by anonymous

I just ran the above TCP "ping" command about 50 times against a server running latest subversion trunk (r15269) and was not able to crash it. Likewise, even tho I monitor port 6544, the consistent crashes I used to experience in version 0.20.x no longer seem to plague me.

comment:6 Changed 11 years ago by stuartm

Resolution: fixed
Status: newclosed

Fixed in current trunk.

comment:7 Changed 11 years ago by superm1@…

Any ideas what changeset(s) had resolved this?

Note: See TracTickets for help on using tickets.