Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3C8CE099.E028CD19@csksoftware.com> Date: Mon, 11 Mar 2002 17:51:37 +0100 From: "Michael Teske" X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: make core dumping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20010407 Hi! Maybe this is interesting for some of you: I did some research for the "make somtimes core-dumping problem", which still seems to be open from what I read in the release notes. With the help of the generated stack traces I saw that it happens in the function exec_command () in job.c. Then I added some printf-calls and saw that for some reason, the execvp()-call in line 2276 fails with errno=4 (EINTR, Interrupted system call). After that, the stack seems to be garbled completely, because then argv is set to 0x5, and the actual crash happens in perror_with_name ("execvp: ", argv[0]); This was done on WindowsNT, $ uname -a CYGWIN_NT-4.0 LOCUTUS 1.3.3(0.46/3/2) 2001-09-12 23:54 i686 unknown and a self-built (with debug info) make-3.79.1-5. What still confuses me is that if I take the sources of make-3.79.1-2 and rebuild it with my cygwin version, the core never happens. I did a diff to the latest version but I could not figure out what the problem is. The mean thing is that it doesn't happen every time and the probability of it happening has something to do with the number of printf-calls before; and strangely, it is much easier to reproduce if stdout is redirected to a file. Hopefully this helps someone to track down the problem. Greetings, Michael -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/