crash on latest cygwin snapshot

crash on latest cygwin snapshot

[marco atzeri]

Cgf, Corinna,

while building latest atlas  I hit a bug that is crashing all the 
running cygwin process.
It crashes on 20120619 snapshot and also latest cvs source.
No issue on 20120611 snapshot.

The binary to replicate and a extract of the strace's is at
http://matzeri.altervista.org/works/atlas/

on W7/64 just run this command
---------------------------------------------------------------------
  ./xprobe_comp -v 2 -o atlconf.txt -O 9 -A 25 -Si nof77 0 -V 448  -Fa 
ic '-fno-common' -Fa sm '-fno-common' -Fa dm '-fno-common' -Fa sk 
'-fno-common' -Fa dk '-fno-common' -Fa xc '-fno-common' -Fa gc 
'-fno-common' -Fa if '-fno-common' -b 32 -d b .
----------------------------------------------------------------------

no stackdump is generated.

Regards
Marco


--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Sun, Jun 24, 2012 at 11:30:02PM +0200, marco atzeri wrote:
>Cgf, Corinna,
>
>while building latest atlas  I hit a bug that is crashing all the 
>running cygwin process.
>It crashes on 20120619 snapshot and also latest cvs source.
>No issue on 20120611 snapshot.
>
>The binary to replicate and a extract of the strace's is at
>http://matzeri.altervista.org/works/atlas/
>
>on W7/64 just run this command
>---------------------------------------------------------------------
>  ./xprobe_comp -v 2 -o atlconf.txt -O 9 -A 25 -Si nof77 0 -V 448  -Fa 
>ic '-fno-common' -Fa sm '-fno-common' -Fa dm '-fno-common' -Fa sk 
>'-fno-common' -Fa dk '-fno-common' -Fa xc '-fno-common' -Fa gc 
>'-fno-common' -Fa if '-fno-common' -b 32 -d b .
>----------------------------------------------------------------------
>
>no stackdump is generated.

I think I need a better test case.

No matter what DLL I use, if I put the above in a shell script (adding a
'\' to the end of each line) and execute it, I get the below output and
my process table fills up /usr/bin/sh processes.

If I reduce my PATH to just /usr/bin, the xprobe_comp sits there and I
get lots and lots of /usr/bin/sh processes showing up in ps output and
eventually I have to power-cycle my system to recover.

cgf

The script:

#!/bin/sh
./xprobe_comp -v 2 -o atlconf.txt -O 9 -A 25 -Si nof77 0 -V 448  -Fa \
ic '-fno-common' -Fa sm '-fno-common' -Fa dm '-fno-common' -Fa sk \
'-fno-common' -Fa dk '-fno-common' -Fa xc '-fno-common' -Fa gc \
'-fno-common' -Fa if '-fno-common' -b 32 -d b .

The output:

User Override Compilers:
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'

sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `find $HOME/local /cygdrive/c/Program\ Files\ (x86)/PC\ Connectivity\ Solution /cygdrive/c/Program\
 Files\ (x86)/NVIDIA\ Corporation/PhysX/Common /cygdrive/c/Program\ Files/Common\ Files/Microsoft\ Shared/Windows\
Live /cygdrive/c/Program\ Files\ (x86)/Common\ Files/Microsoft\ Shared/Windows\ Live /usr/bin /usr/local/bin /cygdr
ive/c/Windows/system32 /cygdrive/c/Windows /cygdrive/c/Windows/System32/Wbem /cygdrive/c/Windows/System32/WindowsPo
werShell/v1.0 /cygdrive/c/Program\ Files\ (x86)/Windows\ Live/Shared /cygdrive/c/Program\ Files/WIDCOMM/Bluetooth\
Software /cygdrive/c/Program\ Files/WIDCOMM/Bluetooth\ Software/syswow64 /cygdrive/c/Program\ Files\ (x86)/software
.jessies.org/terminator/Resources/terminator/bin -name '*gcc*' -exec ./xisgcc '{}' \; > /tmp/t4580.0 2>&1'

ierr=256 in command='find $HOME/local /cygdrive/c/Program\ Files\ (x86)/PC\ Connectivity\ Solution /cygdrive/c/Prog
ram\ Files\ (x86)/NVIDIA\ Corporation/PhysX/Common /cygdrive/c/Program\ Files/Common\ Files/Microsoft\ Shared/Windo
ws\ Live /cygdrive/c/Program\ Files\ (x86)/Common\ Files/Microsoft\ Shared/Windows\ Live /usr/bin /usr/local/bin /c
ygdrive/c/Windows/system32 /cygdrive/c/Windows /cygdrive/c/Windows/System32/Wbem /cygdrive/c/Windows/System32/Windo
wsPowerShell/v1.0 /cygdrive/c/Program\ Files\ (x86)/Windows\ Live/Shared /cygdrive/c/Program\ Files/WIDCOMM/Bluetoo
th\ Software /cygdrive/c/Program\ Files/WIDCOMM/Bluetooth\ Software/syswow64 /cygdrive/c/Program\ Files\ (x86)/soft
ware.jessies.org/terminator/Resources/terminator/bin -name '*gcc*' -exec ./xisgcc '{}' \;'!

OUTPUT:
=======
cat: /tmp/t4580.0: No such file or directory

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/25/2012 6:31 AM, Christopher Faylor wrote:
> On Sun, Jun 24, 2012 at 11:30:02PM +0200, marco atzeri wrote:
>> Cgf, Corinna,
>>
>> while building latest atlas  I hit a bug that is crashing all the
>> running cygwin process.
>> It crashes on 20120619 snapshot and also latest cvs source.
>> No issue on 20120611 snapshot.
>>
>> The binary to replicate and a extract of the strace's is at
>> http://matzeri.altervista.org/works/atlas/
>>
>> on W7/64 just run this command
>> ---------------------------------------------------------------------
>>   ./xprobe_comp -v 2 -o atlconf.txt -O 9 -A 25 -Si nof77 0 -V 448  -Fa
>> ic '-fno-common' -Fa sm '-fno-common' -Fa dm '-fno-common' -Fa sk
>> '-fno-common' -Fa dk '-fno-common' -Fa xc '-fno-common' -Fa gc
>> '-fno-common' -Fa if '-fno-common' -b 32 -d b .
>> ----------------------------------------------------------------------
>>
>> no stackdump is generated.
>
> I think I need a better test case.

I was afraid of that.
xprobe_comp is a sytem/processor probe and it is really
resource consuming during its normal run.

I tried to strace but it produces an enormous amount of data

$ ls -sh1  xprobe_comp.strace*
330M xprobe_comp.strace_fail
761M xprobe_comp.strace_good

and there is no guarantee that the root cause is traced.
>
> No matter what DLL I use, if I put the above in a shell script (adding a
> '\' to the end of each line) and execute it, I get the below output and
> my process table fills up /usr/bin/sh processes.
>
> If I reduce my PATH to just /usr/bin, the xprobe_comp sits there and I
> get lots and lots of /usr/bin/sh processes showing up in ps output and
> eventually I have to power-cycle my system to recover.
>
> cgf
>
> The script:
>
> #!/bin/sh
> ./xprobe_comp -v 2 -o atlconf.txt -O 9 -A 25 -Si nof77 0 -V 448  -Fa \
> ic '-fno-common' -Fa sm '-fno-common' -Fa dm '-fno-common' -Fa sk \
> '-fno-common' -Fa dk '-fno-common' -Fa xc '-fno-common' -Fa gc \
> '-fno-common' -Fa if '-fno-common' -b 32 -d b .
>
> The output:
>
> User Override Compilers:
>     'none' : 'none' '-fno-common'
>     'none' : 'none' '-fno-common'
>     'none' : 'none' '-fno-common'
>     'none' : 'none' '-fno-common'
>     'none' : 'none' '-fno-common'
>     'none' : 'none' '-fno-common'
>     'none' : 'none' '-fno-common'
>     'none' : 'none' '-fno-common'

for what I see on my log, it crash after that
and before of:

>
> sh: -c: line 0: syntax error near unexpected token `('
> sh: -c: line 0: `find $HOME/local /cygdrive/c/Program\ Files\ (x86)/PC\ Connectivity\ Solution /cygdrive/c/Program\
>   Files\ (x86)/NVIDIA\ Corporation/PhysX/Common /cygdrive/c/Program\ Files/Common\ Files/Microsoft\ Shared/Windows\
> Live /cygdrive/c/Program\ Files\ (x86)/Common\ Files/Microsoft\ Shared/Windows\ Live /usr/bin /usr/local/bin /cygdr
> ive/c/Windows/system32 /cygdrive/c/Windows /cygdrive/c/Windows/System32/Wbem /cygdrive/c/Windows/System32/WindowsPo
> werShell/v1.0 /cygdrive/c/Program\ Files\ (x86)/Windows\ Live/Shared /cygdrive/c/Program\ Files/WIDCOMM/Bluetooth\
> Software /cygdrive/c/Program\ Files/WIDCOMM/Bluetooth\ Software/syswow64 /cygdrive/c/Program\ Files\ (x86)/software
> .jessies.org/terminator/Resources/terminator/bin -name '*gcc*' -exec ./xisgcc '{}' \; > /tmp/t4580.0 2>&1'
>
> ierr=256 in command='find $HOME/local /cygdrive/c/Program\ Files\ (x86)/PC\ Connectivity\ Solution /cygdrive/c/Prog
> ram\ Files\ (x86)/NVIDIA\ Corporation/PhysX/Common /cygdrive/c/Program\ Files/Common\ Files/Microsoft\ Shared/Windo
> ws\ Live /cygdrive/c/Program\ Files\ (x86)/Common\ Files/Microsoft\ Shared/Windows\ Live /usr/bin /usr/local/bin /c
> ygdrive/c/Windows/system32 /cygdrive/c/Windows /cygdrive/c/Windows/System32/Wbem /cygdrive/c/Windows/System32/Windo
> wsPowerShell/v1.0 /cygdrive/c/Program\ Files\ (x86)/Windows\ Live/Shared /cygdrive/c/Program\ Files/WIDCOMM/Bluetoo
> th\ Software /cygdrive/c/Program\ Files/WIDCOMM/Bluetooth\ Software/syswow64 /cygdrive/c/Program\ Files\ (x86)/soft
> ware.jessies.org/terminator/Resources/terminator/bin -name '*gcc*' -exec ./xisgcc '{}' \;'!
>
> OUTPUT:
> =======
> cat: /tmp/t4580.0: No such file or directory
>

--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Jun 25 09:34, marco atzeri wrote:
> On 6/25/2012 6:31 AM, Christopher Faylor wrote:
> >On Sun, Jun 24, 2012 at 11:30:02PM +0200, marco atzeri wrote:
> >>Cgf, Corinna,
> >>
> >>while building latest atlas  I hit a bug that is crashing all the
> >>running cygwin process.
> >>It crashes on 20120619 snapshot and also latest cvs source.
> >>No issue on 20120611 snapshot.
> >>
> >>The binary to replicate and a extract of the strace's is at
> >>http://matzeri.altervista.org/works/atlas/
> >>
> >>on W7/64 just run this command
> >>---------------------------------------------------------------------
> >>  ./xprobe_comp -v 2 -o atlconf.txt -O 9 -A 25 -Si nof77 0 -V 448  -Fa
> >>ic '-fno-common' -Fa sm '-fno-common' -Fa dm '-fno-common' -Fa sk
> >>'-fno-common' -Fa dk '-fno-common' -Fa xc '-fno-common' -Fa gc
> >>'-fno-common' -Fa if '-fno-common' -b 32 -d b .
> >>----------------------------------------------------------------------
> >>
> >>no stackdump is generated.
> >
> >I think I need a better test case.
> 
> I was afraid of that.
> xprobe_comp is a sytem/processor probe and it is really
> resource consuming during its normal run.
> 
> I tried to strace but it produces an enormous amount of data
> 
> $ ls -sh1  xprobe_comp.strace*
> 330M xprobe_comp.strace_fail
> 761M xprobe_comp.strace_good
> 
> and there is no guarantee that the root cause is traced.

Does the failing strace contain a line like this?

  --- Process 3708, exception C0000094 at 00401198

If so, it might give a clue.  There's a chance that an exception
generates another exception, so you might have more than one such
line.  The first one rules.  Did you try from CVS again with cgf's
latest patch?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/25/2012 10:05 AM, Corinna Vinschen wrote:
> On Jun 25 09:34, marco atzeri wrote:
>> On 6/25/2012 6:31 AM, Christopher Faylor wrote:
>>> On Sun, Jun 24, 2012 at 11:30:02PM +0200, marco atzeri wrote:
>>>> Cgf, Corinna,
>>>>
>>>> while building latest atlas  I hit a bug that is crashing all the
>>>> running cygwin process.
>>>> It crashes on 20120619 snapshot and also latest cvs source.
>>>> No issue on 20120611 snapshot.
>>>>
>>>> The binary to replicate and a extract of the strace's is at
>>>> http://matzeri.altervista.org/works/atlas/
>>>>
>>>> on W7/64 just run this command
>>>> ---------------------------------------------------------------------
>>>>   ./xprobe_comp -v 2 -o atlconf.txt -O 9 -A 25 -Si nof77 0 -V 448  -Fa
>>>> ic '-fno-common' -Fa sm '-fno-common' -Fa dm '-fno-common' -Fa sk
>>>> '-fno-common' -Fa dk '-fno-common' -Fa xc '-fno-common' -Fa gc
>>>> '-fno-common' -Fa if '-fno-common' -b 32 -d b .
>>>> ----------------------------------------------------------------------
>>>>
>>>> no stackdump is generated.
>>>
>>> I think I need a better test case.
>>
>> I was afraid of that.
>> xprobe_comp is a sytem/processor probe and it is really
>> resource consuming during its normal run.
>>
>> I tried to strace but it produces an enormous amount of data
>>
>> $ ls -sh1  xprobe_comp.strace*
>> 330M xprobe_comp.strace_fail
>> 761M xprobe_comp.strace_good
>>
>> and there is no guarantee that the root cause is traced.
>
> Does the failing strace contain a line like this?
>
>    --- Process 3708, exception C0000094 at 00401198
>
> If so, it might give a clue.  There's a chance that an exception
> generates another exception, so you might have more than one such
> line.  The first one rules.  Did you try from CVS again with cgf's
> latest patch?
>
>
> Corinna
>

Hi Corinna,
Tested up to
http://cygwin.com/ml/cygwin-cvs/2012-q2/msg00129.html

There are no exceptions on the strace.

The last portion, ~ 500 lines, of strace is available here:
http://matzeri.altervista.org/works/atlas/

together with the equivalent area of the good strace (~ 1000 lines).

A normal exception should kill just the running process, while
I see that  xprobe_comp, bash, mintty are killed and
also others bash and mintty processes are taking down.

Regards
Marco



--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Jun 25 10:37, marco atzeri wrote:
> On 6/25/2012 10:05 AM, Corinna Vinschen wrote:
> >On Jun 25 09:34, marco atzeri wrote:
> >>I tried to strace but it produces an enormous amount of data
> >>
> >>$ ls -sh1  xprobe_comp.strace*
> >>330M xprobe_comp.strace_fail
> >>761M xprobe_comp.strace_good
> >>
> >>and there is no guarantee that the root cause is traced.
> >
> >Does the failing strace contain a line like this?
> >
> >   --- Process 3708, exception C0000094 at 00401198
> >
> >If so, it might give a clue.  There's a chance that an exception
> >generates another exception, so you might have more than one such
> >line.  The first one rules.  Did you try from CVS again with cgf's
> >latest patch?
> >
> >
> >Corinna
> >
> 
> Hi Corinna,
> Tested up to
> http://cygwin.com/ml/cygwin-cvs/2012-q2/msg00129.html

What about http://cygwin.com/ml/cygwin-cvs/2012-q2/msg00130.html ?

> There are no exceptions on the strace.
> 
> The last portion, ~ 500 lines, of strace is available here:
> http://matzeri.altervista.org/works/atlas/
> 
> together with the equivalent area of the good strace (~ 1000 lines).
> 
> A normal exception should kill just the running process, while
> I see that  xprobe_comp, bash, mintty are killed and
> also others bash and mintty processes are taking down.

Really all processes or just all processes in the same terminal window?
If it's the latter, the problem may be triggered by xprobe_comp, but
it would really occur in mintty.  Here's an interesting snippet from the
failing strace:

  414 195741371 [main] xprobe_comp 1084 fhandler_pty_slave::write: pty0, write(40B7E7, 6)
   47 195741418 [main] xprobe_comp 1084 fhandler_pty_slave::write: (648): pty output_mutex (0xCC): waiting -1 ms
   46 195741464 [main] xprobe_comp 1084 fhandler_pty_slave::write: (648): pty output_mutex: acquired
   50 195741514 [main] xprobe_comp 1084 fhandler_pty_slave::write: WriteFile failed, Win32 error 232
   45 195741559 [main] xprobe_comp 1084 seterrno_from_win_error: /pub/cygwin/cvs/src_new/winsup/cygwin/fhandler_tty.cc:676 windows error 1117
   47 195741606 [main] xprobe_comp 1084 geterrno_from_win_error: windows error 1117 == errno 5

So a WriteFile to the slave side of the pty returns with ERROR_NO_DATA
which means the pipe has been closed on the other end.  The other end is
the master, which should be mintty here.  The strace doesn't cover
mintty so there's no way to see what happens in there.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/25/2012 11:00 AM, Corinna Vinschen wrote:
> On Jun 25 10:37, marco atzeri wrote:
>>
>> A normal exception should kill just the running process, while
>> I see that  xprobe_comp, bash, mintty are killed and
>> also others bash and mintty processes are taking down.
>
> Really all processes or just all processes in the same terminal window?

all processes in all the available terminal windows.
3 mintty and 3 bash are taken down and they were indepedently
created by the start menu

>
> Corinna
>

I will check if today cgf's changeset make any difference

Regards
Marco



--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/25/2012 11:36 AM, marco atzeri wrote:
> On 6/25/2012 11:00 AM, Corinna Vinschen wrote:
>> On Jun 25 10:37, marco atzeri wrote:
>>>
>>> A normal exception should kill just the running process, while
>>> I see that  xprobe_comp, bash, mintty are killed and
>>> also others bash and mintty processes are taking down.
>>
>> Really all processes or just all processes in the same terminal window?
>
> all processes in all the available terminal windows.
> 3 mintty and 3 bash are taken down and they were indepedently
> created by the start menu
>
>>
>> Corinna
>>
>
> I will check if today cgf's changeset make any difference
>
> Regards
> Marco
>
>
hi Corinna,
no difference. It takes down everything

but you are right about mintty, it is crashing and the stackdump
are located at c:\windows\SySWOW64, I only noticed with procmon.

---------------------------------------------------------------------
Exception: STATUS_ACCESS_VIOLATION at eip=610CE726
eax=610CE710 ebx=0000010C ecx=777B0000 edx=0008E3C8 esi=0028A5B8 
edi=8005A088
ebp=0028A468 esp=0028A450 program=E:\cygwin\bin\mintty.exe, pid 6652, 
thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0028A468  610CE726  (8004EF58, 0028A5B8, E65DA9C7, 231FFA3E)
0028A488  610D05CE  (0028A5B8, 0028A648, 0028A540, 0028A520)
0028A618  610D146A  (00000002, 0028A648, 0028A540, 0028A520)
24479433 [main] mintty 6652 exception::handle: Exception: 
STATUS_ACCESS_VIOLATION
24495658 [main] mintty 6652 exception::handle: Error while dumping state 
(probably corrupted stack)
----------------------------------------------------------------------

$ addr2line.exe -e cygwin1.dll 610CE726
/pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:687

$ addr2line.exe -e cygwin1.dll 610D05CE
/pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:243

$ addr2line.exe -e cygwin1.dll 610D146A
/pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:252

Regards
Marco



--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Mon, Jun 25, 2012 at 01:57:26PM +0200, marco atzeri wrote:
>On 6/25/2012 11:36 AM, marco atzeri wrote:
>> On 6/25/2012 11:00 AM, Corinna Vinschen wrote:
>>> On Jun 25 10:37, marco atzeri wrote:
>>>>
>>>> A normal exception should kill just the running process, while
>>>> I see that  xprobe_comp, bash, mintty are killed and
>>>> also others bash and mintty processes are taking down.
>>>
>>> Really all processes or just all processes in the same terminal window?
>>
>> all processes in all the available terminal windows.
>> 3 mintty and 3 bash are taken down and they were indepedently
>> created by the start menu
>>
>>>
>>> Corinna
>>>
>>
>> I will check if today cgf's changeset make any difference
>>
>> Regards
>> Marco
>>
>>
>hi Corinna,
>no difference. It takes down everything
>
>but you are right about mintty, it is crashing and the stackdump
>are located at c:\windows\SySWOW64, I only noticed with procmon.
>
>---------------------------------------------------------------------
>Exception: STATUS_ACCESS_VIOLATION at eip=610CE726
>eax=610CE710 ebx=0000010C ecx=777B0000 edx=0008E3C8 esi=0028A5B8 
>edi=8005A088
>ebp=0028A468 esp=0028A450 program=E:\cygwin\bin\mintty.exe, pid 6652, 
>thread main
>cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>Stack trace:
>Frame     Function  Args
>0028A468  610CE726  (8004EF58, 0028A5B8, E65DA9C7, 231FFA3E)
>0028A488  610D05CE  (0028A5B8, 0028A648, 0028A540, 0028A520)
>0028A618  610D146A  (00000002, 0028A648, 0028A540, 0028A520)
>24479433 [main] mintty 6652 exception::handle: Exception: 
>STATUS_ACCESS_VIOLATION
>24495658 [main] mintty 6652 exception::handle: Error while dumping state 
>(probably corrupted stack)
>----------------------------------------------------------------------
>
>$ addr2line.exe -e cygwin1.dll 610CE726
>/pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:687
>
>$ addr2line.exe -e cygwin1.dll 610D05CE
>/pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:243
>
>$ addr2line.exe -e cygwin1.dll 610D146A
>/pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:252

How long did this take to crash mintty?

cgf

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/25/2012 4:45 PM, Christopher Faylor wrote:
> On Mon, Jun 25, 2012 at 01:57:26PM +0200, marco atzeri wrote:
>> On 6/25/2012 11:36 AM, marco atzeri wrote:
>>> On 6/25/2012 11:00 AM, Corinna Vinschen wrote:
>>>> On Jun 25 10:37, marco atzeri wrote:
>>>>>
>>>>> A normal exception should kill just the running process, while
>>>>> I see that  xprobe_comp, bash, mintty are killed and
>>>>> also others bash and mintty processes are taking down.
>>>>
>>>> Really all processes or just all processes in the same terminal window?
>>>
>>> all processes in all the available terminal windows.
>>> 3 mintty and 3 bash are taken down and they were indepedently
>>> created by the start menu
>>>
>>>>
>>>> Corinna
>>>>
>>>
>>> I will check if today cgf's changeset make any difference
>>>
>>> Regards
>>> Marco
>>>
>>>
>> hi Corinna,
>> no difference. It takes down everything
>>
>> but you are right about mintty, it is crashing and the stackdump
>> are located at c:\windows\SySWOW64, I only noticed with procmon.
>>
>> ---------------------------------------------------------------------
>> Exception: STATUS_ACCESS_VIOLATION at eip=610CE726
>> eax=610CE710 ebx=0000010C ecx=777B0000 edx=0008E3C8 esi=0028A5B8
>> edi=8005A088
>> ebp=0028A468 esp=0028A450 program=E:\cygwin\bin\mintty.exe, pid 6652,
>> thread main
>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>> Stack trace:
>> Frame     Function  Args
>> 0028A468  610CE726  (8004EF58, 0028A5B8, E65DA9C7, 231FFA3E)
>> 0028A488  610D05CE  (0028A5B8, 0028A648, 0028A540, 0028A520)
>> 0028A618  610D146A  (00000002, 0028A648, 0028A540, 0028A520)
>> 24479433 [main] mintty 6652 exception::handle: Exception:
>> STATUS_ACCESS_VIOLATION
>> 24495658 [main] mintty 6652 exception::handle: Error while dumping state
>> (probably corrupted stack)
>> ----------------------------------------------------------------------
>>
>> $ addr2line.exe -e cygwin1.dll 610CE726
>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:687
>>
>> $ addr2line.exe -e cygwin1.dll 610D05CE
>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:243
>>
>> $ addr2line.exe -e cygwin1.dll 610D146A
>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:252
>
> How long did this take to crash mintty?
>
> cgf
>


7 sec on my slow PC.
 From procmon I saw that xprobe_comp and the shells it reises continue 
to run for a while and only after they close.

on 20120611 the full successful run is 45 sec.

Regards
Marco

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Mon, Jun 25, 2012 at 05:00:57PM +0200, marco atzeri wrote:
>On 6/25/2012 4:45 PM, Christopher Faylor wrote:
>> On Mon, Jun 25, 2012 at 01:57:26PM +0200, marco atzeri wrote:
>>> On 6/25/2012 11:36 AM, marco atzeri wrote:
>>>> On 6/25/2012 11:00 AM, Corinna Vinschen wrote:
>>>>> On Jun 25 10:37, marco atzeri wrote:
>>>>>>
>>>>>> A normal exception should kill just the running process, while
>>>>>> I see that  xprobe_comp, bash, mintty are killed and
>>>>>> also others bash and mintty processes are taking down.
>>>>>
>>>>> Really all processes or just all processes in the same terminal window?
>>>>
>>>> all processes in all the available terminal windows.
>>>> 3 mintty and 3 bash are taken down and they were indepedently
>>>> created by the start menu
>>>>
>>>>>
>>>>> Corinna
>>>>>
>>>>
>>>> I will check if today cgf's changeset make any difference
>>>>
>>>> Regards
>>>> Marco
>>>>
>>>>
>>> hi Corinna,
>>> no difference. It takes down everything
>>>
>>> but you are right about mintty, it is crashing and the stackdump
>>> are located at c:\windows\SySWOW64, I only noticed with procmon.
>>>
>>> ---------------------------------------------------------------------
>>> Exception: STATUS_ACCESS_VIOLATION at eip=610CE726
>>> eax=610CE710 ebx=0000010C ecx=777B0000 edx=0008E3C8 esi=0028A5B8
>>> edi=8005A088
>>> ebp=0028A468 esp=0028A450 program=E:\cygwin\bin\mintty.exe, pid 6652,
>>> thread main
>>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>> Stack trace:
>>> Frame     Function  Args
>>> 0028A468  610CE726  (8004EF58, 0028A5B8, E65DA9C7, 231FFA3E)
>>> 0028A488  610D05CE  (0028A5B8, 0028A648, 0028A540, 0028A520)
>>> 0028A618  610D146A  (00000002, 0028A648, 0028A540, 0028A520)
>>> 24479433 [main] mintty 6652 exception::handle: Exception:
>>> STATUS_ACCESS_VIOLATION
>>> 24495658 [main] mintty 6652 exception::handle: Error while dumping state
>>> (probably corrupted stack)
>>> ----------------------------------------------------------------------
>>>
>>> $ addr2line.exe -e cygwin1.dll 610CE726
>>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:687
>>>
>>> $ addr2line.exe -e cygwin1.dll 610D05CE
>>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:243
>>>
>>> $ addr2line.exe -e cygwin1.dll 610D146A
>>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:252
>>
>> How long did this take to crash mintty?
>>
>> cgf
>>
>
>
>7 sec on my slow PC.
> From procmon I saw that xprobe_comp and the shells it reises continue 
>to run for a while and only after they close.
>
>on 20120611 the full successful run is 45 sec.

I let my run on 20120611 go for more than that.  The system eventually
became unresponsive and I had to power cycle it.  Probably I could have
rebooted via Start if I'd been more patient, though.

I have another vague idea about this problem and will be checking in
another change soon.

cgf

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/25/2012 5:29 PM, Christopher Faylor wrote:
> On Mon, Jun 25, 2012 at 05:00:57PM +0200, marco atzeri wrote:
>> On 6/25/2012 4:45 PM, Christopher Faylor wrote:
>>> On Mon, Jun 25, 2012 at 01:57:26PM +0200, marco atzeri wrote:
>>>> On 6/25/2012 11:36 AM, marco atzeri wrote:
>>>>> On 6/25/2012 11:00 AM, Corinna Vinschen wrote:
>>>>>> On Jun 25 10:37, marco atzeri wrote:
>>>>>>>
>>>>>>> A normal exception should kill just the running process, while
>>>>>>> I see that  xprobe_comp, bash, mintty are killed and
>>>>>>> also others bash and mintty processes are taking down.
>>>>>>
>>>>>> Really all processes or just all processes in the same terminal window?
>>>>>
>>>>> all processes in all the available terminal windows.
>>>>> 3 mintty and 3 bash are taken down and they were indepedently
>>>>> created by the start menu
>>>>>
>>>>>>
>>>>>> Corinna
>>>>>>
>>>>>
>>>>> I will check if today cgf's changeset make any difference
>>>>>
>>>>> Regards
>>>>> Marco
>>>>>
>>>>>
>>>> hi Corinna,
>>>> no difference. It takes down everything
>>>>
>>>> but you are right about mintty, it is crashing and the stackdump
>>>> are located at c:\windows\SySWOW64, I only noticed with procmon.
>>>>
>>>> ---------------------------------------------------------------------
>>>> Exception: STATUS_ACCESS_VIOLATION at eip=610CE726
>>>> eax=610CE710 ebx=0000010C ecx=777B0000 edx=0008E3C8 esi=0028A5B8
>>>> edi=8005A088
>>>> ebp=0028A468 esp=0028A450 program=E:\cygwin\bin\mintty.exe, pid 6652,
>>>> thread main
>>>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>>> Stack trace:
>>>> Frame     Function  Args
>>>> 0028A468  610CE726  (8004EF58, 0028A5B8, E65DA9C7, 231FFA3E)
>>>> 0028A488  610D05CE  (0028A5B8, 0028A648, 0028A540, 0028A520)
>>>> 0028A618  610D146A  (00000002, 0028A648, 0028A540, 0028A520)
>>>> 24479433 [main] mintty 6652 exception::handle: Exception:
>>>> STATUS_ACCESS_VIOLATION
>>>> 24495658 [main] mintty 6652 exception::handle: Error while dumping state
>>>> (probably corrupted stack)
>>>> ----------------------------------------------------------------------
>>>>
>>>> $ addr2line.exe -e cygwin1.dll 610CE726
>>>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:687
>>>>
>>>> $ addr2line.exe -e cygwin1.dll 610D05CE
>>>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:243
>>>>
>>>> $ addr2line.exe -e cygwin1.dll 610D146A
>>>> /pub/cygwin/cvs/src_new/winsup/cygwin/select.cc:252
>>>
>>> How long did this take to crash mintty?
>>>
>>> cgf
>>>
>>
>>
>> 7 sec on my slow PC.
>>  From procmon I saw that xprobe_comp and the shells it reises continue
>> to run for a while and only after they close.
>>
>> on 20120611 the full successful run is 45 sec.
>
> I let my run on 20120611 go for more than that.  The system eventually
> became unresponsive and I had to power cycle it.  Probably I could have
> rebooted via Start if I'd been more patient, though.
>
> I have another vague idea about this problem and will be checking in
> another change soon.
>
> cgf
>

I straced mintty and uploaded the first portion, 10Mb, on
http://matzeri.altervista.org/works/atlas/

the remaining 320 Mb have no further trace of mintty

Regards
Marco

--
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: crash on latest cygwin snapshot

[Ken Brown]

On 6/24/2012 5:30 PM, marco atzeri wrote:
> while building latest atlas I hit a bug that is crashing all the running
> cygwin process.
> It crashes on 20120619 snapshot and also latest cvs source.
> No issue on 20120611 snapshot.

I'm also seeing this crash, but it does not kill all running cygwin 
processes.  The only processes that die are the mintty processes and the 
associated bash processes.  For example, it just happened a few minutes 
ago, and XWin survived, along with emacs and xterm.

It happens intermittently, maybe once every 3 days, and I haven't found 
a simple sequence of steps for reproducing it.  All I can say for sure 
is that I always have more than one mintty running, and they all die.

Marco, are you sure all cygwin processes die when you experience this 
problem?  Also, since you can reliably reproduce the crash, have you 
tried reverting to the previous version of mintty?  Note that mintty was 
updated just a few days before the 20120619 snapshot was released.

Ken

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 07:53:05AM -0400, Ken Brown wrote:
>On 6/24/2012 5:30 PM, marco atzeri wrote:
>> while building latest atlas I hit a bug that is crashing all the running
>> cygwin process.
>> It crashes on 20120619 snapshot and also latest cvs source.
>> No issue on 20120611 snapshot.
>
>I'm also seeing this crash, but it does not kill all running cygwin 
>processes.  The only processes that die are the mintty processes and the 
>associated bash processes.  For example, it just happened a few minutes 
>ago, and XWin survived, along with emacs and xterm.
>
>It happens intermittently, maybe once every 3 days, and I haven't found 
>a simple sequence of steps for reproducing it.  All I can say for sure 
>is that I always have more than one mintty running, and they all die.
>
>Marco, are you sure all cygwin processes die when you experience this 
>problem?  Also, since you can reliably reproduce the crash, have you 
>tried reverting to the previous version of mintty?  Note that mintty was 
>updated just a few days before the 20120619 snapshot was released.

He indicated that some processes kept running.

But, hmm.  I haven't updated mintty lately.  I will try that.

cgf

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 10:10:28AM -0400, Christopher Faylor wrote:
>On Tue, Jun 26, 2012 at 07:53:05AM -0400, Ken Brown wrote:
>>On 6/24/2012 5:30 PM, marco atzeri wrote:
>>> while building latest atlas I hit a bug that is crashing all the running
>>> cygwin process.
>>> It crashes on 20120619 snapshot and also latest cvs source.
>>> No issue on 20120611 snapshot.
>>
>>I'm also seeing this crash, but it does not kill all running cygwin 
>>processes.  The only processes that die are the mintty processes and the 
>>associated bash processes.  For example, it just happened a few minutes 
>>ago, and XWin survived, along with emacs and xterm.
>>
>>It happens intermittently, maybe once every 3 days, and I haven't found 
>>a simple sequence of steps for reproducing it.  All I can say for sure 
>>is that I always have more than one mintty running, and they all die.
>>
>>Marco, are you sure all cygwin processes die when you experience this 
>>problem?  Also, since you can reliably reproduce the crash, have you 
>>tried reverting to the previous version of mintty?  Note that mintty was 
>>updated just a few days before the 20120619 snapshot was released.
>
>He indicated that some processes kept running.
>
>But, hmm.  I haven't updated mintty lately.  I will try that.

This still just hangs my system by creating many /bin/sh and gcc jobs.
What am I supposed to be seeing for output?  If I set the PATH to just
/usr/bin, I see:

User Override Compilers:
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'
   'none' : 'none' '-fno-common'

and then no more output until I have to restart the machine due to
excessive process creation.

cgf

--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Jun 26 11:04, Christopher Faylor wrote:
> On Tue, Jun 26, 2012 at 10:10:28AM -0400, Christopher Faylor wrote:
> >On Tue, Jun 26, 2012 at 07:53:05AM -0400, Ken Brown wrote:
> >>On 6/24/2012 5:30 PM, marco atzeri wrote:
> >>> while building latest atlas I hit a bug that is crashing all the running
> >>> cygwin process.
> >>> It crashes on 20120619 snapshot and also latest cvs source.
> >>> No issue on 20120611 snapshot.
> >>
> >>I'm also seeing this crash, but it does not kill all running cygwin 
> >>processes.  The only processes that die are the mintty processes and the 
> >>associated bash processes.  For example, it just happened a few minutes 
> >>ago, and XWin survived, along with emacs and xterm.
> >>
> >>It happens intermittently, maybe once every 3 days, and I haven't found 
> >>a simple sequence of steps for reproducing it.  All I can say for sure 
> >>is that I always have more than one mintty running, and they all die.
> >>
> >>Marco, are you sure all cygwin processes die when you experience this 
> >>problem?  Also, since you can reliably reproduce the crash, have you 
> >>tried reverting to the previous version of mintty?  Note that mintty was 
> >>updated just a few days before the 20120619 snapshot was released.
> >
> >He indicated that some processes kept running.
> >
> >But, hmm.  I haven't updated mintty lately.  I will try that.
> 
> This still just hangs my system by creating many /bin/sh and gcc jobs.
> What am I supposed to be seeing for output?  If I set the PATH to just
> /usr/bin, I see:
> 
> User Override Compilers:
>    'none' : 'none' '-fno-common'
>    'none' : 'none' '-fno-common'
>    'none' : 'none' '-fno-common'
>    'none' : 'none' '-fno-common'
>    'none' : 'none' '-fno-common'
>    'none' : 'none' '-fno-common'
>    'none' : 'none' '-fno-common'
>    'none' : 'none' '-fno-common'
> 
> and then no more output until I have to restart the machine due to
> excessive process creation.

This might be a result of the problem, too.  When I run the command
on W7 and W2008R2, it hangs a couple of seconds at this point, apparently
running a find(1) command, and then the output starts like this:

--- SNIP ---
ierr=256 in command='find $HOME/local /home/corinna/bin /usr/local/bin /usr/bin /bin /mnt/c/Windows/system32 /mnt/c/Windows /mnt/c/Windows/System32/Wbem /mnt/c/Windows/System32/WindowsPowerShell/v1.0 -name '*gcc*' -exec ./xisgcc '{}' \;'!

OUTPUT:
=======
find: `/home/corinna/local': No such file or directory
/usr/bin/gcc-4.exe
/usr/bin/gcc.exe
/usr/bin/i686-pc-cygwin-gcc-4.5.3.exe
/usr/bin/i686-pc-cygwin-gcc-4.exe
/usr/bin/i686-pc-cygwin-gcc.exe
/usr/bin/i686-pc-mingw32-gcc-4.5.2.exe
/usr/bin/i686-pc-mingw32-gcc.exe
/usr/bin/x86_64-w64-mingw32-gcc-4.5.3.exe
/usr/bin/x86_64-w64-mingw32-gcc.exe
/bin/gcc-4.exe
/bin/gcc.exe
/bin/i686-pc-cygwin-gcc-4.5.3.exe
/bin/i686-pc-cygwin-gcc-4.exe
/bin/i686-pc-cygwin-gcc.exe
/bin/i686-pc-mingw32-gcc-4.5.2.exe
/bin/i686-pc-mingw32-gcc.exe
/bin/x86_64-w64-mingw32-gcc-4.5.3.exe
/bin/x86_64-w64-mingw32-gcc.exe
[...]
--- SNAP ---

and then a couple of hundreds line of output with various make commands
or something like that.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 05:31:54PM +0200, Corinna Vinschen wrote:
>On Jun 26 11:04, Christopher Faylor wrote:
>> On Tue, Jun 26, 2012 at 10:10:28AM -0400, Christopher Faylor wrote:
>> >On Tue, Jun 26, 2012 at 07:53:05AM -0400, Ken Brown wrote:
>> >>On 6/24/2012 5:30 PM, marco atzeri wrote:
>> >>> while building latest atlas I hit a bug that is crashing all the running
>> >>> cygwin process.
>> >>> It crashes on 20120619 snapshot and also latest cvs source.
>> >>> No issue on 20120611 snapshot.
>> >>
>> >>I'm also seeing this crash, but it does not kill all running cygwin 
>> >>processes.  The only processes that die are the mintty processes and the 
>> >>associated bash processes.  For example, it just happened a few minutes 
>> >>ago, and XWin survived, along with emacs and xterm.
>> >>
>> >>It happens intermittently, maybe once every 3 days, and I haven't found 
>> >>a simple sequence of steps for reproducing it.  All I can say for sure 
>> >>is that I always have more than one mintty running, and they all die.
>> >>
>> >>Marco, are you sure all cygwin processes die when you experience this 
>> >>problem?  Also, since you can reliably reproduce the crash, have you 
>> >>tried reverting to the previous version of mintty?  Note that mintty was 
>> >>updated just a few days before the 20120619 snapshot was released.
>> >
>> >He indicated that some processes kept running.
>> >
>> >But, hmm.  I haven't updated mintty lately.  I will try that.
>> 
>> This still just hangs my system by creating many /bin/sh and gcc jobs.
>> What am I supposed to be seeing for output?  If I set the PATH to just
>> /usr/bin, I see:
>> 
>> User Override Compilers:
>>    'none' : 'none' '-fno-common'
>>    'none' : 'none' '-fno-common'
>>    'none' : 'none' '-fno-common'
>>    'none' : 'none' '-fno-common'
>>    'none' : 'none' '-fno-common'
>>    'none' : 'none' '-fno-common'
>>    'none' : 'none' '-fno-common'
>>    'none' : 'none' '-fno-common'
>> 
>> and then no more output until I have to restart the machine due to
>> excessive process creation.
>
>This might be a result of the problem, too.  When I run the command
>on W7 and W2008R2, it hangs a couple of seconds at this point, apparently
>running a find(1) command, and then the output starts like this:
>
>--- SNIP ---
>ierr=256 in command='find $HOME/local /home/corinna/bin /usr/local/bin /usr/bin /bin /mnt/c/Windows/system32 /mnt/c/Windows /mnt/c/Windows/System32/Wbem /mnt/c/Windows/System32/WindowsPowerShell/v1.0 -name '*gcc*' -exec ./xisgcc '{}' \;'!
>
>OUTPUT:
>=======
>find: `/home/corinna/local': No such file or directory
>/usr/bin/gcc-4.exe
>/usr/bin/gcc.exe
>/usr/bin/i686-pc-cygwin-gcc-4.5.3.exe
>/usr/bin/i686-pc-cygwin-gcc-4.exe
>/usr/bin/i686-pc-cygwin-gcc.exe
>/usr/bin/i686-pc-mingw32-gcc-4.5.2.exe
>/usr/bin/i686-pc-mingw32-gcc.exe
>/usr/bin/x86_64-w64-mingw32-gcc-4.5.3.exe
>/usr/bin/x86_64-w64-mingw32-gcc.exe
>/bin/gcc-4.exe
>/bin/gcc.exe
>/bin/i686-pc-cygwin-gcc-4.5.3.exe
>/bin/i686-pc-cygwin-gcc-4.exe
>/bin/i686-pc-cygwin-gcc.exe
>/bin/i686-pc-mingw32-gcc-4.5.2.exe
>/bin/i686-pc-mingw32-gcc.exe
>/bin/x86_64-w64-mingw32-gcc-4.5.3.exe
>/bin/x86_64-w64-mingw32-gcc.exe
>[...]
>--- SNAP ---
>
>and then a couple of hundreds line of output with various make commands
>or something like that.

Weird.  I see nothing like that.

I get the same behavior with the supposedly working snapshot and with the
snapshot for which problems are reported.  And with 1.7.15.

cgf

--
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: crash on latest cygwin snapshot

[Achim Gratz]

Christopher Faylor writes:
> Weird.  I see nothing like that.
>
> I get the same behavior with the supposedly working snapshot and with the
> snapshot for which problems are reported.  And with 1.7.15.

Besides the problems reported, the June 19 snapshot kills mintty
processes for me once or twice a day (apparently they see an EOF or a
SIGHUP since they do save history).  In several instances the X server
has continued to run, even though mintty would normally refuse to shut
down when an X server was started from it and still running.

The June 18 snapshot had massive problems with make and git simply not
doing anything or just returning without any error or other messages
midway through their operation.  Running the same operations in strace
would often succeed.

I've gone back to the June 10 snapshot (I think June 11 would also be
fine, I've just never downloaded it).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs


--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/26/2012 5:31 PM, Corinna Vinschen wrote:
> On Jun 26 11:04, Christopher Faylor wrote:
>> On Tue, Jun 26, 2012 at 10:10:28AM -0400, Christopher Faylor wrote:
>>> On Tue, Jun 26, 2012 at 07:53:05AM -0400, Ken Brown wrote:
>>>> On 6/24/2012 5:30 PM, marco atzeri wrote:
>>>>> while building latest atlas I hit a bug that is crashing all the running
>>>>> cygwin process.
>>>>> It crashes on 20120619 snapshot and also latest cvs source.
>>>>> No issue on 20120611 snapshot.
>>>>
>>>> I'm also seeing this crash, but it does not kill all running cygwin
>>>> processes.  The only processes that die are the mintty processes and the
>>>> associated bash processes.  For example, it just happened a few minutes
>>>> ago, and XWin survived, along with emacs and xterm.
>>>>
>>>> It happens intermittently, maybe once every 3 days, and I haven't found
>>>> a simple sequence of steps for reproducing it.  All I can say for sure
>>>> is that I always have more than one mintty running, and they all die.
>>>>
>>>> Marco, are you sure all cygwin processes die when you experience this
>>>> problem?  Also, since you can reliably reproduce the crash, have you
>>>> tried reverting to the previous version of mintty?  Note that mintty was
>>>> updated just a few days before the 20120619 snapshot was released.
>>>
>>> He indicated that some processes kept running.
>>>
>>> But, hmm.  I haven't updated mintty lately.  I will try that.
>>
>> This still just hangs my system by creating many /bin/sh and gcc jobs.
>> What am I supposed to be seeing for output?  If I set the PATH to just
>> /usr/bin, I see:
>>
>> User Override Compilers:
>>     'none' : 'none' '-fno-common'
>>     'none' : 'none' '-fno-common'
>>     'none' : 'none' '-fno-common'
>>     'none' : 'none' '-fno-common'
>>     'none' : 'none' '-fno-common'
>>     'none' : 'none' '-fno-common'
>>     'none' : 'none' '-fno-common'
>>     'none' : 'none' '-fno-common'
>>
>> and then no more output until I have to restart the machine due to
>> excessive process creation.
>
> This might be a result of the problem, too.  When I run the command
> on W7 and W2008R2, it hangs a couple of seconds at this point, apparently
> running a find(1) command, and then the output starts like this:
>
> --- SNIP ---
> ierr=256 in command='find $HOME/local /home/corinna/bin /usr/local/bin /usr/bin /bin /mnt/c/Windows/system32 /mnt/c/Windows /mnt/c/Windows/System32/Wbem /mnt/c/Windows/System32/WindowsPowerShell/v1.0 -name '*gcc*' -exec ./xisgcc '{}' \;'!
>
> OUTPUT:
> =======
> find: `/home/corinna/local': No such file or directory
> /usr/bin/gcc-4.exe
> /usr/bin/gcc.exe
> /usr/bin/i686-pc-cygwin-gcc-4.5.3.exe
> /usr/bin/i686-pc-cygwin-gcc-4.exe
> /usr/bin/i686-pc-cygwin-gcc.exe
> /usr/bin/i686-pc-mingw32-gcc-4.5.2.exe
> /usr/bin/i686-pc-mingw32-gcc.exe
> /usr/bin/x86_64-w64-mingw32-gcc-4.5.3.exe
> /usr/bin/x86_64-w64-mingw32-gcc.exe
> /bin/gcc-4.exe
> /bin/gcc.exe
> /bin/i686-pc-cygwin-gcc-4.5.3.exe
> /bin/i686-pc-cygwin-gcc-4.exe
> /bin/i686-pc-cygwin-gcc.exe
> /bin/i686-pc-mingw32-gcc-4.5.2.exe
> /bin/i686-pc-mingw32-gcc.exe
> /bin/x86_64-w64-mingw32-gcc-4.5.3.exe
> /bin/x86_64-w64-mingw32-gcc.exe
> [...]
> --- SNAP ---
>
> and then a couple of hundreds line of output with various make commands
> or something like that.
>
>
> Corinna
>

This is the expected behaviour.
The program is part of a "weird" configure scripts used by ATLAS
http://math-atlas.sourceforge.net/
to detect the best compiler options for optimizing the math
perfomance on the given machine.

It stresses a bit the computer, but on snapshot 20110619 and later CVS
the side effect is to crash all mintty sessions on my W7/64 and
to block cgf's one.

So some of the change between 20110611 and 20110619 are responsable of
the mintty crash.

Marco


--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 08:51:30PM +0200, marco atzeri wrote:
>On 6/26/2012 5:31 PM, Corinna Vinschen wrote:
>> On Jun 26 11:04, Christopher Faylor wrote:
>>> On Tue, Jun 26, 2012 at 10:10:28AM -0400, Christopher Faylor wrote:
>>>> On Tue, Jun 26, 2012 at 07:53:05AM -0400, Ken Brown wrote:
>>>>> On 6/24/2012 5:30 PM, marco atzeri wrote:
>>>>>> while building latest atlas I hit a bug that is crashing all the running
>>>>>> cygwin process.
>>>>>> It crashes on 20120619 snapshot and also latest cvs source.
>>>>>> No issue on 20120611 snapshot.
>>>>>
>>>>> I'm also seeing this crash, but it does not kill all running cygwin
>>>>> processes.  The only processes that die are the mintty processes and the
>>>>> associated bash processes.  For example, it just happened a few minutes
>>>>> ago, and XWin survived, along with emacs and xterm.
>>>>>
>>>>> It happens intermittently, maybe once every 3 days, and I haven't found
>>>>> a simple sequence of steps for reproducing it.  All I can say for sure
>>>>> is that I always have more than one mintty running, and they all die.
>>>>>
>>>>> Marco, are you sure all cygwin processes die when you experience this
>>>>> problem?  Also, since you can reliably reproduce the crash, have you
>>>>> tried reverting to the previous version of mintty?  Note that mintty was
>>>>> updated just a few days before the 20120619 snapshot was released.
>>>>
>>>> He indicated that some processes kept running.
>>>>
>>>> But, hmm.  I haven't updated mintty lately.  I will try that.
>>>
>>> This still just hangs my system by creating many /bin/sh and gcc jobs.
>>> What am I supposed to be seeing for output?  If I set the PATH to just
>>> /usr/bin, I see:
>>>
>>> User Override Compilers:
>>>     'none' : 'none' '-fno-common'
>>>     'none' : 'none' '-fno-common'
>>>     'none' : 'none' '-fno-common'
>>>     'none' : 'none' '-fno-common'
>>>     'none' : 'none' '-fno-common'
>>>     'none' : 'none' '-fno-common'
>>>     'none' : 'none' '-fno-common'
>>>     'none' : 'none' '-fno-common'
>>>
>>> and then no more output until I have to restart the machine due to
>>> excessive process creation.
>>
>> This might be a result of the problem, too.  When I run the command
>> on W7 and W2008R2, it hangs a couple of seconds at this point, apparently
>> running a find(1) command, and then the output starts like this:
>>
>> --- SNIP ---
>> ierr=256 in command='find $HOME/local /home/corinna/bin /usr/local/bin /usr/bin /bin /mnt/c/Windows/system32 /mnt/c/Windows /mnt/c/Windows/System32/Wbem /mnt/c/Windows/System32/WindowsPowerShell/v1.0 -name '*gcc*' -exec ./xisgcc '{}' \;'!
>>
>> OUTPUT:
>> =======
>> find: `/home/corinna/local': No such file or directory
>> /usr/bin/gcc-4.exe
>> /usr/bin/gcc.exe
>> /usr/bin/i686-pc-cygwin-gcc-4.5.3.exe
>> /usr/bin/i686-pc-cygwin-gcc-4.exe
>> /usr/bin/i686-pc-cygwin-gcc.exe
>> /usr/bin/i686-pc-mingw32-gcc-4.5.2.exe
>> /usr/bin/i686-pc-mingw32-gcc.exe
>> /usr/bin/x86_64-w64-mingw32-gcc-4.5.3.exe
>> /usr/bin/x86_64-w64-mingw32-gcc.exe
>> /bin/gcc-4.exe
>> /bin/gcc.exe
>> /bin/i686-pc-cygwin-gcc-4.5.3.exe
>> /bin/i686-pc-cygwin-gcc-4.exe
>> /bin/i686-pc-cygwin-gcc.exe
>> /bin/i686-pc-mingw32-gcc-4.5.2.exe
>> /bin/i686-pc-mingw32-gcc.exe
>> /bin/x86_64-w64-mingw32-gcc-4.5.3.exe
>> /bin/x86_64-w64-mingw32-gcc.exe
>> [...]
>> --- SNAP ---
>>
>> and then a couple of hundreds line of output with various make commands
>> or something like that.
>
>This is the expected behaviour.
>The program is part of a "weird" configure scripts used by ATLAS
>http://math-atlas.sourceforge.net/
>to detect the best compiler options for optimizing the math
>perfomance on the given machine.
>
>It stresses a bit the computer, but on snapshot 20110619 and later CVS
>the side effect is to crash all mintty sessions on my W7/64 and
>to block cgf's one.

I'll say it again: I see no difference in behavior with any snapshot or
with the shipping version.  They all stress the system and eventually
require me to power cycle it.

>So some of the change between 20110611 and 20110619 are responsable of
>the mintty crash.

Yes.  It's understood that this used to work.  No one doubts that.

cgf

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/26/2012 9:23 PM, Christopher Faylor wrote:
>>
>> It stresses a bit the computer, but on snapshot 20110619 and later CVS
>> the side effect is to crash all mintty sessions on my W7/64 and
>> to block cgf's one.
>
> I'll say it again: I see no difference in behavior with any snapshot or
> with the shipping version.  They all stress the system and eventually
> require me to power cycle it.

Is it possible that your cpu has some difference and the
probe compiled on my cpu is not effective or causing other
problems to your pc.

If you want to try, I prepared a slim version of the package at
http://matzeri.altervista.org/works/atlas/cgf/
disabling the build and leaving only the configure session

    cygport atlas-3.9.79-1.cygport compile

take 2 minutes on my pc on 20110611

>
>> So some of the change between 20110611 and 20110619 are responsable of
>> the mintty crash.
>
> Yes.  It's understood that this used to work.  No one doubts that.

Sorry for repetition

>
> cgf
>


Marco

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 03:23:57PM -0400, Christopher Faylor wrote:
>I'll say it again: I see no difference in behavior with any snapshot or
>with the shipping version.  They all stress the system and eventually
>require me to power cycle it.

I had a "mingw-gcc" shell script in /usr/bin which seemed to cause a
problem.  Removing that allows me to duplicate the problem.

Yay?

cgf

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/26/2012 9:47 PM, Christopher Faylor wrote:
> On Tue, Jun 26, 2012 at 03:23:57PM -0400, Christopher Faylor wrote:
>> I'll say it again: I see no difference in behavior with any snapshot or
>> with the shipping version.  They all stress the system and eventually
>> require me to power cycle it.
>
> I had a "mingw-gcc" shell script in /usr/bin which seemed to cause a
> problem.  Removing that allows me to duplicate the problem.

the configure script is unfortunately "weird"
I am already proposing the author some needed cleaning.

>
> Yay?
>
> cgf
>

Marco

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 03:47:55PM -0400, Christopher Faylor wrote:
>On Tue, Jun 26, 2012 at 03:23:57PM -0400, Christopher Faylor wrote:
>>I'll say it again: I see no difference in behavior with any snapshot or
>>with the shipping version.  They all stress the system and eventually
>>require me to power cycle it.
>
>I had a "mingw-gcc" shell script in /usr/bin which seemed to cause a
>problem.  Removing that allows me to duplicate the problem.
>
>Yay?

Actually, I can duplicate your issue with the 2012-06-19 snapshot but
not with the latest CVS.  I no longer see indication of a SEGV and
mintty doesn't abort.

The strace output does have a SEGV in /bin/sh, which is worrying, but I
see similar or worse problems with 1.7.15 so that doesn't seem to be
a regression.

Can you still duplicate this problem with today's snapshot?

On Tue, Jun 26, 2012 at 09:46:15PM +0200, marco atzeri wrote:
>If you want to try, I prepared a slim version of the package at
>http://matzeri.altervista.org/works/atlas/cgf/
>disabling the build and leaving only the configure session
>
>    cygport atlas-3.9.79-1.cygport compile
>
>take 2 minutes on my pc on 20110611

I can't download a file from this slimmed down version:
http://matzeri.altervista.org/works/atlas/cgf/atlas-3.9.79-1.cygport

I get a:

Error 403
You can't access to the requested page or directory.

I can download the other two files.

I'm crossing my fingers that the latest CVS version of Cygwin fixes
your problem and I won't have to download this anyway.

cgf

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/26/2012 10:14 PM, Christopher Faylor wrote:
>
> Can you still duplicate this problem with today's snapshot?

20110626 was still failing, I will recheck anyway

>
>
> I get a:
>
> Error 403
> You can't access to the requested page or directory.
>
> I can download the other two files.
>

adjusted permission, it should work now


> I'm crossing my fingers that the latest CVS version of Cygwin fixes
> your problem and I won't have to download this anyway.
>
> cgf
>

building from CVS, I will let you know

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 10:28:04PM +0200, marco atzeri wrote:
>On 6/26/2012 10:14 PM, Christopher Faylor wrote:
>>
>> Can you still duplicate this problem with today's snapshot?
>
>20110626 was still failing, I will recheck anyway
>
>>
>>
>> I get a:
>>
>> Error 403
>> You can't access to the requested page or directory.
>>
>> I can download the other two files.
>>
>
>adjusted permission, it should work now
>
>
>> I'm crossing my fingers that the latest CVS version of Cygwin fixes
>> your problem and I won't have to download this anyway.
>
>building from CVS, I will let you know

Please use the snapshot, not your own build.

cgf

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/26/2012 10:32 PM, Christopher Faylor wrote:

>>> I'm crossing my fingers that the latest CVS version of Cygwin fixes
>>> your problem and I won't have to download this anyway.
>>
>> building from CVS, I will let you know
>
> Please use the snapshot, not your own build.
>
> cgf
>

I was planning both, just in case.

$ uname -a
CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.16s(0.261/5/3) 20120626 16:47:16 
i686 Cygwin

continues to fail

same for my build

Regards
Marco

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 10:50:51PM +0200, marco atzeri wrote:
>On 6/26/2012 10:32 PM, Christopher Faylor wrote:
>
>>>> I'm crossing my fingers that the latest CVS version of Cygwin fixes
>>>> your problem and I won't have to download this anyway.
>>>
>>> building from CVS, I will let you know
>>
>> Please use the snapshot, not your own build.
>>
>> cgf
>>
>
>I was planning both, just in case.
>
>$ uname -a
>CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.16s(0.261/5/3) 20120626 16:47:16 
>i686 Cygwin
>
>continues to fail

Could you put up an strace for me to download based on a run using the
snapshot?

cgf

--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Tue, Jun 26, 2012 at 04:53:31PM -0400, Christopher Faylor wrote:
>On Tue, Jun 26, 2012 at 10:50:51PM +0200, marco atzeri wrote:
>>On 6/26/2012 10:32 PM, Christopher Faylor wrote:
>>
>>>>> I'm crossing my fingers that the latest CVS version of Cygwin fixes
>>>>> your problem and I won't have to download this anyway.
>>>>
>>>> building from CVS, I will let you know
>>>
>>> Please use the snapshot, not your own build.
>>
>>I was planning both, just in case.
>>
>>$ uname -a
>>CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.16s(0.261/5/3) 20120626 16:47:16 
>>i686 Cygwin
>>
>>continues to fail
>
>Could you put up an strace for me to download based on a run using the
>snapshot?

Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
I'm still working on it.

cgf

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 6/27/2012 3:46 AM, Christopher Faylor wrote:
>
> Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
> I'm still working on it.
>
> cgf
>

it seems solved on 20120702 snapshots

Thanks
Marco




--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

Hi Marco, Hi Ken,

On Jul  2 16:43, marco atzeri wrote:
> On 6/27/2012 3:46 AM, Christopher Faylor wrote:
> >
> >Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
> >I'm still working on it.
> >
> >cgf
> >
> 
> it seems solved on 20120702 snapshots

can you please test your crashing scenarios with the latest developer
snapshot from today?  After some private discussion, cgf and I have a
hunch that the underlying problem was the problem I fixed yesterday, and
cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
code optimization so that your problem wasn't visible anymore.

I reverted cgf's changes to Makefile.in and generated the today's
snapshot specificially to test our hypothesis.  Please give it a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 8/1/2012 11:43 AM, Corinna Vinschen wrote:
> Hi Marco, Hi Ken,
>
> On Jul  2 16:43, marco atzeri wrote:
>> On 6/27/2012 3:46 AM, Christopher Faylor wrote:
>>>
>>> Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
>>> I'm still working on it.
>>>
>>> cgf
>>>
>>
>> it seems solved on 20120702 snapshots
>
> can you please test your crashing scenarios with the latest developer
> snapshot from today?  After some private discussion, cgf and I have a
> hunch that the underlying problem was the problem I fixed yesterday, and
> cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
> code optimization so that your problem wasn't visible anymore.
>
> I reverted cgf's changes to Makefile.in and generated the today's
> snapshot specificially to test our hypothesis.  Please give it a try.
>
>
> Thanks,
> Corinna
>

$ uname -a
CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01 
i686 Cygwin

is not crashing.

Regards
Marco

--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Aug  1 12:34, marco atzeri wrote:
> On 8/1/2012 11:43 AM, Corinna Vinschen wrote:
> >Hi Marco, Hi Ken,
> >
> >On Jul  2 16:43, marco atzeri wrote:
> >>On 6/27/2012 3:46 AM, Christopher Faylor wrote:
> >>>
> >>>Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
> >>>I'm still working on it.
> >>>
> >>>cgf
> >>>
> >>
> >>it seems solved on 20120702 snapshots
> >
> >can you please test your crashing scenarios with the latest developer
> >snapshot from today?  After some private discussion, cgf and I have a
> >hunch that the underlying problem was the problem I fixed yesterday, and
> >cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
> >code optimization so that your problem wasn't visible anymore.
> >
> >I reverted cgf's changes to Makefile.in and generated the today's
> >snapshot specificially to test our hypothesis.  Please give it a try.
> >
> >
> >Thanks,
> >Corinna
> >
> 
> $ uname -a
> CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01
> i686 Cygwin
> 
> is not crashing.

Thanks for the quick feedback!  Now let's see what Ken reports...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 8/1/2012 2:29 PM, Corinna Vinschen wrote:
> On Aug  1 12:34, marco atzeri wrote:

>>
>> $ uname -a
>> CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01
>> i686 Cygwin
>>
>> is not crashing.
>
> Thanks for the quick feedback!  Now let's see what Ken reports...
>
>
> Corinna
>

just lucky, I cleaned everything expect a forgotten test directory..


--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Aug  1 14:41, marco atzeri wrote:
> On 8/1/2012 2:29 PM, Corinna Vinschen wrote:
> >On Aug  1 12:34, marco atzeri wrote:
> 
> >>
> >>$ uname -a
> >>CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01
> >>i686 Cygwin
> >>
> >>is not crashing.
> >
> >Thanks for the quick feedback!  Now let's see what Ken reports...
> >
> >
> >Corinna
> >
> 
> just lucky, I cleaned everything expect a forgotten test directory..

Sorry if I'm dense, but does that mean you could reproduce the crash
now again?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[marco atzeri]

On 8/1/2012 2:46 PM, Corinna Vinschen wrote:

>>
>> just lucky, I cleaned everything expect a forgotten test directory..
>
> Sorry if I'm dense, but does that mean you could reproduce the crash
> now again?
>
>
> Corinna
>

No crash.
Just that the test case was still available and I was able to provide
a very fast feedback

--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Aug  1 14:51, marco atzeri wrote:
> On 8/1/2012 2:46 PM, Corinna Vinschen wrote:
> 
> >>
> >>just lucky, I cleaned everything expect a forgotten test directory..
> >
> >Sorry if I'm dense, but does that mean you could reproduce the crash
> >now again?
> >
> >
> >Corinna
> >
> 
> No crash.
> Just that the test case was still available and I was able to provide
> a very fast feedback

Uh, thank you.  What a relief.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[Ken Brown]

On 8/1/2012 8:29 AM, Corinna Vinschen wrote:
> On Aug  1 12:34, marco atzeri wrote:
>> On 8/1/2012 11:43 AM, Corinna Vinschen wrote:
>>> Hi Marco, Hi Ken,
>>>
>>> On Jul  2 16:43, marco atzeri wrote:
>>>> On 6/27/2012 3:46 AM, Christopher Faylor wrote:
>>>>>
>>>>> Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
>>>>> I'm still working on it.
>>>>>
>>>>> cgf
>>>>>
>>>>
>>>> it seems solved on 20120702 snapshots
>>>
>>> can you please test your crashing scenarios with the latest developer
>>> snapshot from today?  After some private discussion, cgf and I have a
>>> hunch that the underlying problem was the problem I fixed yesterday, and
>>> cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
>>> code optimization so that your problem wasn't visible anymore.
>>>
>>> I reverted cgf's changes to Makefile.in and generated the today's
>>> snapshot specificially to test our hypothesis.  Please give it a try.
>>>
>>>
>>> Thanks,
>>> Corinna
>>>
>>
>> $ uname -a
>> CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01
>> i686 Cygwin
>>
>> is not crashing.
>
> Thanks for the quick feedback!  Now let's see what Ken reports...

I never had a reliable way of reproducing the crash (see 
http://cygwin.com/ml/cygwin/2012-06/msg00464.html).  It happened 
seemingly at random, and very sporadically.  But I have the snapshot 
installed and will exercise it as much as I can.

Ken


--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Aug  1 08:46, Ken Brown wrote:
> On 8/1/2012 8:29 AM, Corinna Vinschen wrote:
> >On Aug  1 12:34, marco atzeri wrote:
> >>On 8/1/2012 11:43 AM, Corinna Vinschen wrote:
> >>>Hi Marco, Hi Ken,
> >>>
> >>>On Jul  2 16:43, marco atzeri wrote:
> >>>>On 6/27/2012 3:46 AM, Christopher Faylor wrote:
> >>>>>
> >>>>>Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
> >>>>>I'm still working on it.
> >>>>>
> >>>>>cgf
> >>>>>
> >>>>
> >>>>it seems solved on 20120702 snapshots
> >>>
> >>>can you please test your crashing scenarios with the latest developer
> >>>snapshot from today?  After some private discussion, cgf and I have a
> >>>hunch that the underlying problem was the problem I fixed yesterday, and
> >>>cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
> >>>code optimization so that your problem wasn't visible anymore.
> >>>
> >>>I reverted cgf's changes to Makefile.in and generated the today's
> >>>snapshot specificially to test our hypothesis.  Please give it a try.
> >>>
> >>>
> >>>Thanks,
> >>>Corinna
> >>>
> >>
> >>$ uname -a
> >>CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01
> >>i686 Cygwin
> >>
> >>is not crashing.
> >
> >Thanks for the quick feedback!  Now let's see what Ken reports...
> 
> I never had a reliable way of reproducing the crash (see
> http://cygwin.com/ml/cygwin/2012-06/msg00464.html).  It happened
> seemingly at random, and very sporadically.  But I have the snapshot
> installed and will exercise it as much as I can.

Thanks!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[Ken Brown]

On 8/1/2012 8:58 AM, Corinna Vinschen wrote:
> On Aug  1 08:46, Ken Brown wrote:
>> On 8/1/2012 8:29 AM, Corinna Vinschen wrote:
>>> On Aug  1 12:34, marco atzeri wrote:
>>>> On 8/1/2012 11:43 AM, Corinna Vinschen wrote:
>>>>> Hi Marco, Hi Ken,
>>>>>
>>>>> On Jul  2 16:43, marco atzeri wrote:
>>>>>> On 6/27/2012 3:46 AM, Christopher Faylor wrote:
>>>>>>>
>>>>>>> Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
>>>>>>> I'm still working on it.
>>>>>>>
>>>>>>> cgf
>>>>>>>
>>>>>>
>>>>>> it seems solved on 20120702 snapshots
>>>>>
>>>>> can you please test your crashing scenarios with the latest developer
>>>>> snapshot from today?  After some private discussion, cgf and I have a
>>>>> hunch that the underlying problem was the problem I fixed yesterday, and
>>>>> cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
>>>>> code optimization so that your problem wasn't visible anymore.
>>>>>
>>>>> I reverted cgf's changes to Makefile.in and generated the today's
>>>>> snapshot specificially to test our hypothesis.  Please give it a try.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Corinna
>>>>>
>>>>
>>>> $ uname -a
>>>> CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01
>>>> i686 Cygwin
>>>>
>>>> is not crashing.
>>>
>>> Thanks for the quick feedback!  Now let's see what Ken reports...
>>
>> I never had a reliable way of reproducing the crash (see
>> http://cygwin.com/ml/cygwin/2012-06/msg00464.html).  It happened
>> seemingly at random, and very sporadically.  But I have the snapshot
>> installed and will exercise it as much as I can.
>
> Thanks!

The good news: I haven't seen a repeat of that old crash so far. 
Unfortunately, I'm finding that emacs is unstable:  The emacs window 
(running under X) simply disappears after 12-24 hours.  This may not 
have anything to do with the most recent changes.  I haven't yet tested 
any earlier snapshots.

Testing this is a very slow process, since I don't know how to produce 
the problem; I just have to wait and see if emacs will die.

I tried to get some information by running emacs under gdb the most 
recent time I started it, but all I got was this:

(gdb) c
Continuing.
[Inferior 1 (process 8196) exited with code 05400]
(gdb) bt
No stack

Does that exit code mean anything to you?  I couldn't find anything by 
googling.

Ken

--
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: crash on latest cygwin snapshot

[Corinna Vinschen]

On Aug  2 10:53, Ken Brown wrote:
> On 8/1/2012 8:58 AM, Corinna Vinschen wrote:
> >On Aug  1 08:46, Ken Brown wrote:
> >>I never had a reliable way of reproducing the crash (see
> >>http://cygwin.com/ml/cygwin/2012-06/msg00464.html).  It happened
> >>seemingly at random, and very sporadically.  But I have the snapshot
> >>installed and will exercise it as much as I can.
> >
> >Thanks!
> 
> The good news: I haven't seen a repeat of that old crash so far.

That's really good news, thank you.

> Unfortunately, I'm finding that emacs is unstable:  The emacs window
> (running under X) simply disappears after 12-24 hours.  This may not
> have anything to do with the most recent changes.  I haven't yet
> tested any earlier snapshots.
> 
> Testing this is a very slow process, since I don't know how to
> produce the problem; I just have to wait and see if emacs will die.
> 
> I tried to get some information by running emacs under gdb the most
> recent time I started it, but all I got was this:
> 
> (gdb) c
> Continuing.
> [Inferior 1 (process 8196) exited with code 05400]
> (gdb) bt
> No stack
> 
> Does that exit code mean anything to you?  I couldn't find anything
> by googling.

05400 oct is 0xb00 hex.  As a wait(2) compatible exit code, it would
mean a normal exit, not signal-induced, with an exit value of 11.  Which
is kind of suspicious, since 11 is also the signal number of a SEGV.  Of
course, not every SEGV must be related to the problem at hand, but
still...

Does emacs have a signal handler which handles SEGVs?  If so, you might
consider to set a breakpoint on this signal handler in GDB.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: crash on latest cygwin snapshot

[Filipp Gunbin]

Ken Brown writes:

...
> Unfortunately, I'm finding that emacs is unstable:  The emacs window 
> (running under X) simply disappears after 12-24 hours.  This may not 
> have anything to do with the most recent changes.  I haven't yet tested 
> any earlier snapshots.
...

Hi Ken,

I observe Emacs crashes in the following scenario:

- emacs -nw
- run cygwin setup utility, click through it until it finishes (it does not matter whether
any packages are installed or not)
- continue with emacs (for example, type "C-x C-f C-g") - it will crash

I don't know if it is related to the problem in this discussion, and
probably it's not a good idea to update Cygwin while running Cygwin programs,
but maybe it will give some hint.

I'm currently on Cygwin 1.7.16, Windows 7 (maybe it started after I
upgraded from Vista recently, but I'm not sure).

-- 
Filipp Gunbin

--
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: crash on latest cygwin snapshot

[Ken Brown]

On 8/2/2012 12:28 PM, Filipp Gunbin wrote:
> Ken Brown writes:
>
> ...
>> Unfortunately, I'm finding that emacs is unstable:  The emacs window
>> (running under X) simply disappears after 12-24 hours.  This may not
>> have anything to do with the most recent changes.  I haven't yet tested
>> any earlier snapshots.
> ...
>
> Hi Ken,
>
> I observe Emacs crashes in the following scenario:
>
> - emacs -nw
> - run cygwin setup utility, click through it until it finishes (it does not matter whether
> any packages are installed or not)
> - continue with emacs (for example, type "C-x C-f C-g") - it will crash
>
> I don't know if it is related to the problem in this discussion, and
> probably it's not a good idea to update Cygwin while running Cygwin programs,
> but maybe it will give some hint.
>
> I'm currently on Cygwin 1.7.16, Windows 7 (maybe it started after I
> upgraded from Vista recently, but I'm not sure).

I can't reproduce this.  But you might want to see if it's fixed in the 
latest snapshot.  setup.exe writes to /etc, and Corinna has just fixed a 
bug involving stack corruption after /etc is modified.

Ken

--
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: crash on latest cygwin snapshot

[Filipp Gunbin]

Ken Brown writes:

> On 8/2/2012 12:28 PM, Filipp Gunbin wrote:
>> Ken Brown writes:
>>
>> ...
>>> Unfortunately, I'm finding that emacs is unstable:  The emacs window
>>> (running under X) simply disappears after 12-24 hours.  This may not
>>> have anything to do with the most recent changes.  I haven't yet tested
>>> any earlier snapshots.
>> ...
>>
>> Hi Ken,
>>
>> I observe Emacs crashes in the following scenario:
>>
>> - emacs -nw
>> - run cygwin setup utility, click through it until it finishes (it does not matter whether
>> any packages are installed or not)
>> - continue with emacs (for example, type "C-x C-f C-g") - it will crash
>>
>> I don't know if it is related to the problem in this discussion, and
>> probably it's not a good idea to update Cygwin while running Cygwin programs,
>> but maybe it will give some hint.
>>
>> I'm currently on Cygwin 1.7.16, Windows 7 (maybe it started after I
>> upgraded from Vista recently, but I'm not sure).
>
> I can't reproduce this.  But you might want to see if it's fixed in the 
> latest snapshot.  setup.exe writes to /etc, and Corinna has just fixed a 
> bug involving stack corruption after /etc is modified.
 
Tried 20120801 snapshot and it seems to be fixed.
Thanks.

-- 
Filipp Gunbin

--
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: crash on latest cygwin snapshot

[Achim Gratz]

Ken Brown writes:
> The good news: I haven't seen a repeat of that old crash so
> far. Unfortunately, I'm finding that emacs is unstable:  The emacs
> window (running under X) simply disappears after 12-24 hours.  This
> may not have anything to do with the most recent changes.  I haven't
> yet tested any earlier snapshots.

I can unfortunately confirm this observation, although I don't enjoy
Emacs for much longer than an hour at a time...  Most of the time Emacs
just vanishes, but just once I got an error message that it couldn't
allocate 8 bytes through GLib.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs


--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Thu, Aug 02, 2012 at 08:11:31PM +0200, Achim Gratz wrote:
>Ken Brown writes:
>> The good news: I haven't seen a repeat of that old crash so
>> far. Unfortunately, I'm finding that emacs is unstable:  The emacs
>> window (running under X) simply disappears after 12-24 hours.  This
>> may not have anything to do with the most recent changes.  I haven't
>> yet tested any earlier snapshots.
>
>I can unfortunately confirm this observation, although I don't enjoy
>Emacs for much longer than an hour at a time...  Most of the time Emacs
>just vanishes, but just once I got an error message that it couldn't
>allocate 8 bytes through GLib.

Just to be clear: Is this with the recent snapshot?

I ask because one other "I see something similar" seemed to come from
1.7.16.

cgf

--
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: crash on latest cygwin snapshot

[Achim Gratz]

Christopher Faylor writes:
> Just to be clear: Is this with the recent snapshot?

Yes, this is with the 2012-08-01 snapshot.

> I ask because one other "I see something similar" seemed to come from
> 1.7.16.

I'm almost always running a snapshot, but I can back it out to vanilla
Cygwin or any other snapshot if it helps finding the error.  I don't
think I've had any other updates except mesa inbetween switching from
the snapshot I used before and the current one — but that is
circumstancial evidence only.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves


--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Thu, Aug 02, 2012 at 09:14:50PM +0200, Achim Gratz wrote:
>Christopher Faylor writes:
>> Just to be clear: Is this with the recent snapshot?
>
>Yes, this is with the 2012-08-01 snapshot.
>
>> I ask because one other "I see something similar" seemed to come from
>> 1.7.16.
>
>I'm almost always running a snapshot, but I can back it out to vanilla
>Cygwin or any other snapshot if it helps finding the error.  I don't
>think I've had any other updates except mesa inbetween switching from
>the snapshot I used before and the current one ??? but that is
>circumstancial evidence only.

It would be interesting to see if you or Ken have a problem with the
20120730 snapshot.

And, if so, then an strace would probably be useful, although it would
be huge.  If you do get one, let me know how to download it or I can
provide temporary storage somewhere.

cgf

--
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: crash on latest cygwin snapshot

[Ken Brown]

On 8/2/2012 3:34 PM, Christopher Faylor wrote:
> On Thu, Aug 02, 2012 at 09:14:50PM +0200, Achim Gratz wrote:
>> Christopher Faylor writes:
>>> Just to be clear: Is this with the recent snapshot?
>>
>> Yes, this is with the 2012-08-01 snapshot.
>>
>>> I ask because one other "I see something similar" seemed to come from
>>> 1.7.16.
>>
>> I'm almost always running a snapshot, but I can back it out to vanilla
>> Cygwin or any other snapshot if it helps finding the error.  I don't
>> think I've had any other updates except mesa inbetween switching from
>> the snapshot I used before and the current one ??? but that is
>> circumstancial evidence only.
>
> It would be interesting to see if you or Ken have a problem with the
> 20120730 snapshot.
>
> And, if so, then an strace would probably be useful, although it would
> be huge.  If you do get one, let me know how to download it or I can
> provide temporary storage somewhere.

I do have the same problem with the 20120730 snapshot.  I started emacs 
in an xterm window, attached strace, and walked away.  This time it 
didn't take long for emacs to crash, so the strace output isn't huge:

wget http://sanibeltranquility.com/cygwin/strace.out

Ken


--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Thu, Aug 02, 2012 at 11:05:10PM -0400, Ken Brown wrote:
>On 8/2/2012 3:34 PM, Christopher Faylor wrote:
>> On Thu, Aug 02, 2012 at 09:14:50PM +0200, Achim Gratz wrote:
>>> Christopher Faylor writes:
>>>> Just to be clear: Is this with the recent snapshot?
>>>
>>> Yes, this is with the 2012-08-01 snapshot.
>>>
>>>> I ask because one other "I see something similar" seemed to come from
>>>> 1.7.16.
>>>
>>> I'm almost always running a snapshot, but I can back it out to vanilla
>>> Cygwin or any other snapshot if it helps finding the error.  I don't
>>> think I've had any other updates except mesa inbetween switching from
>>> the snapshot I used before and the current one ??? but that is
>>> circumstancial evidence only.
>>
>> It would be interesting to see if you or Ken have a problem with the
>> 20120730 snapshot.
>>
>> And, if so, then an strace would probably be useful, although it would
>> be huge.  If you do get one, let me know how to download it or I can
>> provide temporary storage somewhere.
>
>I do have the same problem with the 20120730 snapshot.  I started emacs 
>in an xterm window, attached strace, and walked away.  This time it 
>didn't take long for emacs to crash, so the strace output isn't huge:
>
>wget http://sanibeltranquility.com/cygwin/strace.out

Thanks.  I think I see the problem but I won't be able to get to it tonight.

It's in the new signal handling code.

cgf

--
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: crash on latest cygwin snapshot

[Achim Gratz]

Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
> Thanks.  I think I see the problem but I won't be able to get to it tonight.

Based on that information, I went back to the July 29th snapshot and it is
holding up good so far.  I checked my logs and I had the snapshot from July 25th
installed before going to the August 1st one.


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: crash on latest cygwin snapshot

[Christopher Faylor]

On Thu, Aug 02, 2012 at 11:41:19PM -0400, Christopher Faylor wrote:
>On Thu, Aug 02, 2012 at 11:05:10PM -0400, Ken Brown wrote:
>>On 8/2/2012 3:34 PM, Christopher Faylor wrote:
>>>On Thu, Aug 02, 2012 at 09:14:50PM +0200, Achim Gratz wrote:
>>>>Christopher Faylor writes:
>>>>>Just to be clear: Is this with the recent snapshot?
>>>>
>>>>Yes, this is with the 2012-08-01 snapshot.
>>>>
>>>>>I ask because one other "I see something similar" seemed to come from
>>>>>1.7.16.
>>>>
>>>>I'm almost always running a snapshot, but I can back it out to vanilla
>>>>Cygwin or any other snapshot if it helps finding the error.  I don't
>>>>think I've had any other updates except mesa inbetween switching from
>>>>the snapshot I used before and the current one ???  but that is
>>>>circumstancial evidence only.
>>>
>>>It would be interesting to see if you or Ken have a problem with the
>>>20120730 snapshot.
>>>
>>>And, if so, then an strace would probably be useful, although it would
>>>be huge.  If you do get one, let me know how to download it or I can
>>>provide temporary storage somewhere.
>>
>>I do have the same problem with the 20120730 snapshot.  I started emacs
>>in an xterm window, attached strace, and walked away.  This time it
>>didn't take long for emacs to crash, so the strace output isn't huge:
>>
>>wget http://sanibeltranquility.com/cygwin/strace.out
>
>Thanks.  I think I see the problem but I won't be able to get to it
>tonight.
>
>It's in the new signal handling code.

I was actually able to duplicate this fairly easy.  It took me too long
to realize that I had to run the X version of emacs, when that should
have been obvious from the strace.

I have uploaded a new snapshot which should fix the problem.

Can you confirm Ken?

cgf

--
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: crash on latest cygwin snapshot

[Ken Brown]

On 8/3/2012 12:21 PM, Christopher Faylor wrote:
> On Thu, Aug 02, 2012 at 11:41:19PM -0400, Christopher Faylor wrote:
>> On Thu, Aug 02, 2012 at 11:05:10PM -0400, Ken Brown wrote:
>>> On 8/2/2012 3:34 PM, Christopher Faylor wrote:
>>>> On Thu, Aug 02, 2012 at 09:14:50PM +0200, Achim Gratz wrote:
>>>>> Christopher Faylor writes:
>>>>>> Just to be clear: Is this with the recent snapshot?
>>>>>
>>>>> Yes, this is with the 2012-08-01 snapshot.
>>>>>
>>>>>> I ask because one other "I see something similar" seemed to come from
>>>>>> 1.7.16.
>>>>>
>>>>> I'm almost always running a snapshot, but I can back it out to vanilla
>>>>> Cygwin or any other snapshot if it helps finding the error.  I don't
>>>>> think I've had any other updates except mesa inbetween switching from
>>>>> the snapshot I used before and the current one ???  but that is
>>>>> circumstancial evidence only.
>>>>
>>>> It would be interesting to see if you or Ken have a problem with the
>>>> 20120730 snapshot.
>>>>
>>>> And, if so, then an strace would probably be useful, although it would
>>>> be huge.  If you do get one, let me know how to download it or I can
>>>> provide temporary storage somewhere.
>>>
>>> I do have the same problem with the 20120730 snapshot.  I started emacs
>>> in an xterm window, attached strace, and walked away.  This time it
>>> didn't take long for emacs to crash, so the strace output isn't huge:
>>>
>>> wget http://sanibeltranquility.com/cygwin/strace.out
>>
>> Thanks.  I think I see the problem but I won't be able to get to it
>> tonight.
>>
>> It's in the new signal handling code.
>
> I was actually able to duplicate this fairly easy.  It took me too long
> to realize that I had to run the X version of emacs, when that should
> have been obvious from the strace.
>
> I have uploaded a new snapshot which should fix the problem.
>
> Can you confirm Ken?

I'm testing.  It looks good so far, but I'd like to get emacs running 
without a crash for 24 hours before I'm confident.  I'll report back 
tomorrow.

I'm also testing to see if the recent changes have fixed the problem 
that I was struggling with in 
http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html .  That also 
looks good so far.

Ken


--
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: crash on latest cygwin snapshot

[Christopher Faylor]

On Fri, Aug 03, 2012 at 04:02:28PM -0400, Ken Brown wrote:
>On 8/3/2012 12:21 PM, Christopher Faylor wrote:
>> On Thu, Aug 02, 2012 at 11:41:19PM -0400, Christopher Faylor wrote:
>>> On Thu, Aug 02, 2012 at 11:05:10PM -0400, Ken Brown wrote:
>>>> On 8/2/2012 3:34 PM, Christopher Faylor wrote:
>>>>> On Thu, Aug 02, 2012 at 09:14:50PM +0200, Achim Gratz wrote:
>>>>>> Christopher Faylor writes:
>>>>>>> Just to be clear: Is this with the recent snapshot?
>>>>>>
>>>>>> Yes, this is with the 2012-08-01 snapshot.
>>>>>>
>>>>>>> I ask because one other "I see something similar" seemed to come from
>>>>>>> 1.7.16.
>>>>>>
>>>>>> I'm almost always running a snapshot, but I can back it out to vanilla
>>>>>> Cygwin or any other snapshot if it helps finding the error.  I don't
>>>>>> think I've had any other updates except mesa inbetween switching from
>>>>>> the snapshot I used before and the current one ???  but that is
>>>>>> circumstancial evidence only.
>>>>>
>>>>> It would be interesting to see if you or Ken have a problem with the
>>>>> 20120730 snapshot.
>>>>>
>>>>> And, if so, then an strace would probably be useful, although it would
>>>>> be huge.  If you do get one, let me know how to download it or I can
>>>>> provide temporary storage somewhere.
>>>>
>>>> I do have the same problem with the 20120730 snapshot.  I started emacs
>>>> in an xterm window, attached strace, and walked away.  This time it
>>>> didn't take long for emacs to crash, so the strace output isn't huge:
>>>>
>>>> wget http://sanibeltranquility.com/cygwin/strace.out
>>>
>>> Thanks.  I think I see the problem but I won't be able to get to it
>>> tonight.
>>>
>>> It's in the new signal handling code.
>>
>> I was actually able to duplicate this fairly easy.  It took me too long
>> to realize that I had to run the X version of emacs, when that should
>> have been obvious from the strace.
>>
>> I have uploaded a new snapshot which should fix the problem.
>>
>> Can you confirm Ken?
>
>I'm testing.  It looks good so far, but I'd like to get emacs running 
>without a crash for 24 hours before I'm confident.  I'll report back 
>tomorrow.
>
>I'm also testing to see if the recent changes have fixed the problem 
>that I was struggling with in 
>http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html .  That also 
>looks good so far.

Well, fingers crossed, but I'm not aware of anything which would fix what
you describe there.

cgf

--
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: crash on latest cygwin snapshot

[Ken Brown]

On 8/3/2012 7:48 PM, Christopher Faylor wrote:
> On Fri, Aug 03, 2012 at 04:02:28PM -0400, Ken Brown wrote:
>> On 8/3/2012 12:21 PM, Christopher Faylor wrote:
>>> On Thu, Aug 02, 2012 at 11:41:19PM -0400, Christopher Faylor wrote:
>>>> On Thu, Aug 02, 2012 at 11:05:10PM -0400, Ken Brown wrote:
>>>>> On 8/2/2012 3:34 PM, Christopher Faylor wrote:
>>>>>> On Thu, Aug 02, 2012 at 09:14:50PM +0200, Achim Gratz wrote:
>>>>>>> Christopher Faylor writes:
>>>>>>>> Just to be clear: Is this with the recent snapshot?
>>>>>>>
>>>>>>> Yes, this is with the 2012-08-01 snapshot.
>>>>>>>
>>>>>>>> I ask because one other "I see something similar" seemed to come from
>>>>>>>> 1.7.16.
>>>>>>>
>>>>>>> I'm almost always running a snapshot, but I can back it out to vanilla
>>>>>>> Cygwin or any other snapshot if it helps finding the error.  I don't
>>>>>>> think I've had any other updates except mesa inbetween switching from
>>>>>>> the snapshot I used before and the current one ???  but that is
>>>>>>> circumstancial evidence only.
>>>>>>
>>>>>> It would be interesting to see if you or Ken have a problem with the
>>>>>> 20120730 snapshot.
>>>>>>
>>>>>> And, if so, then an strace would probably be useful, although it would
>>>>>> be huge.  If you do get one, let me know how to download it or I can
>>>>>> provide temporary storage somewhere.
>>>>>
>>>>> I do have the same problem with the 20120730 snapshot.  I started emacs
>>>>> in an xterm window, attached strace, and walked away.  This time it
>>>>> didn't take long for emacs to crash, so the strace output isn't huge:
>>>>>
>>>>> wget http://sanibeltranquility.com/cygwin/strace.out
>>>>
>>>> Thanks.  I think I see the problem but I won't be able to get to it
>>>> tonight.
>>>>
>>>> It's in the new signal handling code.
>>>
>>> I was actually able to duplicate this fairly easy.  It took me too long
>>> to realize that I had to run the X version of emacs, when that should
>>> have been obvious from the strace.
>>>
>>> I have uploaded a new snapshot which should fix the problem.
>>>
>>> Can you confirm Ken?
>>
>> I'm testing.  It looks good so far, but I'd like to get emacs running
>> without a crash for 24 hours before I'm confident.  I'll report back
>> tomorrow.
>>
>> I'm also testing to see if the recent changes have fixed the problem
>> that I was struggling with in
>> http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html .  That also
>> looks good so far.
>
> Well, fingers crossed, but I'm not aware of anything which would fix what
> you describe there.

Everything still looks good, including the version built with gsettings 
support.  I don't know what fixed the latter, unless maybe it was the 
/etc problem.  Anyway, thanks to you and Corinna for whatever you did.

Ken


--
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