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]

1.7.13: pthreads crash on W7/W2008 WoW64

Dear Cygwin experts,

we are using with parallel Posix Threads on Cygwin for quite some time already. After some updates early this year, potentially in the vicinity of Cygwin 1.7.10, some hard crashes started to occur.

This happens with current stable releases of Poly/ML 5.4.0 or 5.4.1 compiled on Cygwin 1.7.10 .. 1.7.13, either on Windows7 or Windows2008 which are both run in 64bit mode. We have tried a bit with old Windows XP in 32bit mode, without clear conclusion if this difference really matters, because there are other problems on our old XP installation.

The gdb backtrace of all threads is included, also cygcheck output.

David Matthews, who is the man behind Poly/ML says:

  I've tried everything I can think of and I really don't know what is
  going on.  I suspect that it is a combination of things that is
  confusing Cygwin. It looks as though it is segfaulting inside some code
  that Cygwin is using to produce a message but I can't tell what that
  message is or why it's producing it.  It could be that some Cygwin table
  has reached its limit.

Does the backtrace make any sense to any Cygwin pthreads experts out there?

The crash can be reproduced in the full application only, see current download via in the Cygwin section. After unpacking the bulky
Isabelle_18-Apr-2012_bundle_x86-cygwin.tar.gz one needs to run the whole thing like this:

  $ export CYGWIN="error_start=dumper -d %1 %2"
  $ cd Isabelle_18-Apr-2012
  $ ./bin/isabelle jedit src/HOL/MicroJava/MicroJava.thy

There will be a jEdit-based Prover IDE starting up and asking to load a bunch of files. Saying Yes here will make the application crunch on all these files and then produce a coredump of the background poly.exe process rather quickly -- at least on a machine with 2 or 4 cores. Sometimes it requires 2 or 3 attempts to reproduce the crash reliably.

Back at the command line, the remains of poly.exe can be inspected like this:

  $ gdb contrib/polyml-5.4.1/x86-cygwin/poly.exe poly.exe.core
  (gdb) thread all apply bt

The output of this is included as attachment "bt" here.

Is it Poly/ML doing bad things with Cygwin pthreads, or a genuine Cygwin problem introduced in recent pthreads renovations?

Any clues?


Attachment: bt
Description: Text document

Attachment: cygcheck.out
Description: Text document

Problem reports:
Unsubscribe info:

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