crash on latest cygwin snapshot
Ryan Johnson
ryan.johnson@cs.utoronto.ca
Tue Jul 3 11:31:00 GMT 2012
On 03/07/2012 4:05 AM, marco atzeri wrote:
> On 7/2/2012 6:01 PM, Christopher Faylor wrote:
>> [redirecting to cygwin-developers]
>> On Mon, Jul 02, 2012 at 04:43:06PM +0200, marco atzeri wrote:
>>> On 6/27/2012 3:46 AM, Christopher Faylor wrote:
>>>>
>>>> Sorry, Marco. Nevermind. I duplicated this. No need to upload
>>>> anything.
>>>> I'm still working on it.
>>>
>>> it seems solved on 20120702 snapshots
>>
>> Thanks for confirming. I suspect that this snapshot really only
>> masks the
>> problem. The stack was getting corrupted by something but I was
>> having a
>> really hard time figuring out what was doing it.
>>
>> Compiling path.cc without optimization or passwd.cc without
>> -fomit-frame-pointer "fixed" the problem but clearly something is wrong.
>>
>> I tried building Cygwin with stack probes and that made the DLL
>> unrunnable. I tried instrumenting it with -finstrument-functions and
>> that made the problem go away.
>>
>> The problem is that something, somewhere along the line, replaces a
>> frame pointer in the stack with 0x10c (268) and the return address with
>> zero. So, eventually, when a function returns, %ebp is set to 0x10c and
>> the program jumps to address zero. That is one manifestation. In others
>> the 0x10c is still there but it is interpreted as a pointer to something
>> and dereferencing it causes a SEGV.
>>
>> 0x10c is 256 + 12 but I haven't been able to find that anywhere in the
>> source.
>>
>> Your test triggered a problem which has existed in Cygwin since last
>> November.
>> I noticed it in snapshots going back to 2012-11-14. But, when I
>> tried to
>> build a version of Cygwin from before that time, it still manifested the
>> problem. I did change to gcc 4.5.3 around that time so I'm thinking
>> that
>> either this version of gcc exposed a problem in Cygwin or Cygwin has
>> exposed
>> a problem in this version gcc. There was an odd problem in select()
>> where
>> it seemed like constructors weren't being properly run on a local
>> variable
>> when alloca was used in the same function.
>>
>> cgf
>>
>
> gcc-4.5 has some issue on windows platform (cygwin and mingw)
> for wrong optimization of function return value on C++ code.
I have also had issues with 4.5 (4.5.3 in particular) on Linux, where
destructors failed to run properly in optimized code. I now make a point
of upgrading (or self-compiling) to at least 4.6; I've actually had no
problems yet with 4.7 after using it for some months under both cygwin
and linux, though I haven't tried compiling a cygwin dll with it yet.
Ryan
More information about the Cygwin-developers
mailing list