This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem with Cygwin's fdopen and Windows handles
On 30/05/2011 3:34 AM, Juanjo wrote:
Christopher Faylor<cgf-use-the-mailinglist-please<at> cygwin.com> writes:
That is a *statically linked* test program whose dependent libraries
have intentional dll base collisions. Be glad you're using dlopen -- at
least there cygwin can usually bully Windows into doing what it wants.
Unfortunately, cygwin_attach_handle_to_fd doesn't really work. Cygwin
needs to know the type of handle it is attaching in order to set up
the correct type of file handler. Since it doesn't do that the handle
is of limited utility.
If this was true, the function should have then been removed from the
manual or marked as not working. But I believe this is not right, for
read() and file handlers work perfectly and the problem only
arises with fread() !!!
It is possible for the function to be more intelligent since other parts
of cygwin try to figure out the handle type by querying attributes of the
handle. So this is a http://cygwin.com/acronyms#SHTDI scenario.
Sorry, no time nor interest to do it myself. I am just reporting it here
because some users of our software experienced this problem. I have a
lot of SHTDI in my own project and in any case, as I said before, I believe
this is not the cause of the problem -- it lays in fread()/fdopen()
not in read().
I don't know what you mean by dlopen() causing fork not to work. That's
obviously not normally the case. If you are seeing something like this
then maybe your dlls are not properly based to avoid collisions. If
that is the case then you should change your link line to specify unique
load addresses for each dll.
I have seen messages in a sibling mailing list reporting that fork()
fails when a program injects libraries using various mechanisms
Unfortunately, the Windows loader has a bad habit of shuffling things
around the address space, and it does its damage before the cygwin dll
even loads. Cygwin does its best to hide all this from you, but Windows
Vista/7 actually makes it impossible to guarantee every fork will
succeed. It's all part of the cost of doing business with Windows.
In our case we just have one core library and other libraries that
are compiled on the fly and which are loaded with dlopen(). Loading
is fine and there are no collisions, the problem is that when fork() reloads
them they do not end up in the right positions and cygwin complains.
It is not our job to hardcode addresses for libraries to be loaded and
do what cygwin is not doing right, which is to determine the
right order of loading.
That said, rebasing and setting tsaware on your dlls helps a lot, and
there are patches in the works which should further improve the odds for
precisely your scenario.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple