Re: Please try the latest snapshot
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: The latest snapshot has some more signal-handling restructuring. I'd appreciate it if people would check it out. Looks good so far. I've had a compile that would pretty often lock up cmake during the config phase so that it needed to be killed from task manager. That seems to be gone, as well as the hangs that git would sometimes produce when doing lots of git-receive-pack back-to-back. Regards, Achim. -- 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
Re: Please try the latest snapshot
On Wed, Apr 10, 2013 at 09:20:26AM -0400, Christopher Faylor wrote: The latest snapshot has some more signal-handling restructuring. I'd appreciate it if people would check it out. http://cygwin.com/snapshots/ -- 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
Re: please try the latest snapshot
Hi, This snapshot (20040306) fixes some of the problems with running emacs. The problem existed even with snapshot of 20040225 (hadn't tried 0305). emacs (under X11) has been running fine for over a day now. It used to crash randomly (SEGV), earlier. Thanks, rb Christopher Faylor wrote: The latest snapshot should fix virtual memory exhausted errors that were reported when running make -j. I am close to releasing cygwin 1.5.8 so I want to verify that this is fixed. http://cygwin.com/snapshots/ cgf __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please try the latest snapshot
Christopher Faylor wrote: The latest snapshot should fix virtual memory exhausted errors that were reported when running make -j. I am close to releasing cygwin 1.5.8 so I want to verify that this is fixed. OK, did that, and got a freeze after 196 iterations. Still using your make with debug info. This time my script enabled the malloc debug info strace -mall+malloc -o strace.out make -j -f MakefileV $logname 2 $logerr so the strace is very long, you can find it here: http://www.scytek.de/cygwin/strace.zip Unfortunately I pressed CTRL-c before looking at the running processes, I cannot say where it was hanging. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please try the latest snapshot
Volker Quetschke wrote: Christopher Faylor wrote: The latest snapshot should fix virtual memory exhausted errors that were reported when running make -j. I am close to releasing cygwin 1.5.8 so I want to verify that this is fixed. OK, did that, and got a freeze after 196 iterations. Still using your make with debug info. This time my script enabled the malloc debug info strace -mall+malloc -o strace.out make -j -f MakefileV $logname 2 $logerr so the strace is very long, you can find it here: http://www.scytek.de/cygwin/strace.zip Unfortunately I pressed CTRL-c before looking at the running processes, I cannot say where it was hanging. Volker I've run it twice so far, 128 iterations, then about 2500, running it a third time now. In both cases, it was make hanging with 0% cpu usage, and I lost the strace from the second run (I tried using /bin/kill -f pid, and the return code from the make process was 0, so the script kept going). -Rolf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please try the latest snapshot
OK, did that, and got a freeze after 196 iterations. Still using your make with debug info. This time my script enabled the malloc debug info strace -mall+malloc -o strace.out make -j -f MakefileV $logname 2 $logerr so the strace is very long, you can find it here: http://www.scytek.de/cygwin/strace.zip Unfortunately I pressed CTRL-c before looking at the running processes, I cannot say where it was hanging. I've run it twice so far, 128 iterations, then about 2500, running it a third time now. In both cases, it was make hanging with 0% cpu usage, and I lost the strace from the second run (I tried using /bin/kill -f pid, and the return code from the make process was 0, so the script kept going). The first run (mentioned above) were 196 iterations, I startet the script again and got an error, not a hang, after 1987 iterations: make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs I have a strace with malloc for this too, shall I put it somewhere on the web? Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
Christopher Faylor wrote: I fixed some more problems with both vfork and with fork recently. The fixes are currently in cvs. It's much better. CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-29 22:44 i686 unknown unknown Cygwin I only have problems with the more complicated tests. Open two tty windows, tty0 and tty1. In the tty0 window, type setsid bash -c echo hello /dev/tty1; /bin/sleep 10; /bin/echo there /dev/tty Note the first echo is a built-in and the last /dev/tty (not /dev/tty1). Things go as I think they should: echo there appear in the tty1 window, and ps shows that bash and sleep have tty1 as ctty. However when using sh, setsid sh -c echo hello /dev/tty1; /bin/sleep 10; /bin/echo there /dev/tty sh and the final echo hang forever (with echo in the O state in ps), and sh cannot be terminated with kill (OK from the task manager). Moreover sysinternals shows that tty1 is not opened in sh, nor in /bin/echo (despite being the ctty), although it is open in /bin/sleep. (My sandbox is slightly different from cvs, but it shouldn't matter). Also I still observe processes terminating with the error in Cygwin1.dll popup (exim, mutt, tty, id, dircolors). JIT gdb kicked in once. Only thread 1 was active and I couldn't get any useful info. I didn't see the proc lock system_printf. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Sun, Dec 28, 2003 at 12:26:32PM -0500, Nicholas Wourms wrote: Pierre A. Humblet wrote: At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote: I missed the 'sh -c' clue in your previous message. Since sh uses vfork, that indicates a vfork problem. I've checked in some more changes to deal with this. It seems to do the right thing both with sh -c and without. It also should have the added benefit of doing the right thing wrt deallocating the console appropriately since open_fhs should now track the ctty usecount. This was screwed up before, apparently even before I started mucking with the tty stuff. I sure do hate usage counting. cgf Yes, that works fine now, as does bash -c inetd. Sorry to jump in on this, but I run into a few problems with the changes you made last night and one issue which has been a problem for some time now. This is on my Win2k box and all problems were noticed when I logged in remotely via ssh (I have not tried locally). If it makes any difference, the /usr/src dir, where all my project and cygwin source is contained, is a managed mount. Issues from yesterday's checkin: 1)When run by itself from the command line, `make` is not forking properly for recursive makes, instead it aborts and returns a bogus HANGUP signal to the console. This is easily seen when attempting to build the Cygwin tree. I cannot provide any useful output since it appears that calling the process from within gdb or through strace actually keeps make from failing to fork, but make still screws up the order of entry into subdirs. I routinely check correct cygwin operation by building cygwin so I can't reproduce this. 2)`procps auxf` incorrectly identifies top-parent processes as defunct, even though ps and the nt process monitor shows them to be valid. However, for postgres's postmaster, the parent and *all* children are labeled as defunct even though I can confirm that the server is up and running. A trivial test of this, which is to run procps auwx from a command prompt, does not demonstrate this here. 3)Running configure scripts using sh.exe (which is default when you ./configure) always hangs, whereas running them through bash.exe works fine (although it does hang from time to time). In either case, when it hangs, doing ctrl-c will drop you to the command line. However, the process isn't terminated, like one would expect. Also, it refuses to obey any signal except SIGKILL. I don't use bash very often. I use zsh or just the command prompt. I can run 'sh /whereever/configure' just fine. Existing issues since 1.5.5: 3)I find myself involuntarily logged-out of my sessions at random intervals. This is especially prevalent when doing massive recursive `rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. However, whatever is causing it seems to be getting fixed, since this happens less frequently then it used to. A small kludge I use to get around this is by running links.exe then using ctrl-Z to send it to a stopped state. Then if it tries to log me out, it will fail because I have a stopped process. Again, I don't see this, so I don't know how it could be fixed. 4)lynx crashes on startup, dropping me back to the command line. Running it through gdb, the segfault happens at line 81 of cygtls.cc, _last_thread-next = this which is inside the function _threadinfo::init_thread(void*). Unfortunately, my system is in a state where I cannot get make to run correctly, so trying to build a debug version of lynx at this point is not feasible. I should note that I do not see this problem inside links. Since cygtls.c is a recent addition, this is not a 1.5.5 issue. lynx also works fine here. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Sat, Dec 27, 2003 at 06:28:09PM -0500, Pierre A. Humblet wrote: ...when I launch inetd from an rxvt window running bash, or from a Dos window running cygwin.bat with tty, I still see tty handles in inetd. I fixed some more problems with both vfork and with fork recently. The fixes are currently in cvs. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Mon, Dec 29, 2003 at 10:04:01PM -0500, Christopher Faylor wrote: On Sun, Dec 28, 2003 at 12:26:32PM -0500, Nicholas Wourms wrote: Pierre A. Humblet wrote: At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote: I missed the 'sh -c' clue in your previous message. Since sh uses vfork, that indicates a vfork problem. I've checked in some more changes to deal with this. It seems to do the right thing both with sh -c and without. It also should have the added benefit of doing the right thing wrt deallocating the console appropriately since open_fhs should now track the ctty usecount. This was screwed up before, apparently even before I started mucking with the tty stuff. I sure do hate usage counting. cgf Yes, that works fine now, as does bash -c inetd. Sorry to jump in on this, but I run into a few problems with the changes you made last night and one issue which has been a problem for some time now. This is on my Win2k box and all problems were noticed when I logged in remotely via ssh (I have not tried locally). If it makes any difference, the /usr/src dir, where all my project and cygwin source is contained, is a managed mount. Issues from yesterday's checkin: 1)When run by itself from the command line, `make` is not forking properly for recursive makes, instead it aborts and returns a bogus HANGUP signal to the console. This is easily seen when attempting to build the Cygwin tree. I cannot provide any useful output since it appears that calling the process from within gdb or through strace actually keeps make from failing to fork, but make still screws up the order of entry into subdirs. I routinely check correct cygwin operation by building cygwin so I can't reproduce this. 2)`procps auxf` incorrectly identifies top-parent processes as defunct, even though ps and the nt process monitor shows them to be valid. However, for postgres's postmaster, the parent and *all* children are labeled as defunct even though I can confirm that the server is up and running. A trivial test of this, which is to run procps auwx from a command prompt, does not demonstrate this here. 3)Running configure scripts using sh.exe (which is default when you ./configure) always hangs, whereas running them through bash.exe works fine (although it does hang from time to time). In either case, when it hangs, doing ctrl-c will drop you to the command line. However, the process isn't terminated, like one would expect. Also, it refuses to obey any signal except SIGKILL. I don't use bash very often. I use zsh or just the command prompt. I can run 'sh /whereever/configure' just fine. Existing issues since 1.5.5: 3)I find myself involuntarily logged-out of my sessions at random intervals. This is especially prevalent when doing massive recursive `rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. However, whatever is causing it seems to be getting fixed, since this happens less frequently then it used to. A small kludge I use to get around this is by running links.exe then using ctrl-Z to send it to a stopped state. Then if it tries to log me out, it will fail because I have a stopped process. Again, I don't see this, so I don't know how it could be fixed. 4)lynx crashes on startup, dropping me back to the command line. Running it through gdb, the segfault happens at line 81 of cygtls.cc, _last_thread-next = this which is inside the function _threadinfo::init_thread(void*). Unfortunately, my system is in a state where I cannot get make to run correctly, so trying to build a debug version of lynx at this point is not feasible. I should note that I do not see this problem inside links. Since cygtls.c is a recent addition, this is not a 1.5.5 issue. lynx also works fine here. Btw, I should point out, that I am using the most recent version of cygwin currently in CVS. I didn't try this with the cygwin vintage that this message refers to but I haven't made any changes which would cause any of the above to work any better. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
Pierre A. Humblet wrote: At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote: I missed the 'sh -c' clue in your previous message. Since sh uses vfork, that indicates a vfork problem. I've checked in some more changes to deal with this. It seems to do the right thing both with sh -c and without. It also should have the added benefit of doing the right thing wrt deallocating the console appropriately since open_fhs should now track the ctty usecount. This was screwed up before, apparently even before I started mucking with the tty stuff. I sure do hate usage counting. cgf Yes, that works fine now, as does bash -c inetd. Sorry to jump in on this, but I run into a few problems with the changes you made last night and one issue which has been a problem for some time now. This is on my Win2k box and all problems were noticed when I logged in remotely via ssh (I have not tried locally). If it makes any difference, the /usr/src dir, where all my project and cygwin source is contained, is a managed mount. Issues from yesterday's checkin: 1)When run by itself from the command line, `make` is not forking properly for recursive makes, instead it aborts and returns a bogus HANGUP signal to the console. This is easily seen when attempting to build the Cygwin tree. I cannot provide any useful output since it appears that calling the process from within gdb or through strace actually keeps make from failing to fork, but make still screws up the order of entry into subdirs. 2)`procps auxf` incorrectly identifies top-parent processes as defunct, even though ps and the nt process monitor shows them to be valid. However, for postgres's postmaster, the parent and *all* children are labeled as defunct even though I can confirm that the server is up and running. 3)Running configure scripts using sh.exe (which is default when you ./configure) always hangs, whereas running them through bash.exe works fine (although it does hang from time to time). In either case, when it hangs, doing ctrl-c will drop you to the command line. However, the process isn't terminated, like one would expect. Also, it refuses to obey any signal except SIGKILL. Existing issues since 1.5.5: 3)I find myself involuntarily logged-out of my sessions at random intervals. This is especially prevalent when doing massive recursive `rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. However, whatever is causing it seems to be getting fixed, since this happens less frequently then it used to. A small kludge I use to get around this is by running links.exe then using ctrl-Z to send it to a stopped state. Then if it tries to log me out, it will fail because I have a stopped process. 4)lynx crashes on startup, dropping me back to the command line. Running it through gdb, the segfault happens at line 81 of cygtls.cc, _last_thread-next = this which is inside the function _threadinfo::init_thread(void*). Unfortunately, my system is in a state where I cannot get make to run correctly, so trying to build a debug version of lynx at this point is not feasible. I should note that I do not see this problem inside links. Although I'm further investigating these problems, I thought I might share them since the next release is being discussed. Cheers, Nicholas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
Christopher Faylor wrote: On Fri, Dec 26, 2003 at 05:37:36PM +0100, Philippe Torche wrote: Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. I've tested it (CVS version 12:35 GMT + 1) on our 4 Xeon on W2003S and unfortunately my previous test case (run_t.sh and t.sh) always fails. I've replace bash with sh and no problem anymore (not have wait enough maybe) ! A bash bug ? Let me be extremely clear about this again: I don't have a 4 Xeon processor running W2003S. I will not be able to test this and I, frankly, don't care much about this corner case -- especially if it is not a regression from previous releases. So, if you were just reporting this as a data point, then thanks. If you are expecting me to do something about it, then, you will, unfortunately, be disappointed. :-( Not you but other maybe ! If you show old threads, I'm not alone with this problem ! I can't give access to a multi CPU computer (client machine), but maybe somebody can ? The test suite runs soon happily (except now 3 cases) with my Athlon on WinXP, and I'm preparing to run it tomorrow on our 4 Xeon. :-) The test case give me the same result I think I will have to give a gold star to the person who figures out why those three cases are failing. It really isn't that hard. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Sat, Dec 27, 2003 at 05:29:56PM +0100, Philippe Torche wrote: So, if you were just reporting this as a data point, then thanks. If you are expecting me to do something about it, then, you will, unfortunately, be disappointed. :-( Not you but other maybe ! Ok. I'll just ignore your periodic reports of the same problem from now on. Or, if you want to send me a 4 Xeon system, I'll look into the problem. This is not something that can be easily debugged remotely. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Fri, Dec 26, 2003 at 10:27:51PM -0500, Pierre A. Humblet wrote: At 09:40 PM 12/26/2003 -0500, Christopher Faylor wrote: I tried the current CVS version and I don't see any stray tty garbage with inetd. I never tried this with an older snapshot, however, so I don't know if I would have been lucky before. I did try a much simpler test case which worked incorrectly with CYGWIN=tty and correctly after today's initial setsid change. Here both exim and inetd are still off, with CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 22:04 i686 unknown unknown Cygwin The trace of sh -c inetd in on http://mysite.verizon.net/phumblet/trace The problem is the same, AFAICS there is an unaccounted for jump in usecount. 177 298078 [main] SH 480747 fhandler_tty_slave::open: /dev/tty0 opened, incremented open_fhs 4, archetype usecount 4 178 336409 [main] sh 480747 fhandler_tty_slave::dup: incremented open_fhs 5, archetype usecount 6 I missed the 'sh -c' clue in your previous message. Since sh uses vfork, that indicates a vfork problem. I've checked in some more changes to deal with this. It seems to do the right thing both with sh -c and without. It also should have the added benefit of doing the right thing wrt deallocating the console appropriately since open_fhs should now track the ctty usecount. This was screwed up before, apparently even before I started mucking with the tty stuff. I sure do hate usage counting. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote: I missed the 'sh -c' clue in your previous message. Since sh uses vfork, that indicates a vfork problem. I've checked in some more changes to deal with this. It seems to do the right thing both with sh -c and without. It also should have the added benefit of doing the right thing wrt deallocating the console appropriately since open_fhs should now track the ctty usecount. This was screwed up before, apparently even before I started mucking with the tty stuff. I sure do hate usage counting. cgf Yes, that works fine now, as does bash -c inetd. However when I launch inetd from an rxvt window running bash, or from a Dos window running cygwin.bat with tty, I still see tty handles in inetd. CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-27 17:25 i686 unknown unknown Cygwin I ran strace -o trace rxvt -d :0 -e bash followed by inetd in the rxvt window. The trace, available on http://mysite.verizon.net/phumblet/trace, shows that the usecount is off by one. Correct run (bash -c inetd): 159 220557 [main] inetd 34889607 setsid: sid 34889607, pgid 34889607, ctty -1, open_fhs 3 168 220725 [main] inetd 34889607 fhandler_tty_slave::close: /dev/tty2 closed, decremented open_fhs 2, usecount 2 Incorrect run (under rxvt) 167 88587 [main] inetd 34937947 setsid: sid 34937947, pgid 34937947, ctty -1, open_fhs 3 159 88746 [main] inetd 34937947 fhandler_tty_slave::close: /dev/tty2 closed, decremented open_fhs 2, usecount 3 Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. cgf I've tested it (CVS version 12:35 GMT + 1) on our 4 Xeon on W2003S and unfortunately my previous test case (run_t.sh and t.sh) always fails. The test suite runs soon happily (except now 3 cases) with my Athlon on WinXP, and I'm preparing to run it tomorrow on our 4 Xeon. Now, I should go, I'll will continue tomorrow. Thanks you very much, Merry Christmas to all of you. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
Christopher == Christopher Faylor [EMAIL PROTECTED] writes: Christopher The subject says it all. Christopher I'm hoping to release cygwin 1.5.6 shortly after Christmas. I just checked cygwin1-20031225 Apache (1.3.24-5) stackdumps right away and wmaker (0.80.0-2) reproducable after 5 !!! minutes. Sorry a party is going on, no more information right now... A happy new year to all of you. Christopher cgf Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Wed, Dec 24, 2003 at 06:27:59PM -0500, Christopher Faylor wrote: On Wed, Dec 24, 2003 at 06:15:24PM -0500, Pierre A. Humblet wrote: At 11:59 AM 12/24/2003 -0500, Christopher Faylor wrote: On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote: On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. On WinMe the queue runner forked by the exim daemon still occasionally produces a popup indicating an error in Cygwin1.dll a popup indicating an error...? Not too helpful. It has happened once more, but differently. ps shows the child as defunct. Sysinternals shows everything normal, pinfo exists in the child. There is no fork failure, in fact the one I mentioned earlier is the only one out of 17070 runs. This time when I killed the daemon (just to see), I got 330495 [main] exim 34658275 proc_subproc: couldn't get proc lock. Something is wrong. 330520 [main] exim 34658275 proc_subproc: couldn't get proc lock. Something is wrong If you have the time could you add some more debugging output to the failing cases that lead to this message and try running it with that? I updated from cvs and noticed you had already added debug info. CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 12:15 i686 unknown unknown Cygwin -996371854 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 1628435976 -996369556 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 1628435976 Also, while running sysinternals I noticed to the exim daemon still had tty related handles, despite setsid(). Ditto for inetd. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Fri, Dec 26, 2003 at 03:46:41PM -0500, Pierre A. Humblet wrote: On Wed, Dec 24, 2003 at 06:27:59PM -0500, Christopher Faylor wrote: On Wed, Dec 24, 2003 at 06:15:24PM -0500, Pierre A. Humblet wrote: At 11:59 AM 12/24/2003 -0500, Christopher Faylor wrote: On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote: On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. On WinMe the queue runner forked by the exim daemon still occasionally produces a popup indicating an error in Cygwin1.dll a popup indicating an error...? Not too helpful. It has happened once more, but differently. ps shows the child as defunct. Sysinternals shows everything normal, pinfo exists in the child. There is no fork failure, in fact the one I mentioned earlier is the only one out of 17070 runs. This time when I killed the daemon (just to see), I got 330495 [main] exim 34658275 proc_subproc: couldn't get proc lock. Something is wrong. 330520 [main] exim 34658275 proc_subproc: couldn't get proc lock. Something is wrong If you have the time could you add some more debugging output to the failing cases that lead to this message and try running it with that? I updated from cvs and noticed you had already added debug info. I added strace debugging. You can use that as a clue for what I was talking about and make it visible if you can't run exim under strace. CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 12:15 i686 unknown unknown Cygwin -996371854 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 1628435976 -996369556 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 1628435976 Also, while running sysinternals I noticed to the exim daemon still had tty related handles, despite setsid(). Ditto for inetd. Calling setsid does not automatically eliminate tty handles. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
At 05:59 PM 12/26/2003 -0500, Christopher Faylor wrote:
I added strace debugging. You can use that as a clue for what I was
talking about and make it visible if you can't run exim under strace.
I put a try_to_debug(1). Waiting for something to happen.
Also, while running sysinternals I noticed to the exim daemon still had tty
related handles, despite setsid(). Ditto for inetd.
Calling setsid does not automatically eliminate tty handles.
This is what inetd does:
if (setsid() == -1)
return (-1);
if (!noclose (fd = open(PATH_DEVNULL, O_RDWR, 0)) != -1) {
(void)dup2(fd, STDIN_FILENO);
(void)dup2(fd, STDOUT_FILENO);
(void)dup2(fd, STDERR_FILENO);
***
Before your last changes, strace was showing
160 282749 [main] inetd 34569887 close: close (2)
361 283110 [main] inetd 34569887 fhandler_tty_slave::close: decremented open_fhs 0,
archetype usecount 2
198 283308 [main] inetd 34569887 fhandler_tty_slave::close: just exiting because
archetype usecount is 0
163 283471 [main] inetd 34569887 close: 0 = close (2)
160 283631 [main] inetd 34569887 dtable::dup2: 2 = dup2 (3, 2)
***
Now usecount is even higher
159 292878 [main] inetd 1086339 close: close (2)
181 293059 [main] inetd 1086339 fhandler_tty_slave::close: decremented open_fhs 0,
archetype usecount 3
313 293372 [main] inetd 1086339 fhandler_tty_slave::close: just returning because
archetype usecount is 0
175 293547 [main] inetd 1086339 close: 0 = close (2)
158 293705 [main] inetd 1086339 dtable::dup2: 2 = dup2 (3, 2)
I looked at your latest change in syscalls.cc.
It seems to me that setsid should simply call close all the time if (cygheap-ctty)
and let close() take care of usecount.
Ditto in pinfo::set_ctty where a problem similar to the one you addressed also exists.
I don't think that will take care of everything, but I can't follow what's happening
when tracing sh -c inetd
Usecount jumps by 2 when open_fhs goes up by 1.
179 854139 [main] SH 34649867 fhandler_tty_slave::open: /dev/tty1 opened,
incremented open_fhs 3, archetype usecount 4
237 880231 [main] sh 34649867 fhandler_tty_slave::dup: incremented open_fhs 4,
archetype usecount 6
The trace is on http://mysite.verizon.net/phumblet/trace if interested.
Pierre
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Fri, Dec 26, 2003 at 05:59:59PM -0500, Christopher Faylor wrote: On Fri, Dec 26, 2003 at 03:46:41PM -0500, Pierre A. Humblet wrote: Also, while running sysinternals I noticed to the exim daemon still had tty related handles, despite setsid(). Ditto for inetd. Calling setsid does not automatically eliminate tty handles. I made some more changes to the tty code to eliminate a long-standing handle leak when CYGWIN=tty. I also *think* I eliminated a source of opened tty handles but I haven't checked the inetd case and need to go back to doing something besides working on cygwin. I haven't been able to duplicate any problems with exim on any of my NT-like systems, which is hardly surprising, since I know nothing about it or how to set it up. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Fri, Dec 26, 2003 at 09:13:36PM -0500, Pierre A. Humblet wrote:
At 05:59 PM 12/26/2003 -0500, Christopher Faylor wrote:
I added strace debugging. You can use that as a clue for what I was
talking about and make it visible if you can't run exim under strace.
I put a try_to_debug(1). Waiting for something to happen.
Thanks, for debugging this but that wasn't specifically what I was
talking about. If you go back and read the message, you'll see that I
was talking about your 'get_proc_lock' problem.
Also, while running sysinternals I noticed to the exim daemon still had tty
related handles, despite setsid(). Ditto for inetd.
Calling setsid does not automatically eliminate tty handles.
This is what inetd does:
if (setsid() == -1)
return (-1);
if (!noclose (fd = open(PATH_DEVNULL, O_RDWR, 0)) != -1) {
(void)dup2(fd, STDIN_FILENO);
(void)dup2(fd, STDOUT_FILENO);
(void)dup2(fd, STDERR_FILENO);
***
Before your last changes, strace was showing
160 282749 [main] inetd 34569887 close: close (2)
361 283110 [main] inetd 34569887 fhandler_tty_slave::close: decremented open_fhs
0, archetype usecount 2
198 283308 [main] inetd 34569887 fhandler_tty_slave::close: just exiting because
archetype usecount is 0
163 283471 [main] inetd 34569887 close: 0 = close (2)
160 283631 [main] inetd 34569887 dtable::dup2: 2 = dup2 (3, 2)
***
Now usecount is even higher
159 292878 [main] inetd 1086339 close: close (2)
181 293059 [main] inetd 1086339 fhandler_tty_slave::close: decremented open_fhs 0,
archetype usecount 3
313 293372 [main] inetd 1086339 fhandler_tty_slave::close: just returning because
archetype usecount is 0
175 293547 [main] inetd 1086339 close: 0 = close (2)
158 293705 [main] inetd 1086339 dtable::dup2: 2 = dup2 (3, 2)
I looked at your latest change in syscalls.cc.
It seems to me that setsid should simply call close all the time if (cygheap-ctty)
and let close() take care of usecount.
I had already checked in a change to this effect but I missed...
Ditto in pinfo::set_ctty where a problem similar to the one you
addressed also exists.
this. Thanks. I've checked in a new fix as well as a similar change
for close_all_files.
I don't think that will take care of everything, but I can't follow
what's happening when tracing sh -c inetd
I tried the current CVS version and I don't see any stray tty garbage
with inetd. I never tried this with an older snapshot, however, so I
don't know if I would have been lucky before. I did try a much simpler
test case which worked incorrectly with CYGWIN=tty and correctly after
today's initial setsid change.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Fri, Dec 26, 2003 at 09:40:10PM -0500, Christopher Faylor wrote: On Fri, Dec 26, 2003 at 09:13:36PM -0500, Pierre A. Humblet wrote: At 05:59 PM 12/26/2003 -0500, Christopher Faylor wrote: I added strace debugging. You can use that as a clue for what I was talking about and make it visible if you can't run exim under strace. I put a try_to_debug(1). Waiting for something to happen. Thanks, for debugging this but that wasn't specifically what I was talking about. If you go back and read the message, you'll see that I was talking about your 'get_proc_lock' problem. Yes, I put the try_to_debug just after the system_printf (couldn't get proc lock By the way, I never saw any problems with exim on NT4 either... I looked at your latest change in syscalls.cc. It seems to me that setsid should simply call close all the time if (cygheap-ctty) and let close() take care of usecount. I had already checked in a change to this effect but I missed... The latest change I saw was not decrementing usecount at all, so it wouldn't do the right thing if inetd closes the tty after calling setsid Ditto in pinfo::set_ctty where a problem similar to the one you addressed also exists. this. Thanks. I've checked in a new fix as well as a similar change for close_all_files. I don't think that will take care of everything, but I can't follow what's happening when tracing sh -c inetd I tried the current CVS version and I don't see any stray tty garbage with inetd. I never tried this with an older snapshot, however, so I don't know if I would have been lucky before. I did try a much simpler test case which worked incorrectly with CYGWIN=tty and correctly after today's initial setsid change. OK, I'll run cvs update. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
At 09:40 PM 12/26/2003 -0500, Christopher Faylor wrote: I tried the current CVS version and I don't see any stray tty garbage with inetd. I never tried this with an older snapshot, however, so I don't know if I would have been lucky before. I did try a much simpler test case which worked incorrectly with CYGWIN=tty and correctly after today's initial setsid change. Here both exim and inetd are still off, with CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 22:04 i686 unknown unknown Cygwin The trace of sh -c inetd in on http://mysite.verizon.net/phumblet/trace The problem is the same, AFAICS there is an unaccounted for jump in usecount. 177 298078 [main] SH 480747 fhandler_tty_slave::open: /dev/tty0 opened, incremented open_fhs 4, archetype usecount 4 178 336409 [main] sh 480747 fhandler_tty_slave::dup: incremented open_fhs 5, archetype usecount 6 The trace also shows e.g. open_fhs -3 Still waiting for exim to misbehave. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Thu, Dec 25, 2003 at 04:05:24PM +0930, Trevor Forbes wrote:
I run the testsuite when I built the dll which gives:
FAIL: msgtest.c (execute)
FAIL: semtest.c (execute)
FAIL: shmtest.c (execute)
FAIL: pthread/mainthreadexits.c (execute)
I think we've already been down the testsuite route.
The {msg,sem,shm}test failures should be obvious.
I'm working on mainthreadexits.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. On WinMe the queue runner forked by the exim daemon still occasionally produces a popup indicating an error in Cygwin1.dll In addition kill -9 exim_daemon produces 518380 [main] exim 34647479 proc_subproc: couldn't get proc lock. Something is wrong. 518404 [main] exim 34647479 proc_subproc: couldn't get proc lock. Something is wrong. 518429 [main] exim 34647479 proc_subproc: couldn't get proc lock. Something is wrong. CYGWIN_ME-4.90 hpn5170x 1.5.6s(0.108/3/2) 20031223 11:45:22 Ebenezer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote: On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. On WinMe the queue runner forked by the exim daemon still occasionally produces a popup indicating an error in Cygwin1.dll a popup indicating an error...? Not too helpful. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
At 11:59 AM 12/24/2003 -0500, you wrote: On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote: On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. On WinMe the queue runner forked by the exim daemon still occasionally produces a popup indicating an error in Cygwin1.dll a popup indicating an error...? Not too helpful. Here are a few more tidbits. The exact popup text is: Exim-4 has caused an error in CYGWIN1.DLL Exim-4 will now close If you continue to experience problems, try restarting your computer Close button ps shows the forked process in a normal state. sysinternals shows it too. There is only one thread handle and the pinfo mapped file is gone (it is still visible in the parent). The cygwin user mapped files are still there. I tried stracing the child, but got the same popup for strace. In previous trials I had failed to attach to the child from gdb. After pushing the close button (on the child), I noticed that the parent (daemon) exim showed too many pinfos. It had 7 pinfos mapped files, although it had no running child. I then killed -9 it, there was no error message. The exim log shows a few interesting things: The last mention of the child pid was (that may be misleading, reuse is a possibility) 2003-12-24 13:29:08 Start queue run: pid=159063 2003-12-24 13:29:08 End queue run: pid=159063 At around the time when I started looking into it, I see 2003-12-24 15:35:26 Start queue run: pid=153375 2003-12-24 15:35:26 End queue run: pid=153375 2003-12-24 15:36:26 Start queue run: pid=34403247 2003-12-24 15:36:26 End queue run: pid=34403247 Note a 5 min gap here, then 2003-12-24 15:42:26 daemon: fork of queue-runner process failed: Resource temporarily unavailable 2003-12-24 15:43:27 Start queue run: pid=176243 2003-12-24 15:43:27 End queue run: pid=176243 2003-12-24 15:44:27 Start queue run: pid=157315 2003-12-24 15:44:27 End queue run: pid=157315 2003-12-24 15:45:27 Start queue run: pid=153375 2003-12-24 15:45:27 End queue run: pid=153375 2003-12-24 15:46:27 Start queue run: pid=34403247 2003-12-24 15:46:27 End queue run: pid=34403247 2003-12-24 15:47:27 Start queue run: pid=178263 2003-12-24 15:47:27 End queue run: pid=178263 There is again a gap here. Next is normal, I killed -9 the parent. 2003-12-24 15:54:23 50 select() failures: Bad file descriptor There were no other gaps since 12:36:58, when I had started the daemon. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Wed, Dec 24, 2003 at 04:20:37PM -0500, Pierre A. Humblet wrote: At 11:59 AM 12/24/2003 -0500, you wrote: On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote: On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. On WinMe the queue runner forked by the exim daemon still occasionally produces a popup indicating an error in Cygwin1.dll a popup indicating an error...? Not too helpful. I tried stracing the child, but got the same popup for strace. In previous trials I had failed to attach to the child from gdb. Have you rebuilt strace? It was broken in 1.5.5. After pushing the close button (on the child), I noticed that the parent (daemon) exim showed too many pinfos. It had 7 pinfos mapped files, although it had no running child. I then killed -9 it, there was no error message. That's not necessarily a problem if exim had unreaped zombies. The exim log shows a few interesting things: The last mention of the child pid was (that may be misleading, reuse is a possibility) 2003-12-24 13:29:08 Start queue run: pid=159063 2003-12-24 13:29:08 End queue run: pid=159063 At around the time when I started looking into it, I see 2003-12-24 15:35:26 Start queue run: pid=153375 2003-12-24 15:35:26 End queue run: pid=153375 2003-12-24 15:36:26 Start queue run: pid=34403247 2003-12-24 15:36:26 End queue run: pid=34403247 Note a 5 min gap here, then 2003-12-24 15:42:26 daemon: fork of queue-runner process failed: Resource temporarily unavailable 2003-12-24 15:43:27 Start queue run: pid=176243 2003-12-24 15:43:27 End queue run: pid=176243 2003-12-24 15:44:27 Start queue run: pid=157315 2003-12-24 15:44:27 End queue run: pid=157315 2003-12-24 15:45:27 Start queue run: pid=153375 2003-12-24 15:45:27 End queue run: pid=153375 2003-12-24 15:46:27 Start queue run: pid=34403247 2003-12-24 15:46:27 End queue run: pid=34403247 2003-12-24 15:47:27 Start queue run: pid=178263 2003-12-24 15:47:27 End queue run: pid=178263 There is again a gap here. Next is normal, I killed -9 the parent. 2003-12-24 15:54:23 50 select() failures: Bad file descriptor There were no other gaps since 12:36:58, when I had started the daemon. There's really nothing here that is useful, unfortunately. Have you ever tried running exim via strace rather than trying to attach to it when it has a problem? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
At 11:59 AM 12/24/2003 -0500, Christopher Faylor wrote: On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote: On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. On WinMe the queue runner forked by the exim daemon still occasionally produces a popup indicating an error in Cygwin1.dll a popup indicating an error...? Not too helpful. It has happened once more, but differently. ps shows the child as defunct. Sysinternals shows everything normal, pinfo exists in the child. There is no fork failure, in fact the one I mentioned earlier is the only one out of 17070 runs. This time when I killed the daemon (just to see), I got 330495 [main] exim 34658275 proc_subproc: couldn't get proc lock. Something is wrong. 330520 [main] exim 34658275 proc_subproc: couldn't get proc lock. Something is wrong Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Please try the latest snapshot -- it is close to cygwin 1.5.6
Using a CVS Head version, I get a popup with:
The instruction at 0x61085fba referenced memory at 0x61002f90. The
memory could not be written
$ addr2line -e /bin/cygwin1.dll 61085fba
/src/cygwin/obj/obj-org/i686-pc-cygwin/winsup/cygwin/../../../../../src/
winsup/cygwin/shm.cc:331
/* Try allocating memory before calling cygserver. */
shm_shmid_list *ssh_new_entry = new (shm_shmid_list);
if (!ssh_new_entry)
{
set_errno (ENOMEM);
331 return -1;
}
I am not sure if this is helpful...
Trevor
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Thu, Dec 25, 2003 at 09:07:51AM +0930, Trevor Forbes wrote:
Using a CVS Head version, I get a popup with:
The instruction at 0x61085fba referenced memory at 0x61002f90. The
memory could not be written
$ addr2line -e /bin/cygwin1.dll 61085fba
/src/cygwin/obj/obj-org/i686-pc-cygwin/winsup/cygwin/../../../../../src/
winsup/cygwin/shm.cc:331
/* Try allocating memory before calling cygserver. */ shm_shmid_list
*ssh_new_entry = new (shm_shmid_list); if (!ssh_new_entry) { set_errno
(ENOMEM);
331 return -1;
}
I am not sure if this is helpful...
You get a popup with WHAT? Every single cygwin program?
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Please try the latest snapshot -- it is close to cygwin 1.5.6
I was running the open_posix_testsuite against the current homebuilt cygwin1.dll but I get the same error if I use the new dll to build itself. It only happens randomly to gcc.exe but it always errors at the same location 0x61085fba. I run the testsuite when I built the dll which gives: FAIL: msgtest.c (execute) FAIL: semtest.c (execute) FAIL: shmtest.c (execute) FAIL: pthread/mainthreadexits.c (execute) === winsup Summary === # of expected passes259 # of unexpected failures4 # of expected failures 14 The pthread test is the only abnormal failure as I am not using the cygserver. I looked at the mainthreadexits.c test and I was not sure if the test was correct. So that's what lead me to try out the open_posix_testsuite. I am currently Googling for different debugging methods and contemplating having a Xmas drink or two. I tried the how-to-debug-cygwin.txt but GDB did not provide any useful information. Sorry I am not more helpful. Merry Xmas to all. Trevor -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Tue, 23 Dec 2003, Christopher Faylor wrote: The subject says it all. I'm hoping to release cygwin 1.5.6 shortly after Christmas. Have you run the testsuite lately? I get a heap of failures on NT4. But, in that timeframe, I certainly won't have time to look at them. lots of child process exited abnormally errors. Just FYI. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Tue, Dec 23, 2003 at 04:39:13PM -0600, Brian Ford wrote: Have you run the testsuite lately? I get a heap of failures on NT4. But, in that timeframe, I certainly won't have time to look at them. You can safely assume that cygwin is not released without my running the test suite. I haven't run it in the last couple of days, though. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Tue, 23 Dec 2003, Christopher Faylor wrote: On Tue, Dec 23, 2003 at 04:39:13PM -0600, Brian Ford wrote: Have you run the testsuite lately? I get a heap of failures on NT4. But, in that timeframe, I certainly won't have time to look at them. You can safely assume that cygwin is not released without my running the test suite. I haven't run it in the last couple of days, though. I figured as much on both counts. FWIW, I didn't have your latest fork.c change. I am testing again now, but probably won't have the results before I need to leave. All, have a good holiday. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
On Tue, Dec 23, 2003 at 04:45:27PM -0600, Brian Ford wrote: On Tue, 23 Dec 2003, Christopher Faylor wrote: On Tue, Dec 23, 2003 at 04:39:13PM -0600, Brian Ford wrote: Have you run the testsuite lately? I get a heap of failures on NT4. But, in that timeframe, I certainly won't have time to look at them. You can safely assume that cygwin is not released without my running the test suite. I haven't run it in the last couple of days, though. I figured as much on both counts. Did you figure that I was setting things up to run the test suite when your email came in? I was basically hoping for some more real world success or failures like rsync doesn't work or rxvt works fine. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please try the latest snapshot
Christopher Faylor wrote: The latest snapshot should fix some /etc handling problems (thanks to ideas and code from Pierre Humblet), like the dreaded BSOD. It may also solve the pipes are slow problem. There are also all of the fixes accumulated since 1.3.18, of course. Indeed it does seem to stop the BSODding on my machines. Thanks! /dan -- 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/
Re: please try the latest snapshot
Chris, On Fri, Jan 17, 2003 at 12:52:16AM -0500, Christopher Faylor wrote: If I don't hear too many whines about this snapshot, it may become 1.3.19. The 2003-Jan-17 snapshot seems to fix the symlink problem that I mentioned in: http://cygwin.com/ml/cygwin/2003-01/msg00827.html However, sshd is failing with the following in sshd.log: C:\cygwin\usr\sbin\sshd.exe: *** internal error I know that the above is not much to go on, but I thought that it was better to start whining sooner rather that later. :,) I will try to dig deeper. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Re: please try the latest snapshot
Dan Holmsand wrote: Indeed it does seem to stop the BSODding on my machines. Thanks! Still no BSOD. However, now I'm having trouble with postgresql: the postmaster dies as soon as I exit psql. Reverting to a cygwin1.dll built from cvs from four days ago fixes the problem. Here is what the postmaster.log says: LOG: server process (pid 1440) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing shared memory and semaphores IpcMemoryCreate: shmget(key=5432001, size=1441792, 03600) failed: Not enough core This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 1441792 bytes), reduce PostgreSQL's shared_buffers parameter (currently 64) and/or its max_connections parameter (currently 32). The PostgreSQL Administrator's Guide contains more information about shared memory configuration. /dan -- 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/
Re: please try the latest snapshot
cgf == Christopher Faylor [EMAIL PROTECTED] writes: cgf The latest snapshot should fix some /etc handling problems cgf (thanks to ideas and code from Pierre Humblet), like the cgf dreaded BSOD. Where can I read more about that BSOD problem? I'm getting blue-screens myself and would like to see if the problem you fixed seems like the problem I've been having. -- PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5 C8BD 6337 0041 C01C 5276 -- 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/
Re: please try the latest snapshot
On Fri, Jan 17, 2003 at 10:44:55AM -0500, Jason Tishler wrote: Chris, On Fri, Jan 17, 2003 at 12:52:16AM -0500, Christopher Faylor wrote: If I don't hear too many whines about this snapshot, it may become 1.3.19. The 2003-Jan-17 snapshot seems to fix the symlink problem that I mentioned in: http://cygwin.com/ml/cygwin/2003-01/msg00827.html However, sshd is failing with the following in sshd.log: C:\cygwin\usr\sbin\sshd.exe: *** internal error I know that the above is not much to go on, but I thought that it was better to start whining sooner rather that later. :,) I will try to dig deeper. This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? cgf -- 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/
Re: please try the latest snapshot
Chris, On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote: This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? Looking good! Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
FindFirstChangeNotification BSODs (Re: please try the latest snapshot)
On Fri, Jan 17, 2003 at 12:52:16AM -0500, you [Christopher Faylor] wrote: The latest snapshot should fix some /etc handling problems (thanks to ideas and code from Pierre Humblet), like the dreaded BSOD. It may also solve the pipes are slow problem. There are also all of the fixes accumulated since 1.3.18, of course. If I don't hear too many whines about this snapshot, it may become 1.3.19. I've got a contact at Microsoft support who is listening about these BSOD issues (I was quite surprised they actually answered when I submitted a report on cygwin causing BSODs...). They are not quite keen on installing the whole cygwin suite (be it free or not), though. However, if some of you who have played with the /etc FindFirstChangeNotification stuff would have the time and patience to wrap up a small .exe (preferably with source of source) that reproduces the problem, I think they would be very interested (only and assumption based on the pretty good feedback I've gotten so far). I'm afraid I'm too busy and unversed to do that myself -- v -- [EMAIL PROTECTED] -- 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/
Re: please try the latest snapshot
Chris, On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote: On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote: This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? Looking good! I spoke too soon. I'm getting segmentation faults and stuff like the following by just running ls: $ uname -a CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown $ cd src/pgsql /home/jt/src/pgsql $ ls ... 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state (probably corrupted stack) Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Re: please try the latest snapshot
The latest 1-17 snapshot fixes the pipe problem for me. No other problems detected so far. Thanks! Christopher Faylor wrote: The latest snapshot should fix some /etc handling problems (thanks to ideas and code from Pierre Humblet), like the dreaded BSOD. It may also solve the pipes are slow problem. There are also all of the fixes accumulated since 1.3.18, of course. -- 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/
Re: please try the latest snapshot
I am encountering sporadic segmentation faults from tools like ls and find. Specifically, I was invoking find as a child process from Cygwin XEmacs, and it was getting a segmentation fault at different locations in my (somewhat deep) directory structure. After this started to occur, I started an rxvt window and when to the top of the directory structure and did an 'ls'. This also caused a segmentation fault. This does not happen all the time, even for that directory. Reverting back to 1.3.17 corrected the problem. I will be happy to provide any additional information if instructions for collecting the information is provided. Dave David Rothenberger wrote: The latest 1-17 snapshot fixes the pipe problem for me. No other problems detected so far. Thanks! Christopher Faylor wrote: The latest snapshot should fix some /etc handling problems (thanks to ideas and code from Pierre Humblet), like the dreaded BSOD. It may also solve the pipes are slow problem. There are also all of the fixes accumulated since 1.3.18, of course. -- 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/
Re: please try the latest snapshot
On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote: Chris, On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote: On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote: This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? Looking good! I spoke too soon. I'm getting segmentation faults and stuff like the following by just running ls: $ uname -a CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown $ cd src/pgsql /home/jt/src/pgsql $ ls ... 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state (probably corrupted stack) Could you get a gdb backtrace of this problem? cgf -- 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/
Re: please try the latest snapshot
On Fri, Jan 17, 2003 at 08:04:43PM -0500, Christopher Faylor wrote: On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote: Chris, On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote: On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote: This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? Looking good! I spoke too soon. I'm getting segmentation faults and stuff like the following by just running ls: $ uname -a CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown $ cd src/pgsql /home/jt/src/pgsql $ ls ... 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state (probably corrupted stack) Could you get a gdb backtrace of this problem? Nevermind. I cd'ed around my disk like crazy until I could duplicate the problem. I'm regenerating the snapshot now. If it has this in the ChangeLog: 2003-01-17 Christopher Faylor [EMAIL PROTECTED] * cygheap.cc: Change most 'int's to 'unsigned's. (_cmalloc): Only check for size of malloced region when calculating budget. Add overhead when performing the sbrk. Previous change broke _crealloc. It should work. cgf -- 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/
RE: please try the latest snapshot
It works. I can now proceed with my progrect(Making music with Cygwin, EZPNO, and Timidity++ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Faylor Sent: Friday, January 17, 2003 9:39 PM To: [EMAIL PROTECTED] Subject: Re: please try the latest snapshot On Fri, Jan 17, 2003 at 08:04:43PM -0500, Christopher Faylor wrote: On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote: Chris, On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote: On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote: This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? Looking good! I spoke too soon. I'm getting segmentation faults and stuff like the following by just running ls: $ uname -a CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown $ cd src/pgsql /home/jt/src/pgsql $ ls ... 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state (probably corrupted stack) Could you get a gdb backtrace of this problem? Nevermind. I cd'ed around my disk like crazy until I could duplicate the problem. I'm regenerating the snapshot now. If it has this in the ChangeLog: 2003-01-17 Christopher Faylor [EMAIL PROTECTED] * cygheap.cc: Change most 'int's to 'unsigned's. (_cmalloc): Only check for size of malloced region when calculating budget. Add overhead when performing the sbrk. Previous change broke _crealloc. It should work. cgf -- 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/ -- 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/
Re: please try the latest snapshot
It does fix the slow pipes on my machine when seti@home is running. - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 4:52 PM Subject: please try the latest snapshot The latest snapshot should fix some /etc handling problems (thanks to ideas and code from Pierre Humblet), like the dreaded BSOD. It may also solve the pipes are slow problem. There are also all of the fixes accumulated since 1.3.18, of course. If I don't hear too many whines about this snapshot, it may become 1.3.19. cgf -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- 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/ -- 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/
Re: please try the latest snapshot
On Fri, Jan 17, 2003 at 05:54:57PM +1100, Eugene Rosenzweig wrote: It does fix the slow pipes on my machine when seti@home is running. Ok, thanks. If this is true to form, the next message will be from someone who indicates that the snapshot either shows no change or makes things worse. cgf -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- 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/
