This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process
On Sun, Jan 29, 2006 at 11:58:42PM +0100, Louis Lecaroz wrote:
>somebody wrote:
>>What did you actually *do* to get from one step to the next in the
>>above? Where does your MSVC-linked DLL come into it? What loads that
>>DLL? What is your system like (the information requested in
>>http://cygwin.com/problems.html)?
That's two requests that you follow the guidelines at this page now and
you still haven't completely complied.
>First, my DLL is written & built in C by using MS DevStudio 2003. so
>no by using gcc & CygWin libs.
>
>Next, I declared it through the LD_PRELOAD, which force cygwin
>processes (trougth the crt cygwin library) to load it in their memory
>space. That's really simple to reproduce, only create an empty dll
>with DllMain & a MessageBox showing environment variables in the Attach
>process step of Dll Main, & you will see that :
>
>-The first cygwin process (bash for example) you request load it
>correctly & environment variable are all in the process
>
>-Next from bash, start VI for example,
>
>-A new instance (the forky instance) of bash will be started also with
>the LD_PRELOAD dll loaded correctly & also with all environment
>variables (If I remember, the cygwin fork() method uses the
>CreateProcess with longjmg, ect... & pipes for synchronizing
>initialization throught the parent & the forky).
>
>-vim.exe is started through the forky instance of bash (If I am right),
>the LD_PRELOAD dll is still (& always) loaded correctly but only 3 or 4
>environment variables have been propaged (by using GetEnvironmentString
>win32 APIs as my DLL due to many constraints is compiled by using
>devenv & not cygwin/gcc as i said above).
>
>The problem has been reproducible on my computers, all using a clean
>install of CygWin 1.5.19-4 with & without last snapshot, & the behavior
>is exctly reprodicble on Win2000 Server & Win2003 Enterprise server.
>Downgrading to 1.5.18-x resolve this issue :(
Since you have now (finally) informed us that you are using a non-cygwin
binaries, then please read Brian Ford's response to your question. Cygwin
now uses a more efficient mechanism for communicating the environment to
cygwin processes. It does not fill out the windows environment if it
knows that the process being started is using the cygwin DLL.
http://cygwin.com/ml/cygwin/2006-01/msg01353.html
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/