#36984: fetchmail - BUG in libdispatch client - ML 10.8.2 ------------------------+------------------- Reporter: srothe@… | Owner: pmq@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: fetchmail | ------------------------+------------------- Changes (by cal@…): * owner: macports-tickets@… => pmq@… * keywords: fetchmail => Comment: Please remember to Cc (or assign to) the maintainer, if any. I have done this for you. This message is printed by libdispatch (and is thus Apple-specific). Apparently fetchmail closes file descriptors that are used by libdispatch, which terminates the process using this message when this happens. I guess one would have to attach a debugger, see where the file descriptor is closed and see whether this actually is a "random" file descriptor and what can be done about it. The maintainer might also consider forwarding this to upstream fetchmail. -- Ticket URL: <https://trac.macports.org/ticket/36984#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36984: fetchmail - BUG in libdispatch client - ML 10.8.2 ------------------------+------------------- Reporter: srothe@… | Owner: pmq@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: fetchmail | ------------------------+------------------- Comment (by srothe@…): Do you have a debug script? If yes, I can do this for sure :) -- Ticket URL: <https://trac.macports.org/ticket/36984#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36984: fetchmail - BUG in libdispatch client - ML 10.8.2 ------------------------+------------------- Reporter: srothe@… | Owner: pmq@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: fetchmail | ------------------------+------------------- Comment (by srothe@…): OK. What do you use instead? Maybe there are good alternatives. -- Ticket URL: <https://trac.macports.org/ticket/36984#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36984: fetchmail - BUG in libdispatch client - ML 10.8.2 ------------------------+------------------- Reporter: srothe@… | Owner: pmq@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: fetchmail | ------------------------+------------------- Comment (by srothe@…): Comes libdispatch with OSX, or does mac port install it? -- Ticket URL: <https://trac.macports.org/ticket/36984#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36984: fetchmail - BUG in libdispatch client - ML 10.8.2 ------------------------+------------------- Reporter: srothe@… | Owner: pmq@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: fetchmail | ------------------------+------------------- Comment (by matthias.andree@…): Greetings, I am the current upstream maintainer of fetchmail, am unaware of MacOS X idiosyncrasies beyond the mere fact that it exists, and causes irritation with GCD idiosyncrasies and recent MacOS X regressions. Having said that, I also know nothing of otool or .dylibs or any of that stuff, and I do not care to learn any of that stuff, or obtain MacOS X. I have not got the faintest clue as to why a single-threaded application needs to deal with threading garbage. Very irritating. Documentation on this GCD requirement (keep file descriptor open, how to avoid GCD altogether, ...) is scarce and/or hard to find. I looked around Apple's developer docs, googled for quite a while without coming up with anything substantial, except that a few ported applications are also trapped by these GCD file descriptor idiosyncrasies, and apparently GCD has recently gotten in the fad of killing applications rather than just complaining. I find it strange that a UNIX-derived system is now breaking a UNIX application that has been around for far more of a decade -- and I am a bit alienated by the whole story: 1. apparently the whole issue only appears if NLS (through gettext/libintl) is in use. LC_ALL=C appears to avoid it, according to srothe@'s reports. 2. apparently the operating system forces underdocumented premature threading stuff on my single-threaded application 3. apparently the operating system also imposes open file descriptors on my single-threaded application. 4. Documentation on this GCD requirement (keep file descriptor open, how to avoid GCD altogether, ...) is scarce and/or hard to find. What I need is: 1. I need to be able to close all file descriptors in the daemonize() functionm before and/or after close()ing all open file descriptors. That is how Unix has worked for ages, this is required to let go of controlling terminals and thereabouts so we can thoroughly detach from the process that launched fetchmail in order to go in the background. 2. How do I avoid the system forcing additional constraints on my application that are in direct violation of relevant standards (details below)? 3. How do I determine when this descriptor needs to remain open, and which one it is? I am not ready to break my application for other Unices just because one OS acts up and imposes restrictions that violate the Single Unix Specification aka. IEEE Std 1003.1; If MacOS X believes I must not close its special file descriptor, it is required, that it - when I call close(SPECIAL_MACOS_FILE_DESC) - sets errno = EBADF and returns -1, rather than kill the application. Now, how can we resolve the mess without depriving end users of established fetchmail functionality (such as NLS or background/daemon mode) that they could successfully use in earlier MacOS X 10.n versions? -- Ticket URL: <https://trac.macports.org/ticket/36984#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS

#36984: fetchmail - BUG in libdispatch client - ML 10.8.2 ------------------------+------------------- Reporter: srothe@… | Owner: pmq@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: fetchmail | ------------------------+------------------- Comment (by srothe@…): Thanks Matthias for all the information. I have complile fetchmail without Native language Support and now there is no error message anymore. But this should only be considered as a workaround. ./configure --disable-nls -- Ticket URL: <https://trac.macports.org/ticket/36984#comment:12> MacPorts <http://www.macports.org/> Ports system for Mac OS