This is the mail archive of the cygwin 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.8


On Nov 10 12:14, Corinna Vinschen wrote:
> On Nov  7 16:16, Tim Prince wrote:
> > 
> > On 11/7/2014 4:11 AM, Corinna Vinschen wrote:
> > >
> > > - GCC 4.9.2-1 DLLs accidentally call __cxa_atexit with the wrong DSO
> > >   handle value.  This Cygwin update allows this scenario throughout.
> > >   It now understands *any* DSO handle value, as long as it's a pointer
> > >   into the DSO's address space.
> > >   This fixes: https://cygwin.com/ml/cygwin/2014-11/msg00122.html
> > >
> > >   If you don't build applications or DLLs with Cygwin, you can safely
> > >   ignore this change.
> > >
> > >
> > > If you want to help testing this new release (which I seriously hope
> > > for), you can find it in your setup-x86.exe or setup-x86_64.exe as
> > > "test" release.
> > >
> > >
> > >
> > I take it from now on it should be OK to take the default for 
> > 
> > __cxa_atexit
> > 
> > when configuring to build gcc.  Thanks for explanation.
> > I'm repeating some tests with 1.7.33-0.8 and gcc/gfortran 4.9.2-1
> > 
> > no surprises, thanks (following segfault apparently unchanged, running with AV and Defender disabled, but failure not seen with gfortran 5.0):
> > 
> > Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
> > 
> > Backtrace for this error:
> > 1181925 [main] profile_omp 3684 fixup_mmaps_after_fork: ReadProcessMemory failed
> >  for MAP_PRIVATE address 0x6FE5FC60000, Win32 error 998
> 
> This probably means that there's an mmap'ed memory region which Cygwin
> has in its bookkeeping list, but which doesn't exist in the parent
> process anymore.  The problem here is that it's totally unclear how
> something like this could have happened.
> [...]
> Does that happen under Cygwin 1.7.32 as well?  Can you create a simple
> testcase, preferredly in plain C, which allows to reproduce this?

The only reason I can think of would be the fork synchronization between
parent and child allowing the parent to unmap memory before the child
copied it.

However, I fail to reproduce this with default application means:

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/mman.h>

int
main ()
{
  int status;
  void *addr;

  addr = mmap (NULL, 65536, PROT_READ | PROT_WRITE,
               MAP_ANONYMOUS | MAP_PRIVATE, -1, (size_t) 0);
  printf ("Address %p\n", addr);
  switch (fork ())
    {
    case 0:     // child
      printf ("child %p\n", addr);
      break;
    case -1:
      break;
    default:    // parent
      munmap (addr, 65536);
      wait (&status);
      break;
    }
  return 0;
}


Corinna

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

Attachment: pgp7i9zPpFMVG.pgp
Description: PGP signature


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