Mail Archives: cygwin/2006/08/14/11:41:31
Thanks very much for your reply, you have filled in many of the jigsaw
pieces from my patchy fishing questions and here is more detail (if you
really wanted to know!).
Dave Korn wrote:
> On 13 August 2006 09:54, Darryl Miles wrote:
>
>> Q2) Is it possible to setup C:\CYGDEB\ environment with debugging copies
>> of DLLs and EXEs, to help debugging, but keep the runtime separated from
>> the main C:\CYGWIN
>
> What do you mean by 'the runtime'?
>
>> allowing parallel environments on the same system ?
>
> The cygdeb debugging environment is exactly that already, or at least it is
> supposed to be.
>
>> I have set the enviroment variable CYGWIN_TESTING=1 and also noted
>> CYGWIN_MISMATCH_OK=1 to try and supress the problem.
>
> What problem? You haven't described any problem yet!
Okay, it is actually sshd and rsync I am debugging. I have built both
both with extra debugging printf() output and have proved the problem.
So far so good without the need to use a modified CYGWIN1.DLL.
Then I got the to point I want to modify CYGWIN1.DLL so...
I have setup F:\CYGDEB\ and in there my debugging copy of RSYNC.EXE and
SSHD.EXE. I am starting SSHD with the correct options and config to
keep is completely isolated from the system one, its running on a
non-standard port.
I am using the standard ssh to connect into the box to compile, restart
and debug.
> Where did you get the idea that it was resident? It is indeed shared, but
> it doesn't reside any time after the last cygwin process (that has a handle
> open to it) exits. For more information, take a look at shared_info.h and
> shared.cc in the cygwin sources.
Resident comes from old DOS heratige, meaning a persistent part of
something. In this case I'm using it to describe the fact that if I
have one long running CYGWIN program (sshd/bash) and I execute multiple
short running ones (ls/date), they all get to interact with the same
persistent part to share/exchange information.
You have filled in the blanks for me with regards to the lifetime of
that persistant part. After the last user exits it dies. Good stuff.
Okay so the scope of the shared context is per system or per DLL
instance ? So if I use C:\CYGDEB\BIN\CYGWIN1.DLL it will get an
isolated copy of the shared part that does not interact with the one
maintained by C:\CYGWIN\BIN\CYGWIN1.DLL ?
And setting CYGWIN_TESTING=1 enables this isolation mechanism ?
And when CYGWIN_TESTING=1 then CYGWIN mounts POSIX filesystem "/" as
F:\CYGDEB because "SYSTEMDRIVE=F:" for me (Non-standard I know) ?
My line of questioning is to understand more about what CYGWIN_TESTING
actually does.
>> Q4) If I reboot the system and run my program (I want under debugging)
>> using a debugging copy of the CYGWIN1.DLL the environment, I get the
>> error message:
>>
>> 10 [main] ? (2656) F:\CYGWIN\bin\bash.exe: *** fatal error - proc magic
>> mismatch detected - 0x704D1F7E/0xC87757A7.
>> This problem is probably due to using incompatible versions of the
>> cygwin DLL.
>> Search for cygwin1.dll using the Windows Start->Find/Search facility
>> and delete all but the most recent version. The most recent version
>> *should*
>> reside in x:\cygwin\bin, where 'x' is the drive on which you have
>> installed the cygwin distribution. Rebooting is also suggested if you
>> are unable to find another cygwin DLL.
>
> This almost certainly indicates that the root cause of your problem is that
> you have installed a cygwin-based service, such as sshd or crond, which is
> automatically started at window startup, and so is already running (with the
> old, non-debugging version of the dll loaded) by the time you've logged in.
> Try "cygrunsrv -L --verbose".
Well it is 'sshd' I am debugging. But another instance I am hoping is
running cleanly 100% inside the F:\CYGDEB tree with no access to
anything from F:\CYGWIN (so it cant screw anything up :).
So now I don't understand. You indicate that F:\CYGDEB sets up a CYGWIN
enviroment that is seperate from C:\CYGWIN but now that that I am
getting magic errors because I almost certainly have sshd running.
And yes I do. I have 2 SSHDs running, one on port 22 using
F:\CYGWIN\BIN\CYGWIN1.DLL and another on port 10023 using
F:\CYGDEB\BIN\CYGWIN1.DLL.
This is what I want. But when my debugging version of SSH spawns a new
job, it appears to access F:\CYGWIN\BIN\BASH.EXE and reset the
enviroment variables (removing CYGWIN_TESTING). More on that below...
>> once that error message is seen/displayed by an application which is a
>> child of the interactive bash shell the environment (as held at 'extern
>> char **environ') is trashed/reduced to a minimal set of entries:
>>
>> PATH=.......PATH is okay.....
>> SYSTEMDRIVE=F:
>> SYSTEMROOT=F:\WINNT
>> WINDIR=F:\WINNT
>> TERM=cygwin
>> HOME=/home/Administrator
>>
>> Even when I run a simple "A.EXE" program to dump the environ out to
>> stdout. All I see is the above entries, but the bash itself (using
>> 'set' command) which started a.exe has a full set of enviroment
>> variables I expected to see. Only that bash session is effected. If I
>> close it and reopen my enviroment variables come back. Somehow a child
>> process is able to trash the parents environment variables.
>
> The description in this paragraph is fairly confused. You haven't explained
> in enough detail exactly how you're determining the set of environment
> variables in each case. I suspect that you need to revise the meaning of the
> 'export' keyword in bash, and bear in mind that A.EXE will be a child process
> of the bash shell, but 'set' or 'env' are builtin keywords executed directly
> by the main bash process itself. If you still think there's a problem, please
> describe the exact procedure you use to cause it, including the exact commands
> that you issue, messages you see, and exactly what A.EXE does in order to dump
> the environment.
I login with ssh to the box. I from here I have a regular bash shell
environment.
From there I start up my debugging copy of sshd. I use a script to
start it and get the options I want setup correct:
#!/bin/sh
PATH="/cygdrive/f/cygdeb/xbin:/cygdrive/f/cygdeb/bin"
export PATH
CYGWIN_MISMATCH_OK=1
export CYGWIN_MISMATCH_OK
CYGWIN_TESTING=1
export CYGWIN_TESTING
exec /cygdrive/f/cygdeb/usr/sbin/sshd.exe -p 23 -f
/cygdrive/f/cygdeb/etc/sshd_config -d -d -d -D -e
This runs fine and listens on port 23.
I then connect in from Linux openssh client to port 23 and issue the
command -e 'rsync ...' i then see the stdout/stderr output to do with
bad magic emitted through the ssh connection. My 'sshd -p 23' process
terminates (I presume because I am in debugging mode it just accepts one
connection and dies, good stuff).
I have checked over the ssh options and set "UsePrivilegeSeparation no"
just to help reduce the complexity.
Now the funny enviroment thing happens at this point. Interactive
control is returned to the bash shell, that is running in the standard
CYGWIN enviroment.
If I issue a 'set' command I get a list of all the environment variables
I expect to see. So internally inside bash it believes the environment
has ~30 variables setup.
But if I execute any program from now onwards from this bash shell the
enviroment variables have been trashed.
The source code for my a.exe is:
#include <stdio.h>
extern char **environ;
int
main(int argc, char *argv[])
{
char **e;
for(e = environ; *e != NULL; e++) {
fprintf(stdout, "%s\n", *e);
}
return 0;
}
If I run the program BEFORE I run 'sshd -p 23 ...' I get all the
expected enviroment vars, if I run it after I get the cutdown set.
So this is perplexing, as I wasn't expecting a child process to be able
to modify the environment variables of a parent process, under unix they
are a unique private copy given to the process. This is often passed
into the process address space at the end of the application stack, I'm
not sure how WIN32/CYGWIN maintains per-process enviroment variables.
Now I know SSHD itself modifies and sanitizes the environment vars
before invoking the command/shell, and I modified the code to make sure
and force CYGWIN_TESTING=1 is setup.
There is also an issue with sshd I need to check with regards to
setproctitle() to make sure its not writing back to the environ.
But its still trying to execute F:\CYGWIN\BIN\BASH.EXE and not
F:\CYGDEB\BIN\BASH.EXE.
I have a few avenues to rules out yet, with regards to making sure the
PATH variable isn't being reset to /bin inside my 'sshd -p 23 ...' but
I'm expecting "/bin" to resolve to F:\CYGDEB\BIN. From memory the PATH
variable is not modified by sshd from the one in which SSHD itself is
running with.
Thanks for reading if you got this far again,
Darryl
--
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/
- Raw text -