Backend frequently segfaults

[Mark Buechler <Mark.Buechler@…>]

The backend frequently crashes. See attached backtrace and backend log. I'm running trunk 14813.

[Mark Buechler <Mark.Buechler@…>]

Backtrace

[Mark Buechler <Mark.Buechler@…>]

Backend log

[Mark Buechler <Mark.Buechler@…>]

Excerpt from another run of the backend showing DB errors

[Mark Buechler <Mark.Buechler@…>]

I suspect there is something going on with KickDatabase?(). I've seen a couple times when the backend for some reason looses contact with the DB and never regains it (see backend-db.txt attachment).

I was able to fallback to the -vid branch (v14391) compiled with the same gcc/g++ version (4.1.3 20070514). I've tried two different QT versions (one Debian installed, the other hand compiled).

• Mark.

[Mark Buechler <Mark.Buechler@…>]

In tracing this bt through, I'm a bit concerned that KickDatabase?() is being called at all since my database, being on the same host, is never at any point unavailable. I suspect there's some sort of timeout involved here and it only seems to happen during heady EIT processing.

The issue seems to have gotten a lot worse with the addition of frequent checks to QSqlDatabase::hostName() in libmyth/mythdbcon.cpp. I'm attaching a patch which keeps the params necessary for QSqlDatabase all local so that the only place calling QSqlDatabase::hostName() is in MSqlQuery and only once. The MSqlDatabase class now gets its parameters from gContext::GetDatabaseParams?() and stores & uses them locally.

Patch attached.

[Mark Buechler <Mark.Buechler@…>]

The patch.

[Nigel]

1) I agree about the high frequency of KickDatabase() calls - on one machine with a local MySQL I got 59 calls to it before the !UPnP BuildMediaMap was generated. I have applied the patch and am comparing behaviour.

2) Instead of adding 4 strings and an int into !MSqlDatabase, why not add a DatabaseParams? As long as it is a local member or struct (and not an object pointer), it should be more efficient?

3) The extra m_db->hostName().length() calls were added by me for bootstrapping. Setting, and checking, a bool might be even more efficient?

[jari DOT seppala (A) iki DOT fi]

I tried the myth_dbcon_r14813.diff patch with svn 0.21-fixes version 16835. It caused my frontend not being able to show LiveTV while one of my tuners was recording. I have 2 DVB-C TT-2300Cs available, one has also working CI+CAM. Also watching recordings had a problem: first blank screen then announcement that could not connect to backend and after pressing OK I got the recording. Reason I tried was that my backend somehow seems to make corrupt recordings every now and then. No errors in log but recording seems like it was recorded while having really bad signal. I'm still trying to find out what happens.

[Nigel]

Jari, thanks for testing. mark, In a few months of using it at home on a slow machine, I noticed no difference to backend behavior. (but then, I didn't have the crashing you were experiencing)
The frequent calls to KickDatabase? are still a concern to me, though. I suspect there should be no reason to close and open the connections if ( m_db->hostName() == "127.0.0.1" ), and KickDatabase? could exit early in that situation?

[anonymous]

Don't KickDatabase?() if it is local

[Nigel]

Mark, are you still seeing this after [17834] ? (or, if you are still using 0.21, have you tried back-porting that patch?)

[Nigel]

Mark said:

I'm still on pre-qt4. I looked at porting that patch to trunk a couple weeks back, but found it to be unnecessary. I suspect the original bug had to do with Qt3 and not MythTV or possibly could have been fixed with some additional locking.

At any rate, I'm running successfully on my test box a much newer trunk without that patch. I suppose the ticket should be closed.

Thanks, Mark.

so this is about to be closed