Message-ID: <44DEE891.40202@netbauds.net>
Date: 	Sun, 13 Aug 2006 09:53:37 +0100
From: Darryl Miles <darryl-mailinglists AT netbauds DOT net>
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: Debugging with/under CYGWIN query
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com


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.


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 allowing parallel environments on the same system ?

I have set the enviroment variable CYGWIN_TESTING=1 and also noted 
CYGWIN_MISMATCH_OK=1 to try and supress the problem.  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.  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 ?

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 ?   This would 
be a pain in the arse approach, since I am using the non-debugging 
environment to relink and build modified applications and cygwin.dll and 
if I introduce a serious bug into the DLL I'd need to reboot the system 
to recover (after setting up a forced copy of a clean and working 
cygwin.dll over the top early on during the bootup).


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


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.

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.


Thanks for reading if you got this far,

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/