From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Debugging with/under CYGWIN query
Date: Mon, 14 Aug 2006 15:28:57 +0100
Message-ID: <004501c6bfad$fa9209c0$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <44DEE891.40202@netbauds.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 13 August 2006 09:54, Darryl Miles wrote:

> Q1) What is the difference between cygwin0.dll and cygwin1.dll ?  It
> seems all executables link against cygwin1.dll which for me is at
> F:\CYGWIN\BIN\CYGWIN1.DLL.

  'cygwin0.dll' is a temporary name under which the new dll is built so that
it doesn't get mistaken for the current cygwin dll and break the build process
- remember that the compiler, assembler, linker etc. are all cygwin programs
and hence require cygwin1.dll; confusion could arise after a new file called
'cygwin1.dll' gets built.
 
> 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!

> It might be better
> for me to understand what is doing on with relation to the dll magic
> mismatch.  I would guess this has something to do with a resident /
> shared part of cygwin that all running cygwin processes hook into.  

  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.

> Is
> it possible to keep them apart so I can freely build a new
> F:\CYGDEB\BIN\CYGWIN1.DLL and restart all the processes I am debugging ?

  That's exactly what the cygdeb environment already does.

> Do I have to reboot the system if I replace the main CYGWIN.DLL, or can
> I shutdown all processes using it, replace the file and startup
> applications?  Does the resident part get reinitialized ?   

  There is no resident part.  It is entirely adequate to shutdown all current
cygwin processes; once the last process exits, unloading the cygwin dll as it
does so, the dll releases its last handle to the shared section, which is then
deleted by the system.  The first cygwin process you start up after this
creates a new shared section.

> This would
> be a pain in the arse approach,

  But since it is not the case you don't have to worry about it.

> Q3) Does windows have some form of restriction with regards to DLL
> naming, i.e. that only one active DLL maybe called CYGWIN1.DLL ?  What
> scope is this restriction, system wide / per process / etc.. ?

  Nope, it has no such restriction, otherwise how would it even be possible
for two different versions to be running at once and clash?  Anytime a process
loads a dll (which is done by name), windows uses the standard dll search
rules (see MSDN docs for LoadLibrary), and the first correctly-named dll found
gets loaded.

  For this reason, it is a very bad idea to include '.' (the current dir) in
$PATH.  It can mean that which dll gets loaded by an executable depends which
dir you are in when you invoke the exe.

> 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".

> 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.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
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/