* George Hester (2004-03-13 01:24 +0100) > 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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >>> -----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.... >> >>
pdksh -- 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/
