[ANNOUNCEMENT] Update: mintty 2.1.2

[Thomas Wolff]

mintty 2.1.2 is an update in response to a number of crash reports under
unclear circumstances;
mintty only detaches from the caller's terminal if the option -D is given

32 bit package uploaded
64 bit package to follow

Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

> mintty 2.1.2 is an update in response to a number of crash reports under
> unclear circumstances;
> mintty only detaches from the caller's terminal if the option -D is given

Thank you, Thomas!

I extracted mintty.exe (and named it mintty-v212.exe) from mintty-2.1.2-0.tar.xz, and
placed it in <Windows Cygwin root>/bin (i.e. I did not install through setup.exe)

From winmain.c (v212),

  // if started from console, try to detach from caller's terminal (~daemonize)
  // in order to not suppress signals
  // (indicated by isatty if linked with -mwindows)
  if (daemonize && !isatty(0)) { // boolean daemonize is set to true if -D is specified
    if (fork() > 0) exit(0);
    setsid();
  }

I gather, that v212 has the "old behaviour" if -D is not specified on the command line.

Test v212:

 - started from the explorer: works
 - using a dos console (in which mintty-v212 is started): works
 - using a dos console (in which bash is started), followed by invocation of mintty-v212: works
 - using a dos console (in which cmd is started), followed by invocation of mintty-v212: works

Of course, SIGINT is ignored in the third case (old behaviour).

Invocation of 'mintty-v212 -D' in the third case, makes "mintty" crash again ...
(hint: source code of setsid.c -- util-linux package)

(... and I ask myself whether or not the condition '!isatty' is the "correct condition" to
 go "daemon")

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Thomas Wolff]

On 24.07.2015 09:50, Houder wrote:
>> mintty 2.1.2 is an update in response to a number of crash reports under
>> unclear circumstances;
To resolve this discomforting issue which I still cannot reproduce,
could please those who experience a crash report some details about
their calling environment?
Could the issue be related to the occasional fork() resource problems in
cygwin?
How much free memory do you have?
Insights can also be collected in
https://github.com/mintty/mintty/issues/464

>> mintty only detaches from the caller's terminal if the option -D is given
> Thank you, Thomas!
> ...
My quick fix seems to work for now at least, sigh!

> I extracted mintty.exe (and named it mintty-v212.exe) from mintty-2.1.2-0.tar.xz, and
> placed it in <Windows Cygwin root>/bin (i.e. I did not install through setup.exe)
>
>  From winmain.c (v212),
>
>    // if started from console, try to detach from caller's terminal (~daemonize)
>    // in order to not suppress signals
>    // (indicated by isatty if linked with -mwindows)
>    if (daemonize && !isatty(0)) { // boolean daemonize is set to true if -D is specified
>      if (fork() > 0) exit(0);
>      setsid();
>    }
>
> I gather, that v212 has the "old behaviour" if -D is not specified on the command line.
>
> Test v212:
>
>   - started from the explorer: works
>   - using a dos console (in which mintty-v212 is started): works
>   - using a dos console (in which bash is started), followed by invocation of mintty-v212: works
>   - using a dos console (in which cmd is started), followed by invocation of mintty-v212: works
>
> Of course, SIGINT is ignored in the third case (old behaviour).
>
> Invocation of 'mintty-v212 -D' in the third case, makes "mintty" crash again ...
> (hint: source code of setsid.c -- util-linux package)

Maybe setsid() should not be called if fork() fails...
Could you try this please:
   if (daemonize && !isatty(0)) {
     int pid = fork();
     if (pid > 0) exit(0);    // exit parent process
     if (pid == 0) setsid();  // detach child process
     if (pid < 0) {
       error("could not detach from caller");
       exit(9);
     }
   }

> (... and I ask myself whether or not the condition '!isatty' is the "correct condition" to
>   go "daemon")
I wanted to check ttyname() for "/cons" but surprisingly ttyname() was
null when started from cygwin console;
– could this be related to the original issue of signals not being
delivered? (Corinna?)

Thanks for everybody's debugging support.
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

Hi Thomas,

>>> mintty 2.1.2 is an update in response to a number of crash reports under
>>> unclear circumstances;
> To resolve this discomforting issue which I still cannot reproduce,
> could please those who experience a crash report some details about
> their calling environment?
> Could the issue be related to the occasional fork() resource problems in
> cygwin?

... euh, I do not believe so (in my case) ... I installed v211 using setup, which as
you know, does a full "rebase" ...

Also using 'setsid mintty' (in case of v113, v203) does not fail ...

> How much free memory do you have?

 - my computer has lots of free memory (using less than 2 Gb of 8 Gb)
 - my environment: using Cygwin (only the traditional tools)
 - plus: Explorer (and most of the time: Process Explorer from SysInternals)

I am really surprised, that you (and others?) do not experience crashes (v211, v212
if -D is specfied). Failure occurs consistent on my side.

> Maybe setsid() should not be called if fork() fails...
> Could you try this please:
>    if (daemonize && !isatty(0)) {
>      int pid = fork();
>      if (pid > 0) exit(0);    // exit parent process
>      if (pid == 0) setsid();  // detach child process
>      if (pid < 0) {
>        error("could not detach from caller");
>        exit(9);
>      }
>    }

Hint: source code of setsid.c -- util-linux package)

>> (... and I ask myself whether or not the condition '!isatty' is the "correct condition" to
>>   go "daemon")
> I wanted to check ttyname() for "/cons" but surprisingly ttyname() was
> null when started from cygwin console;

... I expect ttyname() to return NULL, as mintty is a GUI application ... (and it did, using
a "small GUI test program"; however it returned /dev/pty0 when executing it from a dos console
in which mintty had been started). Yes, I am confused).

As I wrote 'and I asked myself', I was wondering about something like: 'getpid() != 1'

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Corinna Vinschen-2]

On Jul 24 13:40, Thomas Wolff wrote:
> I wanted to check ttyname() for "/cons" but surprisingly ttyname() was null
> when started from cygwin console;

Isn't mintty a "subsystem=windows" application which is supposed to
attach or create a console at some later point?  Maybe that's the
reason.  Off the top of my head I really don't know.  You provided
patches to Cygwin's console code already, so you're partially familiar
with the codebase.  Did you try to debug it?


Corinna

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

[Houder]

> As I wrote 'and I asked myself', I was wondering about something like: 'getpid() != 1'

s/getpid/getppid/

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Corinna Vinschen-2]

On Jul 24 15:18, Houder wrote:

> Hi Thomas,
>
> >>> mintty 2.1.2 is an update in response to a number of crash reports under
> >>> unclear circumstances;
> > To resolve this discomforting issue which I still cannot reproduce,
> > could please those who experience a crash report some details about
> > their calling environment?
> > Could the issue be related to the occasional fork() resource problems in
> > cygwin?
>
> ... euh, I do not believe so (in my case) ... I installed v211 using setup, which as
> you know, does a full "rebase" ...
>
> Also using 'setsid mintty' (in case of v113, v203) does not fail ...
>
> > How much free memory do you have?
>
>  - my computer has lots of free memory (using less than 2 Gb of 8 Gb)
>  - my environment: using Cygwin (only the traditional tools)
>  - plus: Explorer (and most of the time: Process Explorer from SysInternals)
>
> I am really surprised, that you (and others?) do not experience crashes (v211, v212
> if -D is specfied). Failure occurs consistent on my side.
>
> > Maybe setsid() should not be called if fork() fails...
> > Could you try this please:
> >    if (daemonize && !isatty(0)) {
> >      int pid = fork();
> >      if (pid > 0) exit(0);    // exit parent process
> >      if (pid == 0) setsid();  // detach child process
> >      if (pid < 0) {
> >        error("could not detach from caller");
> >        exit(9);
> >      }
> >    }
>
> Hint: source code of setsid.c -- util-linux package)
>
> >> (... and I ask myself whether or not the condition '!isatty' is the "correct condition" to
> >>   go "daemon")
> > I wanted to check ttyname() for "/cons" but surprisingly ttyname() was
> > null when started from cygwin console;
>
> ... I expect ttyname() to return NULL, as mintty is a GUI application ... (and it did, using
> a "small GUI test program"; however it returned /dev/pty0 when executing it from a dos console
> in which mintty had been started). Yes, I am confused).
>
> As I wrote 'and I asked myself', I was wondering about something like: 'getpid() != 1'

Guys, the Cygwin DLL is as much open source as the other stuff we're
talking about here.  It's a user space DLL, not a kernel driver or
rocket science.  Give debugging a chance.  Ideally build your own Cygwin
DLL with CFLAGS=-g to avoid optimization.  Please don't let me do this
alone and just give up if I don't.


Corinna

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

[Thomas Wolff]

Am 24.07.2015 um 15:18 schrieb Houder:

> Hi Thomas,
>> Maybe setsid() should not be called if fork() fails...
>> Could you try this please:
>>     if (daemonize && !isatty(0)) {
>>       int pid = fork();
>>       if (pid > 0) exit(0);    // exit parent process
>>       if (pid == 0) setsid();  // detach child process
>>       if (pid < 0) {
>>         error("could not detach from caller");
>>         exit(9);
>>       }
>>     }
> Hint: source code of setsid.c -- util-linux package)

... or maybe the parent thread should not exit immediately but wait:
   if (daemonize && !isatty(0)) {
#include <sys/wait.h>
     int status;
     int pid = fork();
     if (pid > 0) {
       waitpid(pid, &status, 0);
       exit(0);
     }
     setsid();
   }

Can you please try both alternatives?
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

>> Hi Thomas,
>>> Maybe setsid() should not be called if fork() fails...
>>> Could you try this please:
>>>     if (daemonize && !isatty(0)) {
>>>       int pid = fork();
>>>       if (pid > 0) exit(0);    // exit parent process
>>>       if (pid == 0) setsid();  // detach child process
>>>       if (pid < 0) {
>>>         error("could not detach from caller");
>>>         exit(9);
>>>       }
>>>     }
>> Hint: source code of setsid.c -- util-linux package)
> ... or maybe the parent thread should not exit immediately but wait:
>    if (daemonize && !isatty(0)) {
> #include <sys/wait.h>
>      int status;
>      int pid = fork();
>      if (pid > 0) {
>        waitpid(pid, &status, 0);
>        exit(0);
>      }
>      setsid();
>    }
>
> Can you please try both alternatives?

Hi Thomas,

I found the bug (more or less): it is me (AND you). More will follow soon.

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

> I found the bug (more or less): it is me (AND you). More will follow soon.

Hi Thomas,

As I reported earlier, I found the culprit ...

No, I did not build my own Cygwin.dll, as advised by Corinna, because to her Cygwin
is NOT "rocket science" (after all these years), however to me, it is still

    an "intergalactic science". :-)

But first things, first ...

Please, make a mental picture of the check boxes at your place at 'control panel >
performance information and tools > adjust visual effects'.

I'll bet, all check boxes for "eye candy" has been checked at your place; NONE of
them are checked at my place ...
(I am an old fashioned guy, who wants his 8 cores to do useful things)

Now, I said, that I found the culprit, but I what I really meant, was that I found
the function, that made mintty crash AT MY SIDE.

You still have to do all the hard work ... Sorry, I cannot help you with that.

winmain.c:

  // Initialise various other stuff.
  win_init_drop_target();
  win_init_menus();
// Henri: got you!
// CURIOUSLY NO PROBLEM if mintty is started from either cmd or explorer
  //update_transparency(); // culprit: Oh God, eye candy ...
if ( (fh = fopen("_RUNNING", "w") ) == (FILE *)NULL) error("_RUNNING ...");
fclose(fh);

// Henri: ouch! -- it even crashes  before this point
if ( (fh = fopen("_show_window", "w") ) == (FILE *)NULL) error("show_window ...");
fclose(fh);
  // Create child process.
  child_create(
    argv, &(struct winsize){cfg.rows, cfg.cols, term_width, term_height}
  );

The culprit is (at least at my place: update_transparancy()). After I had removed
the invocation of update_transparency() before the call to child_create(), mintty
did not crash anymore (at least at my place).

How did I proceed in finding this bug ... well, basically, I applied some debugging
in the old-fashioned way (using printf, sort of).

I started with the addition of this code:

i.e. I replaced 'your fork code', which follows after the processing of the command
line options, with:

  finish_config();

#if 1 // Henri
char my_msg[100];
if (snprintf(my_msg, 100, "getpgrp() = %d, getpid() = %d\n", getpgrp(), getpid() ) > 0) {
    show_msg(stdout, my_msg);
}

FILE *fh;
if (getppid() != (pid_t)1) {
                  /* Perhaps NOT the correct condition (or at least NOT complete)
                     However, is is sufficient for the following 2 cases:
                      - starting a shortcut to mintty (which forks bash), followed by yet another
                        invocation of mintty
                      - starting a shortcut to bash, followed by a invocation of mintty
                   */

    // a process started by bash is always a process group leader (fork will always happen)
    if (getpgrp() == getpid()) {
        switch (fork()) {
        case -1:
            error("fork");
        case 0:
            /* child */
            show_msg(stdout, "child"); // debug
            break;
        default:
            /* parent */
            show_msg(stdout, "parent"); // debug
            return 0;
        }
    }

// Henri: output to file, as output to stdout will not do after setsid()
    if ( (fh = fopen("_henri", "w") ) == (FILE *)NULL) error("fopen ...");
    if ( fprintf(fh, "before setsid() ...\n") <= 0) error("fprintf ...");
fflush(fh);
    if (setsid() < 0) {
        fprintf(fh, "setsid() failed\n");
    } else {
        fprintf(fh, "setsid() ...\n");
    }
fflush(fh);
fclose(fh);

} // if (!isatty(0))
#endif

I learned from this exercise, that the bug had to be further down the source code,
as mintty kept on crashing.

Next, I applied "bisection" on the remainder of the file (winmain.c) ...

It turned out, that mintty can survive its invocation (at least at my place), if I
remove the invocation of update_transparancy() before the call to child_create().

Now, the ball is in your court again ...

Btw, invocation of mintty from cmd has the same issue as mintty had, when invoked
from bash (has been fixed after patch_319 had been applied by you).

Henri

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

Hi Thomas,

Additionally ...

> But first things, first ...
>
> Please, make a mental picture of the check boxes at your place at 'control panel >
> performance information and tools > adjust visual effects'.
>
> I'll bet, all check boxes for "eye candy" has been checked at your place; NONE of
> them are checked at my place ...
> (I am an old fashioned guy, who wants his 8 cores to do useful things)

Additionally I "enabled" 'Windows Classic' ... (which disables transparency, does it
not?) i.s.o. 'Windows 7' (the default).
(control panel > personalization)

(in an attempt to specify how your environment might be different from mine)

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

> Hi Thomas,
>
> Additionally ...
>
>> But first things, first ...
>>
>> Please, make a mental picture of the check boxes at your place at 'control panel >
>> performance information and tools > adjust visual effects'.
>>
>> I'll bet, all check boxes for "eye candy" has been checked at your place; NONE of
>> them are checked at my place ...
>> (I am an old fashioned guy, who wants his 8 cores to do useful things)
>
> Additionally I "enabled" 'Windows Classic' ... (which disables transparency, does it
> not?) i.s.o. 'Windows 7' (the default).
> (control panel > personalization)
>
> (in an attempt to specify how your environment might be different from mine)

Confirmed.

Either
 - changing to 'best appearance' (visual effects) or
 - changing to 'Windows 7' (personalization)

does the trick ... i.e. mintty v211 (and v212 as modified by me, but W/O removing the
invocation of update_transparency() ) will not crash

Changing back to "my default" will make them crash again.

Exit Henri

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Thomas Wolff]

Am 26.07.2015 um 13:58 schrieb Houder:
> ...
Hi, thank you very much for this analysis which should enable me to do
further investigation; first, I'd like to know whether the two
alternative codelets for the -D option change anything.
Anyway, maybe I should simply disable transparency, either at all (but
people would complain, I'm sure) or at least if mintty is invoked from a
console, as a workaround.
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

> Hi, thank you very much for this analysis which should enable me to do
> further investigation; first, I'd like to know whether the two alternative
> codelets for the -D option change anything.
> Anyway, maybe I should simply disable transparency, either at all (but
> people would complain, I'm sure) or at least if mintty is invoked from a
> console.

Hi Thomas,

Let me rephrase/summarize my findings:

Executing 'mintty -D' (i.e. v212)

    from a shortcut to bash (i.e. Cygwin console),

will fork itself, where the child will turn itself into a session leader, as
desired.

i.e. the following code will be executed:

#if 1 // Thomas
 if (daemonize && !isatty(0)) { // daemonize == true, !isatty(0) == true
   if (fork() > 0) exit(0);
   setsid(); // executed by child
 }
#endif

1. if 'Windows Basic' has been selected (Personalization), the child will crash.

2. if 'Windows 7' has been selected (Personalization), the child will NOT crash,
   ... and, eventually, fork itself, where the "grandchild" will replace itself
   by bash in the end.

@@ ps ax
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
      800    2752     800       3684  pty0        1000 00:35:30 /usr/bin/ps
     2752    3936    2752       1708  pty0        1000 00:35:25 /usr/bin/bash        <====
I    3252       1    3252       3252  cons0       1000 23:58:38 /usr/bin/bash
     3936       1    3936       3936  ?           1000 00:35:25 /usr/bin/mintty-v212 <====

case 1. reveals a bug in update_transparency() (or in the call stack below that)

Henri

Re. 'Anyway, maybe I should simply disable transparency ... if mintty is invoked
from a console, as a workaround.'

Why? As I see it, the code that manages the "advanced features" (eye candy) of
mintty has a bug, that must be solved.

However, in future, it might be wise to restructure mintty in a "classic/basic"
part and an "enhanced part". The advantage would be, that one could request for
the "basic part" (command line option), in case of a bug in the "enhanced part".

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Csaba Ráduly]

On Sat, Jul 25, 2015 at 10:15 PM, Houder  wrote:
...
> Please, make a mental picture of the check boxes at your place at 'control panel >
> performance information and tools > adjust visual effects'.
>
> I'll bet, all check boxes for "eye candy" has been checked at your place; NONE of
> them are checked at my place ...
> (I am an old fashioned guy, who wants his 8 cores to do useful things)

They do, even with the checkboxes on:
http://blogs.msdn.com/b/oldnewthing/archive/2013/03/27/10405554.aspx

Csaba
--
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

> On Sat, Jul 25, 2015 at 10:15 PM, Houder  wrote:
> ...
>> Please, make a mental picture of the check boxes at your place at 'control panel >
>> performance information and tools > adjust visual effects'.
>>
>> I'll bet, all check boxes for "eye candy" has been checked at your place; NONE of
>> them are checked at my place ...
>> (I am an old fashioned guy, who wants his 8 cores to do useful things)
>
> They do, even with the checkboxes on:
> http://blogs.msdn.com/b/oldnewthing/archive/2013/03/27/10405554.aspx

Thanks for the link ... ;-)

So, I am of those guys who thinks he is "awesomely clever". Right?

    "because enthusiasts who think they are so awesomely clever, looooove
     disabling anything that makes the computer look pretty, because they're
     convinced that effort making the computer look pretty is clearly done
     at the expense of performance."

As I do not want to be "stupid", I enabled for "best appearance" :-))

As I totally do not appreciate the eye candy I got after enabling for "best
appearance" , I decided to select 'Windows Basic' (Personalization).

Guess what? 'mintty -D' crashes ...

Henri

> Csaba
> --
> GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
> The Tao of math: The numbers you can count are not the real numbers.
> Life is complex, with real and imaginary parts.
> "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
> "People disagree with me. I just ignore them." -- Linus Torvalds
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

> Hi Thomas,
>
> Let me rephrase/summarize my findings:
>
> Executing 'mintty -D' (i.e. v212)
>
>     from a shortcut to bash (i.e. Cygwin console),
>
> will fork itself, where the child will turn itself into a session leader, as
> desired.
>
> i.e. the following code will be executed:
>
> #if 1 // Thomas
>  if (daemonize && !isatty(0)) { // daemonize == true, !isatty(0) == true
>    if (fork() > 0) exit(0);
>    setsid(); // executed by child
>  }
> #endif
>
> 1. if 'Windows Basic' has been selected (Personalization), the child will crash.
>
> 2. if 'Windows 7' has been selected (Personalization), the child will NOT crash,
>    ... and, eventually, fork itself, where the "grandchild" will replace itself
>    by bash in the end.

Hi Thomas,

I _may_ have found the cause of the problem ... (but all bets are off!).

main() in winmain.c starts as follows:

int
main(int argc, char *argv[])
{
  main_argv = argv;
  main_argc = argc;
// Henri: too early?
#if 0
  load_dwm_funcs();
#endif

load_dwm_funcs() apparently "loads" a library, as follows:

load_dwm_funcs
  load_sys_library("dwmapi.dll")
    LoadLibrary ...

Will the library still be loaded in the child, I asked myself ...

As an experiment, I moved the call to load_dwm_funcs() after fork/setsid.

... fork()
... setsid()

// child continues ...

// Henri: will dwmapi.dll still be loaded after the fork() call ?????
#if 1
load_dwm_funcs();
#endif

Still more testing is needed ... but I _may_ have found why mintty -D crashes. But
I cannot explain why the crash does not occur when "eye candy" has been enabled.

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Houder]

Hi Thomas,

Moving load_dwm_funcs() did the trick ...

Tested on 32-bits and 64-bits, W7

See appendix (winmain.c)

Henri
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Thomas Wolff]

Am 27.07.2015 um 17:58 schrieb Houder:
> Hi Thomas,
>
> Moving load_dwm_funcs() did the trick ...
>
>
Thanks again for your analysis.
In Control Panel → Performance Information and Tools → Adjust visual
effects,
it is only the last of the flags, ☐ Use visual styles on windows and
buttons,
that makes the difference; if deselected, mintty crashes if called from
a console or somehow doubly isolated by
(setsid mintty &).

Apparently, LoadLibrary does not propagate to a forked thread; however,
the result was kept static, so being called on a wrong assumption...

A release with the fix will follow soon.
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Buchbinder, Barry (NIH/NIAID) [E]]

Thomas Wolff sent the following at Thursday, July 23, 2015 6:15 PM
>mintty 2.1.2 is an update in response to a number of crash reports under
>unclear circumstances; mintty only detaches from the caller's terminal
>if the option -D is given

Neither man mintty nor mintty --help document the new -D option.

Thanks,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.