This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: crash on latest cygwin snapshot
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