This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Difference between just having cygwin1.dll and running under cygw in


This coming from a whipper-snapper I don't expect a response.  But you sure have a famous name.
Now if I could just get the Korn Shell in cygwin or integrate UWin into cygwin that would be really neat.


George Hester
__________________________________
"Dave Korn" <dk@artimi.com> wrote in message NUTMEGeUOLUei3tVLhU00000117@NUTMEG.CAM.ARTIMI.COM">news:NUTMEGeUOLUei3tVLhU00000117@NUTMEG.CAM.ARTIMI.COM...
> > -----Original Message-----
> > From: cygwin-owner On Behalf Of Larry Hall
> > Sent: 11 March 2004 20:28
> 
> > At 03:17 PM 3/11/2004, you wrote:
> > >What's the difference between running an executable in the cygwin
> > >environment and running it in a Win2K DOS shell on the same 
> > > machine(which obviously has cygwin1.dll)?
> > >
> > >As I mentioned in another thread of mine, I have a 
> > program(port of objcopy)
> > >that I've compiled that runs just fine under cygwin, but 
> > crashes with a
> > >stack violation whenever I run it under a DOS window on the 
> > same machine! 
> 
> > There's really no significant difference, assuming your DOS 
> > shell can see cygwin1.dll and it's the same one you get when 
> > you run under your Cygwin shell (having more than 1 
> > cygwin1.dll on your system is a *very* bad idea anyway).  
> > Certainly, there can be all kinds of differences in the 
> > environment, literally, but it should be pretty obvious if 
> > you're dependent on some environment variable or something 
> > that's not set for Windows.  Maybe you just need to debug it 
> > and see where the problem is and why you get it.  
> > Like I said, objcopy that comes with Cygwin's binutils works 
> > just fine for me outside of a Cygwin shell so it's not a 
> > problem with the tool in general.
> > 
> > Larry
> 
>   I think you may slightly underestimate the amount of difference it makes.
> For example, it's going to make a big difference to the runtime memory
> layout.  If you run under bash you're going to have a whole load of posix
> environment vars at the very top of your runtime stack.  I could easily
> imagine a stray pointer or stack smashing bug that harmlessly scribbles on
> the environment vars under bash but writes over what is active program stack
> at the same address / offset-from-sp when run from dos.  However, I agree
> with your conclusion: any *correct* program should run equally well under
> either, and I think in this case it's not that running under DOS breaks the
> program, but that it just happens to get lucky and work by chance under
> bash.
> 
> 
> > >My makefile does the same thing as the objcopy
> > >makefile, but the result of my compilation is something that 
> > >only works under cygwin.
> 
>   That's quite an assertion to make!  How did you generate your makefile,
> and how can you be really sure it's doing exactly the same?
> Autoconf-produced makefiles are fairly hairy; if you've hacked up the
> autoconf one, you're probably in the clear, but if you've tried reading the
> autoconf one and duplicating it's effects from scratch, you may easily have
> introduced a discrepancy.  However, that's a side issue; it's unlikely to be
> a compiler option that's causing your problem.
> 
>   The fact that it's hanging in malloc suggests that it's very likely that
> the root cause of the crash is trashing the heap, most likely by writing
> past the end of a malloc'd block of memory.  Beyond that it's difficult to
> speculate, particularly since we don't really have any idea what sort of
> changes you've made to the code.  You should investigate any of the changes
> you've made that refer to arrays or malloc'd memory, or perhaps use some
> kind of error-checking malloc wrappers - e.g. efence,
> http://perens.com/FreeSoftware/ (ftp site currently down, it seems) or
> http://freshmeat.net/projects/efence/?branch_id=2277&release_id=7043 .
> 
>   Of course it's always possible that it's not the code you've changed that
> is overwriting memory but something elsewhere by means of some indirect and
> unexpected interaction.  Those are the worst kinds of bugs to look for, but
> malloc-wrappers might still help.
> 
>   How big are the changes you've made to the source?  Minor overhaul or
> radical surgery?
> 
> 
> 
>     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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]