This is the mail archive of the
mailing list for the Cygwin project.
Re: Was that the sound of a snapshot going off?
- From: Steven O'Brien <steven dot obrien2 at ntlworld dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 2 Mar 2003 15:06:34 +0000
- Subject: Re: Was that the sound of a snapshot going off?
On Sun, 2 Mar 2003 01:38:09 -0500, Christopher Faylor wrote:
> Please try the latest cygwin snapshot and report any problems or
> successes here. The latest snapshot may be close to cygwin 1.3.21.
The change to dll_init.cc is wrong. If 1.3.21 is immiment, I strongly
recommend that you back out this change first. At least then we maintain
the status quo until the dlopen/fork issue is resolved.
The problem on 9x/Me is not that LoadlibraryEx returns NULL; it doesn't.
It loads the DLL, and returns a valid handle. If the DLL is properly
rebased then it even returns the address we want. The problem is that
this call does not invoke the cygwin entry point function, but the
corresponding FreeLibrary() call *does* invoke it. So we have a
situation where FreeLibrary risks dereferencing, even freeing,
uninitialised data. This is where I get failures in the gnome desktop,
and even in the simple test case I provided. I believe this issue has
always been there, its just that (i) there have been very few cygwin
apps using dlopen() and fork() to date, and (ii) for typical C programs
linked with gcc-2 the unbalanced call to the cygwin entry point does not
generate any segvs, and (iii) any problems here may have been mistaken
for the rebase problem that dll_list::load_after_fork() also suffers
I have done some more work on my original patch, and I will post that in
a new thread for discussion (since the original thread was HBAM
(hijacked by acronym mania) :( )
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html