Opened 8 years ago

Closed 8 years ago

#10085 closed Bug Report - Crash (Unverified)

Intermittent crash with logging to DB enabled

Reported by: paulh Owned by: beirdo
Priority: minor Milestone: unknown
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The attached BT shows a crash in mytharchivehelper but I believe it affects all the command line tools that start up and exit quickly.

Attachments (4)

mytharchivehelper_crash.txt (17.9 KB) - added by paulh 8 years ago.
mytharchivehelper crash running 'mytharchivehelper -p --output=test.txt'
10085.patch (1.2 KB) - added by danielk 8 years ago.
mytharchivehelper_crash2.txt (18.2 KB) - added by paulh 8 years ago.
Crash after cleanup guard added
log.txt (1.9 KB) - added by paulh 8 years ago.

Download all attachments as: .zip

Change History (15)

Changed 8 years ago by paulh

Attachment: mytharchivehelper_crash.txt added

mytharchivehelper crash running 'mytharchivehelper -p --output=test.txt'

comment:1 Changed 8 years ago by danielk

It looks like gContext is never deleted in most returns from mytharchivehelper's main function.

The MythContext destructor doesn't just shut down the logging thread. There are at least a half dozen other ways a program that constructs MythContext and never deletes it can segfault just before exit.

Changed 8 years ago by danielk

Attachment: 10085.patch added

comment:2 Changed 8 years ago by danielk

Paul, I don't know how one runs mytharchivehelper, but the attached patch is a pretty boilerplate fix for this type of object lifetime problem.

comment:3 Changed 8 years ago by Github

Add CleanupGuard? to mytharchivehelper

Refs #10085

Signed-off-by: Gavin Hurlbut <ghurlbut@…>

Branch: master Changeset: cfeca636694219d4dd7ef021be5e3f12d57c5693

comment:4 Changed 8 years ago by beirdo

Owner: set to beirdo
Status: newassigned

Changed 8 years ago by paulh

Crash after cleanup guard added

comment:5 Changed 8 years ago by paulh

Adding the cleanup guard has made no difference still getting the same crash. New bt added.

comment:6 Changed 8 years ago by beirdo

OK. Could you bring up gdb with that coredump again, and do:

thread 1
up

and continue to go up until you are at #5 which is the logqmsg at logging.cpp:651 or so.

Then

print *info
print query

Also, what is your locale set to?

comment:7 Changed 8 years ago by paulh

(gdb) thread 1
[Switching to thread 1 (Thread 28537)]#0  0x0000000000000000 in ?? ()
(gdb) up
#1  0x00007f5b24ee6327 in QTextCodec::fromUnicode(QString const&) const () from /usr/lib64/qt4/libQtCore.so.4
(gdb) up
#2  0x00007f5b19de58fc in ?? () from /usr/lib64/qt4/plugins/sqldrivers/libqsqlmysql.so
(gdb) up
#3  0x00007f5b266d08f6 in QSqlQuery::exec() () from /usr/lib64/qt4/libQtSql.so.4
(gdb) up
#4  0x00007f5b295a47f1 in MSqlQuery::exec (this=0x721c60) at mythdbcon.cpp:651
651         bool result = QSqlQuery::exec();
(gdb) up
#5  0x00007f5b29648041 in DatabaseLogger::logqmsg (this=0x6a8240, query=..., item=0x6b51e0) at logging.cpp:462
462         if (!query.exec())
(gdb) print *info
No symbol "info" in current context.
(gdb) print query
$1 = (MSqlQuery &) @0x721c60: {<QSqlQuery> = {d = 0x71d3c0}, m_db = 0x6c0d70, m_isConnected = true, m_returnConnection = true, 
  m_last_prepared_query = {d = 0x6b3620}}
(gdb) print item.message 
$2 = "Added database logging to table logging", '\000' <repeats 1889 times>
(gdb)
$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

comment:8 Changed 8 years ago by beirdo

Argh, I did mean item, not info. My bad. You got us what I was looking for anyways. Thanks. Hmm. Could you attach the debug logs (which hopefully you had running) for the crashed process? It seems to be a unicode vs utf-8 issue, which I believe there has been some extra diagnostic logging added fairly recently.

Changed 8 years ago by paulh

Attachment: log.txt added

comment:9 Changed 8 years ago by paulh

Added a log. Just to remind you it doesn't crash every time only about 1 out of 6 attempts.

comment:10 Changed 8 years ago by beirdo

Status: assignedinfoneeded

I can't recreate this issue with current master. Is this fixed? If not, do you have another commandline that exhibits the issue so I can retest? In 20 runs of the command given (with --output replaced with --outfile), not a single crash.

comment:11 Changed 8 years ago by beirdo

Resolution: Unverified
Status: infoneededclosed

5 weeks with no confirmation... Closing this.

Note: See TracTickets for help on using tickets.