Ticket #7714 (closed defect: Fixed)
Opened 2 years ago
Last modified 9 months ago
Handling events received at shutdown causes segfault (mythfilldatabase, mythfrontend)
| Reported by: | superm1@… | Owned by: | danielk |
|---|---|---|---|
| Priority: | trivial | Milestone: | 0.25 |
| Component: | MythTV - General | Version: | Master Head |
| Severity: | low | Keywords: | Mythfilldatabase segfaults after completing |
| Cc: | Ticket locked: | no |
Description
During the daily guide updates, I received a segfault. This is with 0.22 fixes, rev 22936.
A single thread bt is available at: http://launchpadlibrarian.net/36303383/Stacktrace.txt A multi thread bt is available at: http://launchpadlibrarian.net/36303384/ThreadStacktrace.txt
The mythbackend log is available at: http://launchpadlibrarian.net/36303374/.var.log.mythtv.mythbackend.log.txt
Attachments
Change History
comment:1 Changed 2 years ago by anonymous
comment:2 Changed 2 years ago by stuartm
- Priority changed from minor to trivial
- Severity changed from medium to low
comment:3 Changed 2 years ago by stuartm
- Summary changed from Mythfilldatabase segfaults during run to Mythfilldatabase segfaults after completing
comment:5 Changed 23 months ago by jan@…
If #8246 is really a dupe, then this is more than a cosmetic issue, because for me the import doesn't finish. I don't have any xmltv provided EPG data anymore. Since the EIT sometimes provides different show names or sub titles, my rules cease to work in about a week. Though I don't want to hurry anyone. :-)
comment:7 Changed 22 months ago by Marc Randolph <mrand@…>
This appears to be a slightly better backtrace. mythfilldatabase log looked relatively normal, simply ending with:
2010-04-26 06:25:04.251 MythContext: Connecting to backend server: 192.168.2.22:6543 (try 1 of 1) 2010-04-26 06:25:04.252 Using protocol version 56 2010-04-26 06:25:04.501 Received a remote 'Clear Cache' request 2010-04-26 06:25:04.503 mythfilldatabase run complete. 2010-04-26 06:25:04.504 DataDirect?: Deleting temporary files Segmentation fault (core dumped)
#0 0x0806546c in QBasicAtomicInt::operator!= (this=0x8, value=1)
at /usr/include/qt4/QtCore/qbasicatomic.h:69
No locals.
#1 0x003ef634 in QHash<QString, QString>::detach (this=0x3f627ac)
at /usr/include/qt4/QtCore/qhash.h:281
No locals.
#2 0x02a51b67 in QHash<QString, QString>::reserve (this=0x3f627ac, asize=61)
at /usr/include/qt4/QtCore/qhash.h:821
No locals.
#3 0x02a50b9a in MythDB::ClearSettingsCache (this=0x9beeff0, _key=...)
at mythdb.cpp:789
it = {i = 0xb688bd78}
#4 0x01f5483c in MythContext::ClearSettingsCache (this=0x9bf9848, myKey=...)
at mythcontext.cpp:1865
No locals.
#5 0x01f56639 in MythContext::readyRead (this=0x9bf9848, sock=0x9c661a8)
at mythcontext.cpp:2121
strlist = {<QList<QString>> = {{p = {static shared_null = {ref = {
_q_value = 95}, alloc = 0, begin = 0, end = 0,
sharable = 1, array = {0x0}}, d = 0x9c67438},
d = 0x9c67438}}, <No data fields>}
prefix = {static null = {<No data fields>}, static shared_null = {
ref = {_q_value = 124}, alloc = 0, size = 0, data = 0x80a06a2,
clean = 0, simpletext = 0, righttoleft = 0, asciiCache = 0,
capacity = 0, reserved = 0, array = {0}}, static shared_empty = {
ref = {_q_value = 1875}, alloc = 0, size = 0, data = 0x3f6446e,
clean = 0, simpletext = 0, righttoleft = 0, asciiCache = 0,
capacity = 0, reserved = 0, array = {0}}, d = 0x9c8df00,
static codecForCStrings = 0x0}
message = {static null = {<No data fields>}, static shared_null = {
ref = {_q_value = 124}, alloc = 0, size = 0, data = 0x80a06a2,
clean = 0, simpletext = 0, righttoleft = 0, asciiCache = 0,
capacity = 0, reserved = 0, array = {0}}, static shared_empty = {
ref = {_q_value = 1875}, alloc = 0, size = 0, data = 0x3f6446e,
clean = 0, simpletext = 0, righttoleft = 0, asciiCache = 0,
capacity = 0, reserved = 0, array = {0}}, d = 0x9c16bf0,
static codecForCStrings = 0x0}
#6 0x02a3a755 in MythSocketThread::ReadyToBeRead (this=0x9bc7cc0,
sock=0x9c661a8) at mythsocketthread.cpp:165
bytesAvail = 58
#7 0x02a3d260 in MythSocketThread::run (this=0x9bc7cc0)
at mythsocketthread.cpp:352
rrtm = {mds = 23104501}
socket = 12
timers = {{d = 0x80a06c0, e = 0x80a06c0}}
maxfd = 13
rfds = {fds_bits = {4096, 0 <repeats 31 times>}}
it = {i = 0x9c149c4}
rval = 1
downref_tm = 0
tm = {mds = 23104501}
locker = {{mtx = 0x9bc7ccd, val = 163347661}}
#8 0x03d81e32 in ?? () from /usr/lib/libQtCore.so.4
No symbol table info available.
#9 0x07e2480e in start_thread (arg=0xb688cb70) at pthread_create.c:300
__res = <value optimized out>
__ignore1 = <value optimized out>
__ignore2 = <value optimized out>
pd = 0xb688cb70
now = <value optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {132337652, 0, 4001536,
-1232550840, 1796310535, -1105659035}, mask_was_saved = 0}},
priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 0}}}
not_first_call = <value optimized out>
robust = <value optimized out>
#10 0x01c198de in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
No locals.
This is against 0.23+fixes24220
comment:9 Changed 18 months ago by robertm
- Owner changed from stuartm to mdean
- Status changed from new to assigned
This should be long since fixed.
comment:10 Changed 17 months ago by beirdo
- Version changed from 0.22-fixes to Trunk Head
This is still the case with trunk at [26520]. I've updated the affected version to be trunk.
comment:11 Changed 16 months ago by mdean
(In [26629]) Refs #7714. Add a cleanup guard to mythfilldatabase to ensure we always delete the gContext and set it to NULL regardless of where we exit.
Although all returns from mythfilldatabase's main() function properly deleted the gContext, we did not set gContext to NULL after the delete. Therefore, the only real difference in this patch is setting gContext to NULL after deleting it.
comment:12 Changed 16 months ago by beirdo
(In [26746]) Cleanup the database connection after DestroyMythDB() in the MythCoreContext? class. This seems to fix the mythfilldatabase crashes on shutdown when running under mythbackend. Hopefully it is the last niggling issue there.
Refs #7714. (we hope it fixes it)
comment:13 Changed 15 months ago by mdean
Ref [27071] (adds sleep(1) workaround for 0.24-fixes).
comment:14 Changed 12 months ago by beirdo
Referred to by a4ba70865147. This commit is attempting to prevent a deadlock waiting on shutdown.
comment:15 Changed 12 months ago by mdean
- Keywords Mythfilldatabase segfaults after completing added
- Component changed from MythTV - Mythfilldatabase to MythTV - General
- Summary changed from Mythfilldatabase segfaults after completing to Handling events received at shutdown causes segfault (mythfilldatabase, mythfrontend)
See, also, #9580 for additional backtrace (from mythfrontend).
comment:16 Changed 10 months ago by mdean
Ref 25daba43, which may fix the issue (thanks Daniel K.)
In 25daba43:
Make sure we shut down read ahead thread before we delete mythcorecontext. This avoids segfaults when a dispatch event is triggered by an event. This also makes a related change to the mythobservable dtor to make this a segfault unlikely even when an event is dispateched after the mythobservable is deleted.
comment:17 Changed 9 months ago by mdean
- Owner changed from mdean to danielk
- Milestone changed from unknown to 0.25
comment:18 Changed 9 months ago by danielk
- Status changed from assigned to closed
- Resolution set to Fixed
Fixed by [25daba43].

Confirming this harmless nuisance on my backend; happens very frequently and looks like a race condition to me. BT shows one thread at main.cpp:959, just after "delete gContext". Second thread is MythSocketThread?, which segfaults as it was processing the CLEAR_SETTINGS_CACHE initiated by main.cpp:955. It segfaults because "delete gContext" at main.cpp:957 destroys MythDB object while the second thread is using it. Hack approach might be to throw a usleep in here to reduce the frequency of these segfaults, but certainly there are better solutions.