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 Tue, Jul 03, 2012 at 03:28:21PM +0200, Corinna Vinschen wrote:
>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?

Or, barring that, an experimental gcc 4.6 cross-compiler for Linux.

I will roll one myself if Yaakov doesn't already have one lurking in
the wings.

cgf


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