Debugging with/under CYGWIN query

[Darryl Miles]

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/