Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#7582 closed defect (fixed)

OSX 10.6 MythBackend fatal closing random unix handles

Reported by: Jeff Gibbons <mythtv@…> Owned by: Nigel
Priority: minor Milestone: unknown
Component: Ports - OSX Version: 0.22
Severity: high Keywords:
Cc: Ticket locked: no

Description

In all versions of MythBackend?, running on OSX 10.6 (Snow Leopard), MythBackend? crashes at startup with a message in Console about closing random unix handles.

In main.cpp, in the routine main, the following lines are the cause of the problem.

for (int i = 3; i < sysconf(_SC_OPEN_MAX) - 1; ++i)

close(i);

These are apparently benign in 10.5 (Leopard) but fatal in 10.6. They should be #ifdef'd away for 10.6 or OSX in general.

MythTV Version : 22791M MythTV Branch : branches/release-0-22-fixes Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.5.3 Options compiled in:

release darwin_da using_corevideo using_backend using_darwin using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_lirc using_mheg using_opengl_video using_qtwebkit using_appleremote using_bindings_perl using_bindings_python using_darwin_da using_opengl using_ffmpeg_threads using_live using_mheg

Attachments (1)

MythBackend_2009-11-20-203641_MythTV.crash (25.2 KB) - added by Graham.Dumpleton@… 14 years ago.
Example crash log showing actual error message.

Download all attachments as: .zip

Change History (8)

Changed 14 years ago by Graham.Dumpleton@…

Example crash log showing actual error message.

comment:1 Changed 14 years ago by Graham.Dumpleton@…

Have attached actual crash log to show this is a real issue. The error message is:

BUG IN CLIENT OF LIBDISPATCH: Do not close random Unix descriptors

This appears to be coming out of Grand Central Dispatch.

http://libdispatch.macosforge.org/trac/browser/trunk/src/queue.c?rev=2#L1893

http://libdispatch.macosforge.org/

The nature of the error seems to imply that direct or indirect linking of Grand Central Dispatch must cause some back ground task to run automatically and the close() loop in MythTV is closing some special file descriptor it is monitoring and causing fatal crash.

comment:2 Changed 14 years ago by Graham.Dumpleton@…

An anonymous poster over on ServerFault? gave this answer in relation to this issue:

"""The bug is in MythTV. The command-line argument parsing is apparently causing GCD to be started as a side-effect. The solution is simple. Move the "for ()" loop that closes all the descriptors to the very top of main()."""

comment:3 Changed 14 years ago by Nigel

Status: newassigned

Hi Graham. Sorry for the delay in working on this - not much time around Xmas. (Though, I don't use your OSE much any more, so I should have plenty of time :-)
Your suspicion is correct. Closing file handle 3 causes the crash. I'm still working out the best fix - anonymous' suggestion does not work for me - changing the loop to start from 4 on Mac OS X may be easiest?

comment:4 Changed 14 years ago by Jeff Gibbons <mythtv@…>

Pardon my ignorance but why are the handles being closed this way in the first place?

comment:5 Changed 14 years ago by Nigel

Resolution: fixed
Status: assignedclosed

(In [23099]) Work around Mac OS X 10.6 problem - file handle 3 is used, and there is no easy way to check if libdispatch is linked in, so just skip handle 3. Closes #7582. Thanks to Jeff for the original report and troubleshooting.

comment:6 in reply to:  5 Changed 14 years ago by Brian K Boonstra <(myth) (at) (boonstra.org)>

Replying to nigel:

(In [23099]) Work around Mac OS X 10.6 problem - file handle 3 is used, and there is no easy way to check if libdispatch is linked in, so just skip handle 3. Closes #7582.

Can we get this into 0.22-fixes also?

comment:7 Changed 14 years ago by Nigel

(In [23140]) Backport [23099] from trunk. Work around Mac OS X 10.6 problem - file handle 3 is used, and there is no easy way to check if libdispatch is linked in, so just skip handle 3. Refs #7582.

Note: See TracTickets for help on using tickets.