context team mailing list archive

[taco <taco@xxxxxxxxxxxxx>]

Peter Münster wrote:
> On Wed, Aug 25 2010, Peter Münster wrote:
> > On Tue, Aug 24 2010, Taco Hoekwater wrote:
> > > This is very different indeed. I don't see why a crash that
> > > happened after application close and was fixed there
> > > now suddenly happens way before the application close,
> > > unless it is related to C++ memory freeing. And even then,
> > > I have no idea what goes wrong and why. Anyway, can you try the
> > > released 0.62.0 ?
> > Yes. The results are the same:
>
> Let's drop support for cygwin. Ok?

Two things that might help debug the problem:

* what is the gcc version is that version of cygwin?
* Is there any chance of trying with a different compiler version?

Also, are you running the resulting luatex in a command box,
or in a real shell?

What I think _may_ be the problem is that the c++ garbage
collector is run too late or too early, resulting in reads
or writes to file descriptors that are already closed. But
I have no idea why and how that could happen unless it is
either a compiler bug or you are running into a conflict
between (y)our usage patterns and the cygwin runtime dll.

You could even try to compile with -no-cygwin to get rid of
the runtime dll dependency (I don't remember the exact flags
needed for that, sorry). But then, if you wanted to do that,
you probably would have used the mingw compiler from the start ...

Anyway, this sort of trouble is exactly why I abandonded
cygwin in the mid-nineties: it seems that whatever you do
at the system level (either in windows style or in unix style),
cygwin is always doing something unexpected behind your back.
Maybe I am wrong and I simply do not understand the system
enough, but that was definitely the impression I got.

Best wishes,
Taco