This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process

Hi Christophe,
First, let met apologize if there were many misunderstanding between you & me.
I was really calm when I wrote my previous mail, there was no agression but maybe some missing smiley.

Next for your email address, I understand your concerned, I just copied & past it from the changelog & the source code where it was written & did not take care of this as these code & so your email address are publicly accessible from cvs :( but I understand that robots could use it for spamming.

Next, I troubleshoot my issue a little bit, maybe my first mail was too quick on the investigation.
I now found the origin of my issue, sure, you're right the LD_PRELOAD is propaged correctly (as you corrrected it als form in the snapshot referenced below).

But... As I use manu environment variable, for example, one called FILELOG_PORT (which is used by the injected code/dll for communciation with external process), It appears, I don't know why, that this variable is not replicated in all sub/child process ! :(

Do you have an idea on this ?
For your information, I retrieve this environment variable from the getenv() microsoft C APi as my injected DLL is written with the Microsoft C runtime & not cygwin one. But I suppose that you fix environment variable for child process... 

Looking a little bit better inside & drilling in the issue, here is what I found :
from cmd.exe
->Start bash
-->All environment variables from cmd.exe were propaged in bash environment+.profiles one.
-->Start "vi sample.txt" from this bash instance
---->A new instance of bash is loaded with also all environment variables.
----->A VIM.exe instance is loaded but only with PATH, SYSTEMDRIVE, SYSTEMROOT, WINDIR !!!!!!!!!

I tried also to verify with the win32 system routine called GetEnvironmentStrings(), but it is exactly the same data retrieved with getenv() !
So it (I feel) seems that this new version of cygwin did not propaged all environment variable to all child process !
Don't know why :( but I Just tested it on the 1.5.18 patched with the snapshot mentioned below, just reinstall the 1.5.19-4 over it (after having removed the previous), & my conclusion (but I am not the Cygwin Expert ;) ), is that LD_PRELOAD since 1.5.19-4 & previuous does have the same behavior as environment variable appears to be correctly propagated in 1.5.18-x & not in 1.5.19-4.

So, let me also apologize for my first bad investigation, but anyway, it appears that there is an issue in this build (environment variables not propagated).
I reported it as an LD_PRELOAD issue, as I uses this TCP port defined in the environment variable to communicate & send traces. & so because, the environment port called FILELOG_PORT was not propagated to child process, I was not able to see my dll traces considering this issue as an LD_PRELOAD issue instead of an environment variable propagation.

I am sure that you will be able to help me on this ;)
Thx a lot in advance,

-----Original Message-----
From: Christopher Faylor
Sent: jeudi 26 janvier 2006 19:37
Subject: Re: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library
in child process

On Thu, Jan 26, 2006 at 11:37:18AM +0100, Louis Lecaroz wrote:
>Hi all CygWin champions developers ;)
>Since this version, the LD_PRELOAD tag is no more replicated to
>subprocess (Win32 version of cygwin).  That means, if I set the
>LD_PRELOAD variable, only the parent process calls the LoadLibrary &
>load the DLL defined in LD_PRELOAD.
>In this case, when starting bash, the LD_PRELOAD command is executed.
>but when starting a cp.exe, cat.exe or another cygwin command from the
>bash shell, the LD_PRELOAD is no more executed !


>If I performed :
>SET LD_PRELOAD=/cygdrive/d/mydll.dll
>c:\bash (mydll.dll loaded correctly)
>$cp toto.txt titi.txt (no mydll.dll loaded !)
>If I performed :
>SET LD_PRELOAD=/cygdrive/d/mydll.dll
>c:\bash (mydll.dll loaded correctly)
>c:\cp toto.txt titi.txt (mydll.dll loaded)
>So, it works now in this last build of cygwin as it was working
>previously the snapshot #20050811
>To correct this, a snapshot has been provided, snapshot #20050811, See
>ChangeLog in winsup\cygwinChangeLog :
>2005-08-11  Christopher Faylor  <cgf@DONTQUOTERAWEMAIL>

Please don't send my email address to public mailing lists.

> * Remove ld_preload declaration.
> * winsup.h: Move ld_preload declaration here.
> * (fork_child): Call ld_preload() before returning.
>So this issue was corrected by version 1.158 of ffork.ccd I
>took a quick look into the, & I saw that the
>fixup_hooks_after_fork () & _my_tls.fixup_after_fork () are now called
>after ld_preload instead of before as deliverd in snapshot #20050811.
>I don't know exactly if this is the reason of my issue.

I'm sorry but I don't really understand this report.  I implemented
LD_PRELOAD because I have software which needs it.  I would notice if it
wasn't working in subprocesses and I've just confirmed that it does, in
fact get propagated and loaded.  So whatever your problem is, it isn't
as simple as what you are describing.

I appreciate the fact that you're making the effort to look at the
source code but, in general, just quoting something like this with no
understanding of what the change does is not really going to be very

If you are building this from source then maybe you could put some
"small_printf ("...");" entries in the code to illustrate what is
going on since, as I said, it WFM.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]