Opened 17 years ago

Closed 17 years ago

#3804 closed defect (invalid)

mythbackend crashes everytime mythfilldatabase completes

Reported by: anonymous Owned by: stuartm
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

A couple of days ago, I upgraded to the latest SVN version (14150). Since then, I have encountered seg faults just after mythfilldatabase completes.

Here is an excerpt of the mythbackend.log file.

2007-08-07 17:28:41.574 mythfilldatabase run complete.
2007-08-07 17:28:41.550 Reschedule requested for id -1.
2007-08-07 17:28:41.550 Received a remote 'Clear Cache' request
Segmentation fault (core dumped)
2007-08-07 17:28:44.179 Scheduled 117 items in 2.6 = 1.42 match + 1.20 place
[mpeg2video @ 0x2aae83b28b30]invalid cbp at 8 28
[mpeg2video @ 0x2aae83b28b30]Warning MVs not available
2007-08-07 17:33:46.705 DB Error (ClearMarkupMap deleting):
Query was:
DELETE FROM recordedmarkup WHERE chanid = '1061' AND STARTTIME = '2007-07-24T21:00:00' AND type = -3 ;
Driver error was [2/145]:
QMYSQL3: Unable to execute query
Database error was:
Table './mythconverg/recordedmarkup' is marked as crashed and should be repaired

In this case, mythconverg was corrupted. In other seg faults, the database survived intact.

Change History (9)

comment:1 in reply to:  description Changed 17 years ago by trgreer@…

Replying to anonymous:

A couple of days ago, I upgraded to the latest SVN version (14150). Since then, I have encountered seg faults just after mythfilldatabase completes.

Here is an excerpt of the mythbackend.log file.

2007-08-07 17:28:41.574 mythfilldatabase run complete.
2007-08-07 17:28:41.550 Reschedule requested for id -1.
2007-08-07 17:28:41.550 Received a remote 'Clear Cache' request
Segmentation fault (core dumped)
2007-08-07 17:28:44.179 Scheduled 117 items in 2.6 = 1.42 match + 1.20 place
[mpeg2video @ 0x2aae83b28b30]invalid cbp at 8 28
[mpeg2video @ 0x2aae83b28b30]Warning MVs not available
2007-08-07 17:33:46.705 DB Error (ClearMarkupMap deleting):
Query was:
DELETE FROM recordedmarkup WHERE chanid = '1061' AND STARTTIME = '2007-07-24T21:00:00' AND type = -3 ;
Driver error was [2/145]:
QMYSQL3: Unable to execute query
Database error was:
Table './mythconverg/recordedmarkup' is marked as crashed and should be repaired

In this case, mythconverg was corrupted. In other seg faults, the database survived intact.

Like a dummy, I posted this as anonymously. Here is my email address. Let me know if you need more information.

Tom

comment:2 Changed 17 years ago by stuartm

Owner: changed from Isaac Richards to stuartm
Version: unknownhead

Could you clarify, is mythfilldatabase segfaulting or is the mythbackend segfaulting? The log you posted shows that mythfilldatabase is segfaulting, this is a known QT 3.3.8 bug and cannot be fixed within mythtv. I'm guessing that at the same time you upgraded mythtv you also upgraded other packages on your system including QT?

comment:3 in reply to:  2 Changed 17 years ago by trgreer@…

Replying to stuartm:

Could you clarify, is mythfilldatabase segfaulting or is the mythbackend segfaulting? The log you posted shows that mythfilldatabase is segfaulting, this is a known QT 3.3.8 bug and cannot be fixed within mythtv. I'm guessing that at the same time you upgraded mythtv you also upgraded other packages on your system including QT?

This was an update to mythtv only. No other system updates were performed.

I upgraded on 8/6 - and restarted the backend around 16:28. The log shows the first seg fault at 18:17 on the 6th right after mythfilldatabase completed. Reviewing the logs all the way back to 8/1, there were no other seg faults.

After the upgrade, there is a seg fault after each mythfilldatabase run.

BTW, how can you tell that it is mythfilldatabase that is segfaulting? I can't differentiate between the two.

comment:4 Changed 17 years ago by stuartm

If mythbackend segfaulted you wouldn't see any further entries in the log, the process would no longer be running. You can run mythfilldatabase manually from a terminal to confirm that it is the application which is segfaulting.

Also try to find out which version of QT you have installed. (Using qtconfig for example).

comment:5 in reply to:  4 Changed 17 years ago by trgreer@…

Replying to stuartm:

If mythbackend segfaulted you wouldn't see any further entries in the log, the process would no longer be running. You can run mythfilldatabase manually from a terminal to confirm that it is the application which is segfaulting.

Also try to find out which version of QT you have installed. (Using qtconfig for example).

OK. I can see that mythbackend continues without interruption. Thanks for the education.

However, when I run mythfilldatabase from the command line, it completes successfully.

Regarding my QT version, that is not clear to me. I did not have qtconfig installed. So I fired up synaptic (I'm using Ubuntu) figuring I could see which version of qt was installed. It tells me that I have libqt-headers version 3.3.8. But in the description of the package, it says: 'Version: 3.3.8really3.3.7-ubuntu5.1'.

Since that was unclear, I installed the package containing qtconfig and ran it. It tells me the version is 3.3.7.

Perhaps the problem that I am seeing is related to Changeset 14124 which moved the clearance of old program data from mythfilldatabase to mythbackend/housekeeper.cpp?

comment:6 Changed 17 years ago by stuartm

I'd ask for a backtrace, but because mythfilldatabase isn't segfaulting when run manually that could be difficult. See the following guide anyway - http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2

Could you try running make distclean, rebuilding and installing? I can't see any problems with recent commits and it's possible that this is just one of those odd build/install issues.

There remains the possibility that this is the QT bug, aside from some ambiguity over the installed version of QT it has many of the hallmarks of that problem.

comment:7 in reply to:  6 Changed 17 years ago by anonymous

Replying to stuartm:

I'd ask for a backtrace, but because mythfilldatabase isn't segfaulting when run manually that could be difficult. See the following guide anyway - http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2

Could you try running make distclean, rebuilding and installing? I can't see any problems with recent commits and it's possible that this is just one of those odd build/install issues.

That's pretty radical. This problem is annoying to me, but the rest of the family has not noticed. (The DB corruption was automatically fixed by the nightly optimize_mythdb cron job.)

This is my master backend with three other frontend/backend combos. Right now, the system is queued with recordings for the entire evening...

I'll have to find time to do this. Maybe over the weekend.

There remains the possibility that this is the QT bug, aside from some ambiguity over the installed version of QT it has many of the hallmarks of that problem.

OK. I'll update you once I have re-installed myth. Thanks for the quick attention to this.

comment:8 in reply to:  6 Changed 17 years ago by anonymous

Replying to stuartm:

I'd ask for a backtrace, but because mythfilldatabase isn't segfaulting when run manually that could be difficult. See the following guide anyway - http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2

Could you try running make distclean, rebuilding and installing? I can't see any problems with recent commits and it's possible that this is just one of those odd build/install issues.

There remains the possibility that this is the QT bug, aside from some ambiguity over the installed version of QT it has many of the hallmarks of that problem.

Quick update:

I had a brief period last evening to run make distclean, etc. When I restarted mythbackend, it called mythfilldatabase in short order - and everything ran fine.

However, overnight, mythfilldatabase ran again and segfaulted. When I scanned my log files for the past couple of days, there were a several other times that mythfilldatabase ran to completion without segfaulting.

Over the weekend, hopefully I'll find some time to compile in debugging and get you a backtrace.

One last comment, I thought that mythfilldatabase would run once per day per lineup (I let datadirect when to run). But it looks like mythfilldatabase ran 7 times yesterday (including 4 times since I recompiled). Strange.

comment:9 Changed 17 years ago by stuartm

Resolution: invalid
Status: newclosed

I'm closing this as invalid until the submitter is able to attach a valid backtrace.

Note: See TracTickets for help on using tickets.