Mail Archives: cygwin/2015/07/25/16:15:40
> 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
- Raw text -