Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#9893 closed Bug Report - Crash (fixed)

SIGSEGV waking up non-existant threads

Reported by: Ian Dall <ian@…> Owned by: beirdo
Priority: minor Milestone: 0.25
Component: MythTV - General Version: Unspecified
Severity: medium Keywords:
Cc: Ticket locked: no


Version: v0.25pre-2556-gc12e7d7-dirty

I am seeing SIGSEGV almost immediately on starting mythbackend. This happens often but not always. I haven't been able to figure out the circumstances in which this happens. It might be related to the order in which threads are run.

There is no log file, but the console output is:

2011-07-02 15:43:33.136749 C mythbackend version: master [v0.25pre-2556-gc12e7d7-dirty] 2011-07-02 15:43:33.136925 C Enabled verbose msgs: important general 2011-07-02 15:43:33.136988 C Setting Log Level to LOG_INFO 2011-07-02 15:43:33.137259 I Added logging to the console 2011-07-02 15:43:33.137284 I Added database logging to table logging 2011-07-02 15:43:33.162102 C Setting up SIGHUP handler

A full backtrace is attached. The SIGSEGV is in thread #4.

The issue seems to be that MythSystemIOHandler::BuildFDs calls readThread->wake with NULL readThread.

Changing to:

if (readThread) readThread-wake

(and likewise for writeThread) seems to work, but maybe only solve the symptoms. Perhaps there is a race in thread startup

Attachments (2) (3.2 KB) - added by Ian Dall <ian@…> 10 years ago.
system-unix.cpp.diff (500 bytes) - added by Ian Dall <ian@…> 10 years ago.
Possible patch.

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by Ian Dall <ian@…>

Attachment: added

Changed 10 years ago by Ian Dall <ian@…>

Attachment: system-unix.cpp.diff added

Possible patch.

comment:1 Changed 10 years ago by beirdo

Owner: set to beirdo
Status: newassigned

Please do the following:

  • revert all custom changes (store them somewhere of course)
  • do a make distclean
  • clear out ccache's cache
  • remove the installed MythTV headers, libraries and binaries
  • rebuild and try again

The only time I've seen funky behavior is when things are partially linked incorrectly to old versions of the code. Once you are on a known version (i.e. not -dirty from custom patches) and with a clean build, if this continues, then I'll look into it.

comment:2 Changed 10 years ago by beirdo

Status: assignedinfoneeded

comment:3 Changed 10 years ago by beirdo

Actually, gave it a quick look-see anyways, and I found what is likely the true issue. In the backend's main.cpp, we are calling setHttpProxy() before initializing gCoreContext (and gContext). setHttpProxy(), if configured to use a proxy, will attempt to ping the proxy, via myth_system, which is only usable with gCoreContext initialized.

I'll be committing a fix for this shortly. I don't think that the patches you have provided are bad, necessarily, but they are also not really fixing the problem.

comment:4 Changed 10 years ago by Github

Milestone: unknown0.25
Resolution: fixed
Status: infoneededclosed

Setup http proxy after the gCoreContext is initialized

Fixes #9893. Fixes #9894.

The setHttpProxy() uses myth_system to ping the proxy. However, myth_system requires that gCoreContext be valid for proper use. Therefore, move the proxy setup to after where we setup the context.

Branch: master Changeset: df8b987413106d47701a6c8ff04185b411d1a5b5

comment:5 Changed 10 years ago by Github

Check for thread existance before waking them

Refs #9893

This should never really happen if all else is correct, but no harm in being careful.

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

Branch: master Changeset: 4c7e1b792595204c41ee8b2def84abc4b97130b8

Note: See TracTickets for help on using tickets.