Modify

Ticket #7714 (closed defect: Fixed)

You must read the TicketHowTo before creating a new ticket or commenting on an existing ticket.

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

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.

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:4 Changed 23 months ago by mdean

Backtrace included on #8245

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:6 Changed 22 months ago by mdean

Ref #8310

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:8 Changed 22 months ago by mdean

Ref [24291]

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

25daba43 was merged to master in 2c8a1c97f . I'm closing this ticket as fixed, since I'm unable to reproduce the issue. If users running code from the unstable (master) branch see segfaults after 2c8a1c97f on mythfilldatabase runs, please open a new ticket.

comment:18 Changed 9 months ago by danielk

  • Status changed from assigned to closed
  • Resolution set to Fixed

Fixed by [25daba43].

View

Add a comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.