X-Spam-Check-By: sourceware.org Message-ID: <44E0998F.2050802@netbauds.net> Date: Mon, 14 Aug 2006 16:41:03 +0100 From: Darryl Miles User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.0.5) Gecko/20060727 SeaMonkey/1.0.3 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Debugging with/under CYGWIN query References: <004501c6bfad$fa9209c0$a501a8c0 AT CAM DOT ARTIMI DOT COM> In-Reply-To: <004501c6bfad$fa9209c0$a501a8c0@CAM.ARTIMI.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 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/