[RFC] libgfortran dll i/o redirection lossage caused by order-of-termination issue

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Jul 29 08:38:00 GMT 2009

On Jul 29 05:29, Dave Korn wrote:
> Dave Korn wrote:
> > Corinna Vinschen wrote:
> >> Hi Dave,
> >>
> >> On Jul 20 16:05, Dave Korn wrote:
> >>> Christopher Faylor wrote:
> >>>
> >>>>>  That's with the Cygwin DLL simply patched to schedule an atexit call to
> >>>>> dll_global_dtors directly after the exe's global dtors get run.
> >>>> So, you've removed the call from do_exit() then?  If so, please also remove the
> >>>> ES_GLOBAL_DTORS definition.
> >>>   Not yet.  Wanted to see what happens if I leave it in there as a last-chance
> >>> fallback.
> >> Any news?  A patch, maybe?
> >   I appear to have worked around my BLODA for the moment and have a testrun
> > progressing nicely now, with g++ completed and java nearly done.  Let's wait
> > and see how the libstdc++ tests go, sometime tomorrow.
>   So, the tests all finished successfully, in c++ and java, which I think is
> pretty good validation of the safety of this change.  I'm in two (possibly even
> three) minds about what to do now:
> 1- Ship it!  Commit it as it stands, dll_global_dtors is idempotent so it
> doesn't matter if it gets called again during ES_GLOBAL_DTORS.
> 2- Remove ES_GLOBAL_DTORS, because we believe that the outcome of the various
> standards is that dtors only get run if you exit() and not if you _exit() or
> abort().
> 3- ????
>   I guess we ought to look at #2, but that's going to require a bunch more
> testing.

That should be the right thing to do, given the semantics of _exit.
The fflush calls in the dtors of the fortran lib is a fine example.


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

More information about the Cygwin-developers mailing list