This is the mail archive of the cygwin-developers 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: crash on latest cygwin snapshot


On Jul  3 07:31, Ryan Johnson wrote:
> 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.

Dave, any chance we can get a gcc update to 4.6?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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