From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75629 invoked by alias); 25 Jul 2015 20:15:22 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 75593 invoked by uid 89); 25 Jul 2015 20:15:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: lb1-smtp-cloud2.xs4all.net Received: from lb1-smtp-cloud2.xs4all.net (HELO lb1-smtp-cloud2.xs4all.net) (194.109.24.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 25 Jul 2015 20:15:16 +0000 Received: from oude-webmail.xs4all.nl ([194.109.26.21]) by smtp-cloud2.xs4all.net with ESMTP id wkFD1q0030TK8Cq01kFDdY; Sat, 25 Jul 2015 22:15:13 +0200 Received: from 83.162.234.136 (SquirrelMail authenticated user incog) by oude-webmail.xs4all.nl with HTTP; Sat, 25 Jul 2015 22:15:13 +0200 Message-ID: In-Reply-To: References: <63a08c60771faffa23bc1c029235301d.squirrel@oude-webmail.xs4all.nl> <55B22422.6000601@towo.net> <55B2B644.8010506@towo.net> Date: Sat, 25 Jul 2015 20:15:00 -0000 Subject: Re: [ANNOUNCEMENT] Update: mintty 2.1.2 From: "Houder" To: cygwin@cygwin.com, "Thomas Wolff" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00394.txt.bz2 > 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