Mail Archives: cygwin/2004/03/12/22:55:42
* 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" <dk AT artimi DOT com> wrote in message news:NUTMEGeUOLUei3tVLhU00000117 AT NUTMEG DOT CAM DOT ARTIMI DOT 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....
>>
>>
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/
- Raw text -