Re: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
Is your keyboard symbol correctly set at the startxwin.sh log? -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
Oh, well, I thought that needed to be a 1 lines program. :-)
Anyway, indeed gdb does pop up for the sample program but doesn't so for
the real crashes. Bad luck.
Regards,
Kiyo
Christopher Faylor wrote:
On Fri, Jul 28, 2006 at 08:35:15PM +1000, Kiyo Kelvin Lee wrote:
I am quite sure I am doing that correctly.
I have checked all cygwin processes using System Explorer (from System
Internals) and they all are having the suggested CYGWIN setting.
BTW, is there any way to test if the setting is really effectively?
Say, is there any intentionally broken program which would activate the
setting?
Write a program which SEGVs, something like:
int
main (int argc, char **argv)
{
int *i = (int *) 0;
*i = 27;
}
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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
I am quite sure I am doing that correctly. I have checked all cygwin processes using System Explorer (from System Internals) and they all are having the suggested CYGWIN setting. BTW, is there any way to test if the setting is really effectively? Say, is there any intentionally broken program which would activate the setting? Regards, Kiyo Christopher Faylor wrote: On Thu, Jul 27, 2006 at 05:55:55PM +1000, Kiyo Kelvin Lee wrote: At least not for me. See my another post in this thread. Both 1.5.21 and snapshot 20060718 do not help. And I have the feeling that crashes happen more often with 1.5.21. Great to hear that I am not alone having the problem. I'm still not sure why CYGWIN=error_start isn't working. I have a feeling that when you set CYGWIN=error_start, you are not doing this prior to running any Cygwin process, i.e., X. You need to set the CYGWIN environment variable outside of Cygwin. Were you doing that? cgf O.D. -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
Larry Hall (Cygwin reply-to-list-only-lh at cygwin.com writes: Does 1.5.21 help? Updating to 1.5.12 doesn't seem to help. -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
Jon Harrison jon.harrison at selex-sas.com writes: Updating to 1.5.12 doesn't seem to help. Sorry, finger trouble: meant 5.1.21 -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
Jon Harrison jon.harrison at selex-sas.com writes: Updating to 1.5.12 doesn't seem to help. Sorry, finger trouble: meant 5.1.21 Wow, this thing will take at least another 42 years to fix! ;) Erik -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
On Fri, Jul 28, 2006 at 08:35:15PM +1000, Kiyo Kelvin Lee wrote:
I am quite sure I am doing that correctly.
I have checked all cygwin processes using System Explorer (from System
Internals) and they all are having the suggested CYGWIN setting.
BTW, is there any way to test if the setting is really effectively?
Say, is there any intentionally broken program which would activate the
setting?
Write a program which SEGVs, something like:
int
main (int argc, char **argv)
{
int *i = (int *) 0;
*i = 27;
}
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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
At least not for me. See my another post in this thread. Both 1.5.21 and snapshot 20060718 do not help. And I have the feeling that crashes happen more often with 1.5.21. Great to hear that I am not alone having the problem. Regards, Kiyo Larry Hall (Cygwin) wrote: Jon Harrison wrote: Hi, I too have been experiencing the same sort of psuedo random crash of sh.exe/bash.exe when running any form of shell script. Again, other than the irritation of the Windoze Application Error it appears that the scripts have worked I'd have a hard time putting any kind of pattern to the failure, seem to happen whether plain dos/cygwin shell or under X. Does 1.5.21 help? -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
On Thu, Jul 27, 2006 at 05:55:55PM +1000, Kiyo Kelvin Lee wrote: At least not for me. See my another post in this thread. Both 1.5.21 and snapshot 20060718 do not help. And I have the feeling that crashes happen more often with 1.5.21. Great to hear that I am not alone having the problem. I'm still not sure why CYGWIN=error_start isn't working. I have a feeling that when you set CYGWIN=error_start, you are not doing this prior to running any Cygwin process, i.e., X. You need to set the CYGWIN environment variable outside of Cygwin. Were you doing that? cgf O.D. -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
Jon Harrison wrote: Hi, I too have been experiencing the same sort of psuedo random crash of sh.exe/bash.exe when running any form of shell script. Again, other than the irritation of the Windoze Application Error it appears that the scripts have worked I'd have a hard time putting any kind of pattern to the failure, seem to happen whether plain dos/cygwin shell or under X. Does 1.5.21 help? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
Now it seems the crashes are relating to another problem reported earlier: 1.5.20: Occasionally infinite loop happens in do_exit() (dcrt0.cc) (see attached original text below) I managed to make sure the infinite loop had not happened (more about that later) and then tested to run configure for squid-2.6 multiple times (ran for 2 hours) and was unable to reproduce a single crash. So I am guessing the infinite loop and hence explicitly killing the offending process would leave cygwin in some funny state and lead to those crashes. The infinite loop problem happened fairly often whenever I started X Windows. And I basically did all the tests inside xterm, i.e. always after an infinite loop had happened. I started to notice the potential relationship when I had successfully run configure for squid-2.6 without any crash inside just bash with no X Windows running at the time. And I notice the infinite loop problem seems to be relating epist, a utility comes with and for openbox 2.3.1 which I built myself and use as the windows manager. (Note that the official cygwin openbox is still of version 0.99) Once I have removed epist from starting in xinitrc, the infinite loop problem no longer happens and that allows me to do the test above. As to why I wondered that epist is part of the problem is that there is a strange characteristic about it. That is the process is not listed with ps or procps or even ps -W (as a Windows process) but indeed it is running and functional. (Unbelievable?) It is still shown in Task Manager of course but just like invisible inside cygwin. And it won't be killed automatically upon terminating X Windows. I need to kill it explicitly after terminated X Windows. If this is not complicated enough, I have to mention openbox 2.3.1 cannot be built by default on cygwin as it requires gcc-2.95. So I have to fix it to support gcc-3.4.4, the current official cygwin gcc, and tweak Makefiles after configure (to link to Xft, fontconfig, iconv) to build. If you would like to test all these (I'd be very grateful if you do so), you may like to take my attached patch for openbox 2.3.1. Regards, Kiyo ### Problem reported earlier ### 1.5.20: Occasionally infinite loop happens in do_exit() (dcrt0.cc) == Using 1.5.20-1 on Windows XP, occasionally a process would become consuming all CPU cycles (90+%) upon termination. Tested snapshot 20060707 and the problem persists. I debugged into the process using msdev and found the attached stack trace. The infinite loop is inside ntdll. 0x61004b4c is the last address in cygwin1 which has never been get back to. BTW, the address corresponding to line 1113 of dcrt0.cc (snapshot 20060707) function do_exit() at the line: cygwin_shared-tty.terminate(); So look very much like a problem I reported before for 1.5.19-4. But that one was constantly reproducible with running gvim in diff mode. And that problem has been gone with 1.5.20-1. Now, the infinite loop problem happens more unpredictably and just occasionally. -- Christopher Faylor wrote: On Wed, Jul 19, 2006 at 05:30:05PM +1000, Kiyo Kelvin Lee wrote: Actually, I have 2 systems (one XP [AMD Athlon 64 3500] and one Win2K [Celeron 900]) both have the same problem and attached are the cygcheck output. My sh.exe is bash.exe. The crashes happen just sparsely and not upon all processes termination. When I ran, say, configure for openbox-2, I always got at least a few crashes but the configure procedure should have already ran hundreds of processes. Note the crashes did not seem to affect the configure procedure and configure finished just normally. I tried to debug bash and get the stack trace with no success. The crashing dialog is like attached to a ghost process. Click on CANCEL does not start msdev.exe as the debugger. Running msdev wouldn't be very interesting anyway. Possibly setting CYGWIN=error_start=c:/cygwin/bin/gdb.exe might cause gdb to pop up, however. Also tried to attach to a bash using gdb before running configure, the crashes still happen but gdb just couldn't catch anything, the bash just kept running (inside gdb). I'm not sure what this means. If bash kept running then that would indicate that it isn't the bash which is crashing. Possibly a forked cgf copy is crashing. diff -C3 -r openbox-2.3.1/configure openbox-2.3.1-p1/configure *** openbox-2.3.1/configure Thu Apr 10 13:53:56 2003 --- openbox-2.3.1-p1/configure Thu Jul 6 11:52:09 2006 *** *** 1449,1454 --- 1449,1455 program_transform_name=s,\$,$program_suffix,;$program_transform_name # Double any \ or $. echo might interpret backslashes. # By default was `s,x,x', remove it if useless. + program_transform_name_sh=`echo $program_transform_name | sed 's/;s,x,x,$//'` cat \_ACEOF conftest.sed s/[\\$]//g;s/;s,x,x,$//
Re: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
On Sun, Jul 23, 2006 at 03:55:05AM +1000, Kiyo Kelvin Lee wrote: Now it seems the crashes are relating to another problem reported earlier: 1.5.20: Occasionally infinite loop happens in do_exit() (dcrt0.cc) (see attached original text below) I managed to make sure the infinite loop had not happened (more about that later) and then tested to run configure for squid-2.6 multiple times (ran for 2 hours) and was unable to reproduce a single crash. So I am guessing the infinite loop and hence explicitly killing the offending process would leave cygwin in some funny state and lead to those crashes. If you can reproduce the crash with the latest snapshot then please try including error_start:c:/cygwin/bin/gdb.exe in your CYGWIN environment variable as I previously suggested. This must be used before you start any other CYGWIN processes. If it works, then it should be fairly easy to see what the state of cygwin is when the crash occurs. FWIW, the loop in tty::terminate was reported as fixed in the latest snapshot. 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
I'm not sure what this means. If bash kept running then that would indicate that it isn't the bash which is crashing. Possibly a forked cgf copy is crashing. There are copies of cgf that fork? Actually, that explains an awful lot. Ant. ___ All New Yahoo! Mail Tired of [EMAIL PROTECTED]@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html -- 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: 1.5.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthre
On Wed, Jul 19, 2006 at 05:30:05PM +1000, Kiyo Kelvin Lee wrote: Actually, I have 2 systems (one XP [AMD Athlon 64 3500] and one Win2K [Celeron 900]) both have the same problem and attached are the cygcheck output. My sh.exe is bash.exe. The crashes happen just sparsely and not upon all processes termination. When I ran, say, configure for openbox-2, I always got at least a few crashes but the configure procedure should have already ran hundreds of processes. Note the crashes did not seem to affect the configure procedure and configure finished just normally. I tried to debug bash and get the stack trace with no success. The crashing dialog is like attached to a ghost process. Click on CANCEL does not start msdev.exe as the debugger. Running msdev wouldn't be very interesting anyway. Possibly setting CYGWIN=error_start=c:/cygwin/bin/gdb.exe might cause gdb to pop up, however. Also tried to attach to a bash using gdb before running configure, the crashes still happen but gdb just couldn't catch anything, the bash just kept running (inside gdb). I'm not sure what this means. If bash kept running then that would indicate that it isn't the bash which is crashing. Possibly a forked cgf copy is crashing. -- 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/
