* "emacs -nw" hangs in a terminal
@ 2012-05-14 12:31 cygwin
2012-05-14 13:58 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: cygwin @ 2012-05-14 12:31 UTC (permalink / raw)
To: cygwin
Recently, emacs in a terminal started hanging:
/usr/bin/emacs -nw --no-init-file --no-site-file
I had to kill it from another terminal window.
But I noticed /usr/bin/emacs points through alternatives to
/usr/bin/emacs-X11, so I started calling /usr/bin/emacs-nox
directly. (Actually I modified my emn script.) This solves
the problem for me.
But "emacs -nw" has worked forever until very recently.
-Ken Jackson
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-14 12:31 "emacs -nw" hangs in a terminal cygwin
@ 2012-05-14 13:58 ` Ken Brown
2012-05-15 11:00 ` Filipp Gunbin
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-14 13:58 UTC (permalink / raw)
To: cygwin
On 5/14/2012 8:29 AM, Ken Jackson wrote:
> Recently, emacs in a terminal started hanging:
>
> /usr/bin/emacs -nw --no-init-file --no-site-file
>
> I had to kill it from another terminal window.
>
> But I noticed /usr/bin/emacs points through alternatives to
> /usr/bin/emacs-X11, so I started calling /usr/bin/emacs-nox
> directly. (Actually I modified my emn script.) This solves
> the problem for me.
>
> But "emacs -nw" has worked forever until very recently.
This is a known problem with emacs-23 and glib >= 2.31:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9754
I guess the problem just showed up on Cygwin a few days ago because of
the recent update of the GNOME libraries. And I didn't notice it myself
because I've been using emacs-24, which doesn't have the problem.
I'll prepare an update ASAP with a fix. In the meantime, you can
continue with your workaround of calling emacs-nox.exe directly, or you
can try the test version of emacs-24 that's available via setup.exe. The
latter would be appreciated; emacs-24.1 is going to be released fairly
soon, and it would be nice to have some Cygwin users test it.
Thanks for the report.
Ken Brown
Cygwin's emacs maintainer
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-14 13:58 ` Ken Brown
@ 2012-05-15 11:00 ` Filipp Gunbin
2012-05-15 11:47 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Filipp Gunbin @ 2012-05-15 11:00 UTC (permalink / raw)
To: cygwin
Ken Brown <kbrown@cornell.edu> writes:
> On 5/14/2012 8:29 AM, Ken Jackson wrote:
>> Recently, emacs in a terminal started hanging:
>>
>> /usr/bin/emacs -nw --no-init-file --no-site-file
>>
>> I had to kill it from another terminal window.
>>
>> But I noticed /usr/bin/emacs points through alternatives to
>> /usr/bin/emacs-X11, so I started calling /usr/bin/emacs-nox
>> directly. (Actually I modified my emn script.) This solves
>> the problem for me.
>>
>> But "emacs -nw" has worked forever until very recently.
>
> This is a known problem with emacs-23 and glib >= 2.31:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9754
>
> I guess the problem just showed up on Cygwin a few days ago because of
> the recent update of the GNOME libraries. And I didn't notice it
> myself because I've been using emacs-24, which doesn't have the
> problem.
>
> I'll prepare an update ASAP with a fix. In the meantime, you can
> continue with your workaround of calling emacs-nox.exe directly, or
> you can try the test version of emacs-24 that's available via
> setup.exe. The latter would be appreciated; emacs-24.1 is going to be
> released fairly soon, and it would be nice to have some Cygwin users
> test it.
>
> Thanks for the report.
>
> Ken Brown
> Cygwin's emacs maintainer
>
>
I had the same problem (emacs-23 hangs) today after updating Cygwin
including GNOME libraries.
I tried emacs-24, but with no luck: after hitting `C-x C-f C-g' emacs
almost always dumps core. I had to revert to emacs-23 for now (using
the workaround with emacs-nox, thanks for it!).
Sorry for the poor report, probably I could provide more details if
needed. In case it matters, I did full rebase (deleted db file and run
rebaseall) just before trying emacs-24.
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-15 11:00 ` Filipp Gunbin
@ 2012-05-15 11:47 ` Ken Brown
2012-05-15 12:17 ` Filipp Gunbin
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-15 11:47 UTC (permalink / raw)
To: cygwin
On 5/15/2012 6:57 AM, Filipp Gunbin wrote:
> I tried emacs-24, but with no luck: after hitting `C-x C-f C-g' emacs
> almost always dumps core. I had to revert to emacs-23 for now (using
> the workaround with emacs-nox, thanks for it!).
>
> Sorry for the poor report, probably I could provide more details if
> needed.
Please do provide details, including the cygcheck output requested at
http://cygwin.com/problems.html
Give a complete recipe for reproducing the problem, preferably starting
with `emacs -Q'.
Thanks.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-15 11:47 ` Ken Brown
@ 2012-05-15 12:17 ` Filipp Gunbin
2012-05-15 12:27 ` Filipp Gunbin
0 siblings, 1 reply; 36+ messages in thread
From: Filipp Gunbin @ 2012-05-15 12:17 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
Ken Brown writes:
> On 5/15/2012 6:57 AM, Filipp Gunbin wrote:
>> I tried emacs-24, but with no luck: after hitting `C-x C-f C-g' emacs
>> almost always dumps core. I had to revert to emacs-23 for now (using
>> the workaround with emacs-nox, thanks for it!).
>>
>> Sorry for the poor report, probably I could provide more details if
>> needed.
>
> Please do provide details, including the cygcheck output requested at
>
> http://cygwin.com/problems.html
>
> Give a complete recipe for reproducing the problem, preferably
> starting with `emacs -Q'.
>
> Thanks.
>
> Ken
>
>
Attached the output from cygcheck. For some reason it dumped core too:
$ cygcheck -s -v -r > /tmp/cygcheck.out
Segmentation fault
Other programs seem to work normally (though I haven't tried many).
The steps to reproduce the problem with emacs-24 are:
1. start emacs: emacs -nw -Q
2. C-x C-f C-g
Here emacs either dumps core or hangs.
I didn't have any problems with other Cygwin programs in the last
months.
Thanks!
--
Filipp Gunbin
[-- Attachment #2: cygcheck.out.1 --]
[-- Type: application/octet-stream, Size: 36291 bytes --]
Cygwin Configuration Diagnostics
Current System Time: Tue May 15 13:02:10 2012
Windows Vista Business Ver 6.0 Build 6001 Service Pack 1
Path: D:\cygwin\root\home\fg\bin
D:\cygwin\root\usr\local\apache-maven-2.2.1\bin
D:\cygwin\root\usr\local\ant\bin
C:\Program Files\Java\jdk1.6.0_32\bin
D:\cygwin\root\opt\jboss\bin
D:\cygwin\root\usr\local\pgsql\bin
D:\cygwin\root\usr\local\pgsql\lib
D:\cygwin\root\usr\local\hbase-0.20.6\bin
D:\cygwin\root\usr\local\apache-activemq-5.5.1\bin
D:\cygwin\root\usr\local\bin
D:\cygwin\root\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\oracle\product\11.1.0\client_1
D:\cygwin\root\lib\lapack
Output from D:\cygwin\root\bin\id.exe
UID: 1016(fg) GID: 513(None)
513(None) 0(root)
544(Администраторы) 545(Пользователи)
SysDir: C:\Windows\system32
WinDir: C:\Windows
HOME = 'D:\cygwin\root\home\fg'
PWD = '/home/fg'
USER = 'fg'
ALLUSERSPROFILE = 'C:\ProgramData'
ANT_HOME = 'D:/cygwin/root/usr/local/ant'
APPDATA = 'C:\Users\fg\AppData\Roaming'
CATALINA_HOME = '/usr/local/tomcat'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
COMPUTERNAME = 'WS796-OF-SPB'
DFSTRACINGON = 'FALSE'
FP_NO_HOST_CHECK = 'NO'
FTP_PASSIVE = '1'
HBASE_HOME = '/usr/local/hbase'
HOMEDRIVE = 'C:'
HOMEPATH = '\Users\fg'
HOSTNAME = 'ws796-of-spb'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
JAVA_HOME = 'C:/Program Files/Java/jdk1.6.0_32/'
JBOSS_HOME = 'D:/cygwin/root/opt/jboss'
LANG = 'C.UTF8'
LOCALAPPDATA = 'C:\Users\fg\AppData\Local'
LOGONSERVER = '\\WS796-OF-SPB'
M2 = 'D:/cygwin/root/usr/local/apache-maven-2.2.1/bin'
M2_HOME = 'D:/cygwin/root/usr/local/apache-maven-2.2.1/'
MANPATH = '/usr/local/pgsql/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
MAVEN_OPTS = '-Duser.home=D:/cygwin/root/home/fg -Xmx512m'
NLS_LANG = 'American_America.UTF8'
NUMBER_OF_PROCESSORS = '2'
OLDPWD = '/cygdrive/c/Users/fg/Desktop'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
PGDATA = '/var/pgsql/data'
PRINTER = 'Microsoft XPS Document Writer'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = '6'
PROCESSOR_REVISION = '1706'
PROGRAMFILES = 'C:\Program Files'
PS1 = '\n\u@\h \w\n$ '
PUBLIC = 'C:\Users\Public'
ProgramData = 'C:\ProgramData'
SESSIONNAME = 'Console'
SHELL = '/bin/bash'
SHLVL = '1'
SYSTEMDRIVE = 'C:'
SYSTEMROOT = 'C:\Windows'
TEMP = 'D:\cygwin\root\tmp'
TERM = 'xterm'
TMP = 'D:\cygwin\root\tmp'
TNS_ADMIN = 'c:/oracle/product/11.1.0/client_1/Network/Admin'
TRACE_FORMAT_SEARCH_PATH = '\\NTREL202.ntdev.corp.microsoft.com\4F18C3A5-CA09-4DBD-B6FC-219FDD4C6BE0\TraceFormat'
TZ = 'Europe/Moscow'
UATDATA = 'C:\Windows\system32\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77'
USERDOMAIN = 'WS796-OF-SPB'
USERNAME = 'fg'
USERPROFILE = 'C:\Users\fg'
WINDIR = 'C:\Windows'
_ = '/usr/bin/cygcheck'
asl.log = 'Destination=file'
temp = 'C:\Users\fg\AppData\Local\Temp'
tmp = 'C:\Users\fg\AppData\Local\Temp'
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.cn%2fcygwin%2f
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.cn%2fcygwin%2f\OpenWithList
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = '/cygdrive'
cygdrive flags = 0x00000022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = 'C:\cygwin'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = 'C:\cygwin/bin'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = 'C:\cygwin/lib'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
(default) = '\??\C:\cygwin'
f4b351e98fef0d38 = '\??\D:\cygwin\root'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
(default) = 'd:\cygwin\root'
obcaseinsensitive set to 1
Cygwin installations found in the registry:
System: Key: c5e39b7a9d22bafb Path: C:\cygwin (ORPHANED)
System: Key: f4b351e98fef0d38 Path: D:\cygwin\root
c: hd NTFS 51214Mb 56% CP CS UN PA FC
d: hd NTFS 187257Mb 17% CP CS UN PA FC
e: cd N/A N/A
D:\cygwin\root / system binary,auto
D:\cygwin\root\bin /usr/bin system binary,auto
D:\cygwin\root\lib /usr/lib system binary,auto
cygdrive prefix /cygdrive user binary,auto
Found: D:\cygwin\root\bin\awk
-> D:\cygwin\root\bin\gawk.exe
Found: D:\cygwin\root\bin\bash.exe
Found: D:\cygwin\root\bin\cat.exe
Found: D:\cygwin\root\bin\cp.exe
Found: D:\cygwin\root\bin\cpp.exe
-> D:\cygwin\root\etc\alternatives\cpp
-> D:\cygwin\root\bin\cpp-3.exe
Not Found: crontab
Found: D:\cygwin\root\bin\find.exe
Found: C:\Windows\system32\find.exe
Warning: D:\cygwin\root\bin\find.exe hides C:\Windows\system32\find.exe
Found: D:\cygwin\root\bin\gcc.exe
-> D:\cygwin\root\etc\alternatives\gcc
-> D:\cygwin\root\bin\gcc-3.exe
Not Found: gdb
Found: D:\cygwin\root\bin\grep.exe
Found: D:\cygwin\root\bin\kill.exe
Found: D:\cygwin\root\bin\ld.exe
Found: D:\cygwin\root\bin\ls.exe
Found: D:\cygwin\root\bin\make.exe
Found: D:\cygwin\root\bin\mv.exe
Found: D:\cygwin\root\bin\patch.exe
Found: D:\cygwin\root\bin\perl.exe
Found: D:\cygwin\root\bin\rm.exe
Found: D:\cygwin\root\bin\sed.exe
Found: D:\cygwin\root\bin\ssh.exe
Found: D:\cygwin\root\bin\sh.exe
Found: D:\cygwin\root\bin\tar.exe
Found: D:\cygwin\root\bin\test.exe
Not Found: vi
Not Found: vim
95k 2012/04/11 D:\cygwin\root\usr\local\pgsql\lib\cygecpg.dll - os=4.0 img=1.0 sys=4.0
"cygecpg.dll" v0.0 ts=2012/4/5 11:12
31k 2012/04/11 D:\cygwin\root\usr\local\pgsql\lib\cygecpg_compat.dll - os=4.0 img=1.0 sys=4.0
"cygecpg_compat.dll" v0.0 ts=2012/4/5 11:12
72k 2012/04/11 D:\cygwin\root\usr\local\pgsql\lib\cygpgtypes.dll - os=4.0 img=1.0 sys=4.0
"cygpgtypes.dll" v0.0 ts=2012/4/5 11:12
147k 2012/04/11 D:\cygwin\root\usr\local\pgsql\lib\cygpq.dll - os=4.0 img=1.0 sys=4.0
"cygpq.dll" v0.0 ts=2012/4/5 11:12
118k 2012/02/19 D:\cygwin\root\bin\cygapr-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygapr-1-0.dll" v0.0 ts=2012/2/19 20:55
89k 2011/12/20 D:\cygwin\root\bin\cygaprutil-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygaprutil-1-0.dll" v0.0 ts=2011/12/20 19:31
448k 2012/03/23 D:\cygwin\root\bin\cygasn1-8.dll - os=4.0 img=1.0 sys=4.0
"cygasn1-8.dll" v0.0 ts=2012/3/23 3:53
94k 2012/05/01 D:\cygwin\root\bin\cygatk-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygatk-1.0-0.dll" v0.0 ts=2012/5/1 3:28
14k 2012/05/04 D:\cygwin\root\bin\cygattr-1.dll - os=4.0 img=1.0 sys=4.0
"cygattr-1.dll" v0.0 ts=2012/5/4 12:35
167k 2012/04/04 D:\cygwin\root\bin\cygautotrace-3.dll - os=4.0 img=1.0 sys=4.0
"cygautotrace-3.dll" v0.0 ts=2012/4/4 9:50
62k 2011/05/21 D:\cygwin\root\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
"cygbz2-1.dll" v0.0 ts=2011/5/21 20:16
895k 2012/05/01 D:\cygwin\root\bin\cygcairo-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-2.dll" v0.0 ts=2012/5/1 5:36
20k 2012/05/01 D:\cygwin\root\bin\cygcairo-gobject-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-gobject-2.dll" v0.0 ts=2012/5/1 5:36
101k 2012/05/01 D:\cygwin\root\bin\cygcairo-script-interpreter-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-script-interpreter-2.dll" v0.0 ts=2012/5/1 5:36
8k 2011/10/16 D:\cygwin\root\bin\cygcharset-1.dll - os=4.0 img=1.0 sys=4.0
"cygcharset-1.dll" v0.0 ts=2011/10/16 18:00
9k 2011/01/07 D:\cygwin\root\bin\cygcom_err-2.dll - os=4.0 img=1.0 sys=4.0
"cygcom_err-2.dll" v0.0 ts=2011/1/7 1:26
29k 2010/10/11 D:\cygwin\root\bin\cygcord-1.dll - os=4.0 img=1.0 sys=4.0
"cygcord-1.dll" v0.0 ts=2010/10/11 18:03
189k 2012/05/04 D:\cygwin\root\bin\cygcroco-0.6-3.dll - os=4.0 img=1.0 sys=4.0
"cygcroco-0.6-3.dll" v0.0 ts=2012/5/4 4:54
7k 2012/05/07 D:\cygwin\root\bin\cygcrypt-0.dll - os=4.0 img=1.0 sys=4.0
"cygcrypt-0.dll" v0.0 ts=2012/5/7 12:18
1246k 2012/05/11 D:\cygwin\root\bin\cygcrypto-0.9.8.dll - os=4.0 img=1.0 sys=4.0
"cygcrypto-0.9.8.dll" v0.0 ts=2012/5/11 12:25
1515k 2012/05/11 D:\cygwin\root\bin\cygcrypto-1.0.0.dll - os=4.0 img=1.0 sys=4.0
"cygcrypto-1.0.0.dll" v0.0 ts=2012/5/11 11:33
340k 2012/03/19 D:\cygwin\root\bin\cygcurl-4.dll - os=4.0 img=1.0 sys=4.0
"cygcurl-4.dll" v0.0 ts=2012/3/19 4:38
17k 2011/10/02 D:\cygwin\root\bin\cygdatrie-1.dll - os=4.0 img=1.0 sys=4.0
"cygdatrie-1.dll" v0.0 ts=2011/10/3 0:13
929k 2011/11/10 D:\cygwin\root\bin\cygdb-4.5.dll - os=4.0 img=1.0 sys=4.0
"cygdb-4.5.dll" v0.0 ts=2011/11/10 19:52
219k 2012/04/20 D:\cygwin\root\bin\cygdbus-1-3.dll - os=4.0 img=1.0 sys=4.0
"cygdbus-1-3.dll" v0.0 ts=2012/4/20 3:09
93k 2011/11/10 D:\cygwin\root\bin\cygdb_cxx-4.5.dll - os=4.0 img=1.0 sys=4.0
"cygdb_cxx-4.5.dll" v0.0 ts=2011/11/10 19:53
130k 2012/01/23 D:\cygwin\root\bin\cygdialog-10.dll - os=4.0 img=1.0 sys=4.0
"cygdialog-10.dll" v0.0 ts=2012/1/23 9:39
140k 2012/05/03 D:\cygwin\root\bin\cygedit-0.dll - os=4.0 img=1.0 sys=4.0
"cygedit-0.dll" v0.0 ts=2012/5/3 18:12
163k 2010/05/19 D:\cygwin\root\bin\cygEMF-1.dll - os=4.0 img=1.0 sys=4.0
"cygEMF-1.dll" v0.0 ts=2010/5/19 20:51
118k 2008/05/09 D:\cygwin\root\bin\cygexpat-1.dll - os=4.0 img=1.0 sys=4.0
"cygexpat-1.dll" v0.0 ts=2008/5/9 5:03
29k 2010/05/12 D:\cygwin\root\bin\cygfam-0.dll - os=4.0 img=1.0 sys=4.0
"cygfam-0.dll" v0.0 ts=2010/5/12 11:26
21k 2011/10/26 D:\cygwin\root\bin\cygffi-4.dll - os=4.0 img=1.0 sys=4.0
"cygffi-4.dll" v0.0 ts=2011/10/23 14:33
785k 2011/08/23 D:\cygwin\root\bin\cygfftw3-3.dll - os=4.0 img=1.0 sys=4.0
"cygfftw3-3.dll" v0.0 ts=2011/8/21 22:53
759k 2011/08/23 D:\cygwin\root\bin\cygfftw3f-3.dll - os=4.0 img=1.0 sys=4.0
"cygfftw3f-3.dll" v0.0 ts=2011/8/21 22:47
20k 2011/08/23 D:\cygwin\root\bin\cygfftw3f_threads-3.dll - os=4.0 img=1.0 sys=4.0
"cygfftw3f_threads-3.dll" v0.0 ts=2011/8/21 22:47
20k 2011/08/23 D:\cygwin\root\bin\cygfftw3_threads-3.dll - os=4.0 img=1.0 sys=4.0
"cygfftw3_threads-3.dll" v0.0 ts=2011/8/21 22:53
175k 2012/02/03 D:\cygwin\root\bin\cygfontconfig-1.dll - os=4.0 img=1.0 sys=4.0
"cygfontconfig-1.dll" v0.0 ts=2012/2/3 8:53
20k 2010/10/31 D:\cygwin\root\bin\cygfontenc-1.dll - os=4.0 img=1.0 sys=4.0
"cygfontenc-1.dll" v0.0 ts=2010/10/31 20:19
43k 2010/01/02 D:\cygwin\root\bin\cygform-10.dll - os=4.0 img=1.0 sys=4.0
"cygform-10.dll" v0.0 ts=2010/1/2 14:49
47k 2010/01/02 D:\cygwin\root\bin\cygformw-10.dll - os=4.0 img=1.0 sys=4.0
"cygformw-10.dll" v0.0 ts=2010/1/2 17:31
548k 2011/11/09 D:\cygwin\root\bin\cygfpx-1.dll - os=4.0 img=1.0 sys=4.0
"cygfpx-1.dll" v0.0 ts=2011/11/9 22:30
505k 2012/03/27 D:\cygwin\root\bin\cygfreetype-6.dll - os=4.0 img=1.0 sys=4.0
"cygfreetype-6.dll" v0.0 ts=2012/3/27 5:27
97k 2010/10/11 D:\cygwin\root\bin\cyggc-1.dll - os=4.0 img=1.0 sys=4.0
"cyggc-1.dll" v0.0 ts=2010/10/11 18:03
79k 2011/10/26 D:\cygwin\root\bin\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0
"cyggcc_s-1.dll" v0.0 ts=2011/10/23 14:15
449k 2011/05/20 D:\cygwin\root\bin\cyggcrypt-11.dll - os=4.0 img=1.0 sys=4.0
"cyggcrypt-11.dll" v0.0 ts=2011/5/20 3:29
227k 2011/11/16 D:\cygwin\root\bin\cyggd-2.dll - os=4.0 img=1.0 sys=4.0
"cyggd-2.dll" v0.0 ts=2011/11/16 10:53
19k 2009/02/26 D:\cygwin\root\bin\cyggdbm-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm-4.dll" v0.0 ts=2009/2/26 7:58
8k 2009/02/26 D:\cygwin\root\bin\cyggdbm_compat-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm_compat-4.dll" v0.0 ts=2009/2/26 7:58
554k 2012/05/02 D:\cygwin\root\bin\cyggdk-x11-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggdk-x11-2.0-0.dll" v0.0 ts=2012/5/2 8:48
201k 2012/05/02 D:\cygwin\root\bin\cyggdk_pixbuf-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggdk_pixbuf-2.0-0.dll" v0.0 ts=2012/5/2 4:28
713k 2011/10/26 D:\cygwin\root\bin\cyggfortran-3.dll - os=4.0 img=1.0 sys=4.0
"cyggfortran-3.dll" v0.0 ts=2011/10/23 15:15
29k 2009/03/23 D:\cygwin\root\bin\cyggif-4.dll - os=4.0 img=1.0 sys=4.0
"cyggif-4.dll" v0.0 ts=2009/3/23 19:55
1063k 2012/05/01 D:\cygwin\root\bin\cyggio-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggio-2.0-0.dll" v0.0 ts=2012/5/1 6:46
838k 2012/05/01 D:\cygwin\root\bin\cygglib-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygglib-2.0-0.dll" v0.0 ts=2012/5/1 6:41
11k 2012/05/01 D:\cygwin\root\bin\cyggmodule-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggmodule-2.0-0.dll" v0.0 ts=2012/5/1 6:43
317k 2011/07/31 D:\cygwin\root\bin\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0
"cyggmp-3.dll" v0.0 ts=2011/7/31 6:14
614k 2011/11/15 D:\cygwin\root\bin\cyggnutls-26.dll - os=4.0 img=1.0 sys=4.0
"cyggnutls-26.dll" v0.0 ts=2011/11/15 7:02
21k 2011/11/15 D:\cygwin\root\bin\cyggnutls-extra-26.dll - os=4.0 img=1.0 sys=4.0
"cyggnutls-extra-26.dll" v0.0 ts=2011/11/15 7:02
24k 2011/11/15 D:\cygwin\root\bin\cyggnutls-openssl-27.dll - os=4.0 img=1.0 sys=4.0
"cyggnutls-openssl-27.dll" v0.0 ts=2011/11/15 7:03
52k 2011/11/15 D:\cygwin\root\bin\cyggnutlsxx-27.dll - os=4.0 img=1.0 sys=4.0
"cyggnutlsxx-27.dll" v0.0 ts=2011/11/15 7:02
258k 2012/05/01 D:\cygwin\root\bin\cyggobject-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggobject-2.0-0.dll" v0.0 ts=2012/5/1 6:43
42k 2011/10/26 D:\cygwin\root\bin\cyggomp-1.dll - os=4.0 img=1.0 sys=4.0
"cyggomp-1.dll" v0.0 ts=2011/10/23 14:21
14k 2011/05/20 D:\cygwin\root\bin\cyggpg-error-0.dll - os=4.0 img=1.0 sys=4.0
"cyggpg-error-0.dll" v0.0 ts=2011/5/20 3:04
6546k 2011/11/10 D:\cygwin\root\bin\cyggs-9.dll - os=4.0 img=1.0 sys=4.0
"cyggs-9.dll" v0.0 ts=2011/11/10 22:56
1724k 2011/06/26 D:\cygwin\root\bin\cyggsl-0.dll - os=4.0 img=1.0 sys=4.0
"cyggsl-0.dll" v0.0 ts=2011/6/26 22:14
199k 2011/06/26 D:\cygwin\root\bin\cyggslcblas-0.dll - os=4.0 img=1.0 sys=4.0
"cyggslcblas-0.dll" v0.0 ts=2011/6/26 21:59
179k 2012/03/23 D:\cygwin\root\bin\cyggssapi-3.dll - os=4.0 img=1.0 sys=4.0
"cyggssapi-3.dll" v0.0 ts=2012/3/23 4:01
6k 2012/05/01 D:\cygwin\root\bin\cyggthread-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggthread-2.0-0.dll" v0.0 ts=2012/5/1 6:43
3746k 2012/05/02 D:\cygwin\root\bin\cyggtk-x11-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggtk-x11-2.0-0.dll" v0.0 ts=2012/5/2 8:53
10k 2012/03/23 D:\cygwin\root\bin\cygheimbase-1.dll - os=4.0 img=1.0 sys=4.0
"cygheimbase-1.dll" v0.0 ts=2012/3/23 3:51
20k 2012/03/23 D:\cygwin\root\bin\cygheimntlm-0.dll - os=4.0 img=1.0 sys=4.0
"cygheimntlm-0.dll" v0.0 ts=2012/3/23 3:58
25k 2012/05/04 D:\cygwin\root\bin\cyghistory7.dll - os=4.0 img=1.0 sys=4.0
"cyghistory7.dll" v0.0 ts=2012/5/4 22:07
211k 2012/03/23 D:\cygwin\root\bin\cyghx509-5.dll - os=4.0 img=1.0 sys=4.0
"cyghx509-5.dll" v0.0 ts=2012/3/23 3:54
74k 2010/10/31 D:\cygwin\root\bin\cygICE-6.dll - os=4.0 img=1.0 sys=4.0
"cygICE-6.dll" v0.0 ts=2010/10/31 20:18
358k 2012/04/14 D:\cygwin\root\bin\cygicons-0.dll - os=4.0 img=1.4 sys=4.0
"cygicons-0.dll" v0.0 ts=2012/4/14 2:48
985k 2011/10/16 D:\cygwin\root\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
"cygiconv-2.dll" v0.0 ts=2011/10/16 18:01
0k 2012/04/29 D:\cygwin\root\bin\cygicudata.dll - os=19625.30180 img=13857.17887 sys=63800.34
17852k 2011/07/26 D:\cygwin\root\bin\cygicudata48.dll - os=4.0 img=1.0 sys=4.0
"cygicudata48.dll" v0.0 ts=2011/7/26 12:36
0k 2012/04/29 D:\cygwin\root\bin\cygicui18n.dll - os=19625.30180 img=13857.17887 sys=63800.34
1809k 2011/07/26 D:\cygwin\root\bin\cygicui18n48.dll - os=4.0 img=1.0 sys=4.0
"cygicui18n48.dll" v0.0 ts=2011/7/26 11:53
0k 2012/04/29 D:\cygwin\root\bin\cygicuio.dll - os=19625.30180 img=13857.17887 sys=63800.34
35k 2011/07/26 D:\cygwin\root\bin\cygicuio48.dll - os=4.0 img=1.0 sys=4.0
"cygicuio48.dll" v0.0 ts=2011/7/26 11:56
0k 2012/04/29 D:\cygwin\root\bin\cygicule.dll - os=19625.30180 img=13857.17887 sys=63800.34
233k 2011/07/26 D:\cygwin\root\bin\cygicule48.dll - os=4.0 img=1.0 sys=4.0
"cygicule48.dll" v0.0 ts=2011/7/26 11:53
0k 2012/04/29 D:\cygwin\root\bin\cygiculx.dll - os=19625.30180 img=13857.17887 sys=63800.34
42k 2011/07/26 D:\cygwin\root\bin\cygiculx48.dll - os=4.0 img=1.0 sys=4.0
"cygiculx48.dll" v0.0 ts=2011/7/26 11:54
0k 2012/04/29 D:\cygwin\root\bin\cygicutest.dll - os=19625.30180 img=13857.17887 sys=63800.34
51k 2011/07/26 D:\cygwin\root\bin\cygicutest48.dll - os=4.0 img=1.0 sys=4.0
"cygicutest48.dll" v0.0 ts=2011/7/26 11:54
0k 2012/04/29 D:\cygwin\root\bin\cygicuuc.dll - os=19625.30180 img=13857.17887 sys=63800.34
1238k 2011/07/26 D:\cygwin\root\bin\cygicuuc48.dll - os=4.0 img=1.0 sys=4.0
"cygicuuc48.dll" v0.0 ts=2011/7/26 11:50
190k 2011/11/16 D:\cygwin\root\bin\cygidn-11.dll - os=4.0 img=1.0 sys=4.0
"cygidn-11.dll" v0.0 ts=2011/11/16 14:51
31k 2005/11/20 D:\cygwin\root\bin\cygintl-3.dll - os=4.0 img=1.0 sys=4.0
"cygintl-3.dll" v0.0 ts=2005/11/20 2:04
35k 2011/10/16 D:\cygwin\root\bin\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
"cygintl-8.dll" v0.0 ts=2011/10/16 6:38
242k 2012/02/03 D:\cygwin\root\bin\cygjasper-1.dll - os=4.0 img=1.0 sys=4.0
"cygjasper-1.dll" v0.0 ts=2012/2/3 14:31
47k 2009/12/23 D:\cygwin\root\bin\cygjbig-2.dll - os=4.0 img=1.0 sys=4.0
"cygjbig-2.dll" v0.0 ts=2009/12/23 16:59
200k 2010/08/09 D:\cygwin\root\bin\cygjpeg-8.dll - os=4.0 img=1.0 sys=4.0
"cygjpeg-8.dll" v0.0 ts=2010/8/9 8:02
20k 2012/03/23 D:\cygwin\root\bin\cygkafs-0.dll - os=4.0 img=1.0 sys=4.0
"cygkafs-0.dll" v0.0 ts=2012/3/23 3:58
77k 2012/04/26 D:\cygwin\root\bin\cygkpathsea-6.dll - os=4.0 img=1.0 sys=4.0
"cygkpathsea-6.dll" v0.0 ts=2012/4/27 0:04
372k 2012/03/23 D:\cygwin\root\bin\cygkrb5-26.dll - os=4.0 img=1.0 sys=4.0
"cygkrb5-26.dll" v0.0 ts=2012/3/23 3:57
42k 2012/03/26 D:\cygwin\root\bin\cyglber-2-3-0.dll - os=4.0 img=1.0 sys=4.0
"cyglber-2-3-0.dll" v0.0 ts=2012/3/26 12:12
173k 2010/06/25 D:\cygwin\root\bin\cyglcms-1.dll - os=4.0 img=1.0 sys=4.0
"cyglcms-1.dll" v0.0 ts=2010/6/25 10:50
232k 2011/11/09 D:\cygwin\root\bin\cyglcms2-2.dll - os=4.0 img=1.0 sys=4.0
"cyglcms2-2.dll" v0.0 ts=2011/11/9 17:22
193k 2012/03/26 D:\cygwin\root\bin\cygldap-2-3-0.dll - os=4.0 img=1.0 sys=4.0
"cygldap-2-3-0.dll" v0.0 ts=2012/3/26 13:47
206k 2012/03/26 D:\cygwin\root\bin\cygldap_r-2-3-0.dll - os=4.0 img=1.0 sys=4.0
"cygldap_r-2-3-0.dll" v0.0 ts=2012/3/26 13:48
12928k 2012/01/24 D:\cygwin\root\bin\cygLLVM-3.0.dll - os=4.0 img=1.0 sys=4.0
"cygLLVM-3.0.dll" v0.0 ts=2012/1/24 12:03
5k 2012/05/09 D:\cygwin\root\bin\cyglsa.dll - os=4.0 img=1.0 sys=4.0
"cyglsa.dll" v0.0 ts=2012/5/9 9:26
9k 2012/05/09 D:\cygwin\root\bin\cyglsa64.dll - os=5.2 img=0.0 sys=5.2
30k 2010/09/23 D:\cygwin\root\bin\cygltdl-7.dll - os=4.0 img=1.0 sys=4.0
"cygltdl-7.dll" v0.0 ts=2010/9/23 20:45
123k 2011/05/19 D:\cygwin\root\bin\cyglzma-5.dll - os=4.0 img=1.0 sys=4.0
"cyglzma-5.dll" v0.0 ts=2011/5/19 3:41
116k 2011/11/16 D:\cygwin\root\bin\cyglzo2-2.dll - os=4.0 img=1.0 sys=4.0
"cyglzo2-2.dll" v0.0 ts=2011/11/16 22:27
94k 2012/04/22 D:\cygwin\root\bin\cygmagic-1.dll - os=4.0 img=1.0 sys=4.0
"cygmagic-1.dll" v0.0 ts=2012/4/22 19:09
291k 2012/04/01 D:\cygwin\root\bin\cygMagick++-5.dll - os=4.0 img=1.0 sys=4.0
"cygMagick++-5.dll" v0.0 ts=2012/4/1 8:01
4211k 2012/04/01 D:\cygwin\root\bin\cygMagickCore-5.dll - os=4.0 img=1.0 sys=4.0
"cygMagickCore-5.dll" v0.0 ts=2012/4/1 7:59
1113k 2012/04/01 D:\cygwin\root\bin\cygMagickWand-5.dll - os=4.0 img=1.0 sys=4.0
"cygMagickWand-5.dll" v0.0 ts=2012/4/1 7:59
25k 2010/01/02 D:\cygwin\root\bin\cygmenu-10.dll - os=4.0 img=1.0 sys=4.0
"cygmenu-10.dll" v0.0 ts=2010/1/2 14:48
25k 2010/01/02 D:\cygwin\root\bin\cygmenuw-10.dll - os=4.0 img=1.0 sys=4.0
"cygmenuw-10.dll" v0.0 ts=2010/1/2 17:30
320k 2011/11/07 D:\cygwin\root\bin\cygming-1.dll - os=4.0 img=1.0 sys=4.0
"cygming-1.dll" v0.0 ts=2011/11/5 15:38
213k 2011/07/31 D:\cygwin\root\bin\cygmp-3.dll - os=4.0 img=1.0 sys=4.0
"cygmp-3.dll" v0.0 ts=2011/7/31 6:12
63k 2010/01/02 D:\cygwin\root\bin\cygncurses++-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++-10.dll" v0.0 ts=2010/1/2 15:00
63k 2010/01/02 D:\cygwin\root\bin\cygncurses++w-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++w-10.dll" v0.0 ts=2010/1/2 17:41
195k 2010/01/02 D:\cygwin\root\bin\cygncurses-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses-10.dll" v0.0 ts=2010/1/2 14:45
244k 2010/01/02 D:\cygwin\root\bin\cygncursesw-10.dll - os=4.0 img=1.0 sys=4.0
"cygncursesw-10.dll" v0.0 ts=2010/1/2 17:28
118k 2012/03/22 D:\cygwin\root\bin\cygneon-27.dll - os=4.0 img=1.0 sys=4.0
"cygneon-27.dll" v0.0 ts=2012/3/22 14:05
121k 2012/02/28 D:\cygwin\root\bin\cygopenjpeg-1.dll - os=4.0 img=1.5 sys=4.0
"cygopenjpeg-1.dll" v0.0 ts=2012/2/28 3:51
13k 2010/01/02 D:\cygwin\root\bin\cygpanel-10.dll - os=4.0 img=1.0 sys=4.0
"cygpanel-10.dll" v0.0 ts=2010/1/2 14:47
13k 2010/01/02 D:\cygwin\root\bin\cygpanelw-10.dll - os=4.0 img=1.0 sys=4.0
"cygpanelw-10.dll" v0.0 ts=2010/1/2 16:30
236k 2012/05/02 D:\cygwin\root\bin\cygpango-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpango-1.0-0.dll" v0.0 ts=2012/5/2 4:44
36k 2012/05/02 D:\cygwin\root\bin\cygpangocairo-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangocairo-1.0-0.dll" v0.0 ts=2012/5/2 4:45
186k 2012/05/02 D:\cygwin\root\bin\cygpangoft2-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangoft2-1.0-0.dll" v0.0 ts=2012/5/2 4:44
109k 2012/05/02 D:\cygwin\root\bin\cygpangox-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangox-1.0-0.dll" v0.0 ts=2012/5/2 4:44
23k 2012/05/02 D:\cygwin\root\bin\cygpangoxft-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangoxft-1.0-0.dll" v0.0 ts=2012/5/2 4:45
9k 2010/10/08 D:\cygwin\root\bin\cygpaper-1.dll - os=4.0 img=1.0 sys=4.0
"cygpaper-1.dll" v0.0 ts=2010/10/8 5:56
255k 2012/02/10 D:\cygwin\root\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
"cygpcre-0.dll" v0.0 ts=2012/2/10 10:24
259k 2012/04/30 D:\cygwin\root\bin\cygpcre-1.dll - os=4.0 img=1.0 sys=4.0
"cygpcre-1.dll" v0.0 ts=2012/4/30 7:52
1627k 2010/08/29 D:\cygwin\root\bin\cygperl5_10.dll - os=4.0 img=1.0 sys=4.0
"cygperl5_10.dll" v0.0 ts=2010/8/28 19:17
509k 2012/03/12 D:\cygwin\root\bin\cygpixman-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygpixman-1-0.dll" v0.0 ts=2012/3/12 11:06
988k 2010/01/22 D:\cygwin\root\bin\cygplotter-2.dll - os=4.0 img=1.0 sys=4.0
"cygplotter-2.dll" v0.0 ts=2010/1/22 22:01
249k 2011/07/28 D:\cygwin\root\bin\cygpng12.dll - os=4.0 img=1.0 sys=4.0
"cygpng12.dll" v0.0 ts=2011/7/28 6:20
129k 2011/07/28 D:\cygwin\root\bin\cygpng14-14.dll - os=4.0 img=1.0 sys=4.0
"cygpng14-14.dll" v0.0 ts=2011/7/28 6:55
1463k 2012/02/28 D:\cygwin\root\bin\cygpoppler-19.dll - os=4.0 img=19.0 sys=4.0
"cygpoppler-19.dll" v0.0 ts=2012/2/28 3:59
22k 2002/06/09 D:\cygwin\root\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
"cygpopt-0.dll" v0.0 ts=2002/6/9 6:45
103k 2009/01/07 D:\cygwin\root\bin\cygpq.dll - os=4.0 img=1.0 sys=4.0
"cygpq.dll" v0.0 ts=2009/1/7 16:46
122k 2011/10/05 D:\cygwin\root\bin\cygproxy-1.dll - os=4.0 img=1.0 sys=4.0
"cygproxy-1.dll" v0.0 ts=2011/10/5 5:45
335k 2012/04/02 D:\cygwin\root\bin\cygpstoedit-0.dll - os=4.0 img=1.0 sys=4.0
"cygpstoedit-0.dll" v0.0 ts=2012/4/2 10:36
32k 2012/04/26 D:\cygwin\root\bin\cygptexenc-1.dll - os=4.0 img=1.0 sys=4.0
"cygptexenc-1.dll" v0.0 ts=2012/4/27 0:05
162k 2012/05/04 D:\cygwin\root\bin\cygreadline7.dll - os=4.0 img=1.0 sys=4.0
"cygreadline7.dll" v0.0 ts=2012/5/4 22:07
51k 2012/03/23 D:\cygwin\root\bin\cygroken-18.dll - os=4.0 img=1.0 sys=4.0
"cygroken-18.dll" v0.0 ts=2012/3/23 3:51
187k 2012/05/02 D:\cygwin\root\bin\cygrsvg-2-2.dll - os=4.0 img=1.0 sys=4.0
"cygrsvg-2-2.dll" v0.0 ts=2012/5/2 4:44
84k 2010/07/02 D:\cygwin\root\bin\cygsasl2-2.dll - os=4.0 img=1.0 sys=4.0
"cygsasl2-2.dll" v0.0 ts=2010/7/2 4:19
55k 2012/03/16 D:\cygwin\root\bin\cygserf-0-1.dll - os=4.0 img=1.0 sys=4.0
"cygserf-0-1.dll" v0.0 ts=2012/3/16 2:14
59k 2012/03/21 D:\cygwin\root\bin\cygserf-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygserf-1-0.dll" v0.0 ts=2012/3/21 2:53
8k 2011/05/05 D:\cygwin\root\bin\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0
"cygsigsegv-2.dll" v0.0 ts=2011/5/5 8:33
25k 2010/10/31 D:\cygwin\root\bin\cygSM-6.dll - os=4.0 img=1.0 sys=4.0
"cygSM-6.dll" v0.0 ts=2010/10/31 20:24
1613k 2010/12/01 D:\cygwin\root\bin\cygsqlite3-0.dll - os=4.0 img=1.0 sys=4.0
"cygsqlite3-0.dll" v0.0 ts=2010/12/1 12:20
129k 2012/03/15 D:\cygwin\root\bin\cygssh2-1.dll - os=4.0 img=1.0 sys=4.0
"cygssh2-1.dll" v0.0 ts=2012/3/16 0:46
282k 2012/05/11 D:\cygwin\root\bin\cygssl-0.9.8.dll - os=4.0 img=1.0 sys=4.0
"cygssl-0.9.8.dll" v0.0 ts=2012/5/11 12:25
359k 2012/05/11 D:\cygwin\root\bin\cygssl-1.0.0.dll - os=4.0 img=1.0 sys=4.0
"cygssl-1.0.0.dll" v0.0 ts=2012/5/11 11:33
8k 2011/10/26 D:\cygwin\root\bin\cygssp-0.dll - os=4.0 img=1.0 sys=4.0
"cygssp-0.dll" v0.0 ts=2011/10/23 14:33
780k 2011/10/26 D:\cygwin\root\bin\cygstdc++-6.dll - os=4.0 img=1.0 sys=4.0
"cygstdc++-6.dll" v0.0 ts=2011/10/23 14:58
292k 2012/03/08 D:\cygwin\root\bin\cygsvn_client-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_client-1-0.dll" v0.0 ts=2012/3/8 20:43
39k 2012/03/08 D:\cygwin\root\bin\cygsvn_delta-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_delta-1-0.dll" v0.0 ts=2012/3/8 20:42
57k 2012/03/08 D:\cygwin\root\bin\cygsvn_diff-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_diff-1-0.dll" v0.0 ts=2012/3/8 20:42
20k 2012/03/08 D:\cygwin\root\bin\cygsvn_fs-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs-1-0.dll" v0.0 ts=2012/3/8 20:42
143k 2012/03/08 D:\cygwin\root\bin\cygsvn_fs_base-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs_base-1-0.dll" v0.0 ts=2012/3/8 20:42
133k 2012/03/08 D:\cygwin\root\bin\cygsvn_fs_fs-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs_fs-1-0.dll" v0.0 ts=2012/3/8 20:42
7k 2012/03/08 D:\cygwin\root\bin\cygsvn_fs_util-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs_util-1-0.dll" v0.0 ts=2012/3/8 20:42
34k 2012/03/08 D:\cygwin\root\bin\cygsvn_ra-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra-1-0.dll" v0.0 ts=2012/3/8 20:43
23k 2012/03/08 D:\cygwin\root\bin\cygsvn_ra_local-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_local-1-0.dll" v0.0 ts=2012/3/8 20:42
119k 2012/03/08 D:\cygwin\root\bin\cygsvn_ra_neon-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_neon-1-0.dll" v0.0 ts=2012/3/8 20:42
131k 2012/03/08 D:\cygwin\root\bin\cygsvn_ra_serf-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_serf-1-0.dll" v0.0 ts=2012/3/8 20:42
70k 2012/03/08 D:\cygwin\root\bin\cygsvn_ra_svn-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_svn-1-0.dll" v0.0 ts=2012/3/8 20:42
146k 2012/03/08 D:\cygwin\root\bin\cygsvn_repos-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_repos-1-0.dll" v0.0 ts=2012/3/8 20:42
290k 2012/03/08 D:\cygwin\root\bin\cygsvn_subr-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_subr-1-0.dll" v0.0 ts=2012/3/8 20:42
472k 2012/03/08 D:\cygwin\root\bin\cygsvn_wc-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_wc-1-0.dll" v0.0 ts=2012/3/8 20:42
228k 2012/02/02 D:\cygwin\root\bin\cygt1-5.dll - os=4.0 img=1.0 sys=4.0
"cygt1-5.dll" v0.0 ts=2012/2/2 13:17
57k 2012/03/22 D:\cygwin\root\bin\cygtasn1-3.dll - os=4.0 img=1.0 sys=4.0
"cygtasn1-3.dll" v0.0 ts=2012/3/22 7:33
26k 2011/10/04 D:\cygwin\root\bin\cygthai-0.dll - os=4.0 img=1.0 sys=4.0
"cygthai-0.dll" v0.0 ts=2011/10/4 21:22
48k 2010/01/02 D:\cygwin\root\bin\cygtic-10.dll - os=4.0 img=1.0 sys=4.0
"cygtic-10.dll" v0.0 ts=2010/1/2 14:45
48k 2010/01/02 D:\cygwin\root\bin\cygticw-10.dll - os=4.0 img=1.0 sys=4.0
"cygticw-10.dll" v0.0 ts=2010/1/2 17:28
347k 2011/04/08 D:\cygwin\root\bin\cygtiff-5.dll - os=4.0 img=1.0 sys=4.0
"cygtiff-5.dll" v0.0 ts=2011/4/8 2:27
9k 2011/04/08 D:\cygwin\root\bin\cygtiffxx-5.dll - os=4.0 img=1.0 sys=4.0
"cygtiffxx-5.dll" v0.0 ts=2011/4/8 2:27
41k 2011/08/16 D:\cygwin\root\bin\cygusb0.dll - os=4.0 img=1.0 sys=4.0
"cygusb0.dll" v0.0 ts=2011/8/16 19:28
13k 2012/02/29 D:\cygwin\root\bin\cyguuid-1.dll - os=4.0 img=1.0 sys=4.0
"cyguuid-1.dll" v0.0 ts=2012/2/29 3:56
157k 2012/03/23 D:\cygwin\root\bin\cygwind-0.dll - os=4.0 img=1.0 sys=4.0
"cygwind-0.dll" v0.0 ts=2012/3/23 3:52
28k 2010/03/28 D:\cygwin\root\bin\cygwrap-0.dll - os=4.0 img=1.0 sys=4.0
"cygwrap-0.dll" v0.0 ts=2010/3/28 10:02
1045k 2011/08/22 D:\cygwin\root\bin\cygX11-6.dll - os=4.0 img=1.0 sys=4.0
"cygX11-6.dll" v0.0 ts=2011/8/22 9:25
11k 2010/08/03 D:\cygwin\root\bin\cygXau-6.dll - os=4.0 img=1.0 sys=4.0
"cygXau-6.dll" v0.0 ts=2010/8/3 1:32
337k 2011/02/04 D:\cygwin\root\bin\cygXaw-7.dll - os=4.0 img=1.0 sys=4.0
"cygXaw-7.dll" v0.0 ts=2011/2/4 7:02
75k 2010/12/21 D:\cygwin\root\bin\cygxcb-1.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-1.dll" v0.0 ts=2010/12/21 1:36
22k 2010/12/21 D:\cygwin\root\bin\cygxcb-render-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-render-0.dll" v0.0 ts=2010/12/21 1:36
8k 2010/12/21 D:\cygwin\root\bin\cygxcb-shm-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-shm-0.dll" v0.0 ts=2010/12/21 1:36
10k 2010/11/01 D:\cygwin\root\bin\cygXcomposite-1.dll - os=4.0 img=1.0 sys=4.0
"cygXcomposite-1.dll" v0.0 ts=2010/11/1 1:59
30k 2011/08/22 D:\cygwin\root\bin\cygXcursor-1.dll - os=4.0 img=1.0 sys=4.0
"cygXcursor-1.dll" v0.0 ts=2011/8/22 18:26
11k 2010/08/03 D:\cygwin\root\bin\cygXdamage-1.dll - os=4.0 img=1.0 sys=4.0
"cygXdamage-1.dll" v0.0 ts=2010/8/3 5:25
17k 2010/10/31 D:\cygwin\root\bin\cygXdmcp-6.dll - os=4.0 img=1.0 sys=4.0
"cygXdmcp-6.dll" v0.0 ts=2010/10/31 20:29
52k 2011/05/23 D:\cygwin\root\bin\cygXext-6.dll - os=4.0 img=1.0 sys=4.0
"cygXext-6.dll" v0.0 ts=2011/5/23 9:32
17k 2011/03/17 D:\cygwin\root\bin\cygXfixes-3.dll - os=4.0 img=1.0 sys=4.0
"cygXfixes-3.dll" v0.0 ts=2011/3/17 2:50
66k 2010/11/01 D:\cygwin\root\bin\cygXft-2.dll - os=4.0 img=1.0 sys=4.0
"cygXft-2.dll" v0.0 ts=2010/11/1 2:10
46k 2011/12/21 D:\cygwin\root\bin\cygXi-6.dll - os=4.0 img=1.0 sys=4.0
"cygXi-6.dll" v0.0 ts=2011/12/21 5:39
8k 2010/11/01 D:\cygwin\root\bin\cygXinerama-1.dll - os=4.0 img=1.0 sys=4.0
"cygXinerama-1.dll" v0.0 ts=2010/11/1 2:11
1071k 2012/02/29 D:\cygwin\root\bin\cygxml2-2.dll - os=4.0 img=1.0 sys=4.0
"cygxml2-2.dll" v0.0 ts=2012/2/29 21:04
75k 2010/11/01 D:\cygwin\root\bin\cygXmu-6.dll - os=4.0 img=1.0 sys=4.0
"cygXmu-6.dll" v0.0 ts=2010/11/1 2:19
53k 2010/11/01 D:\cygwin\root\bin\cygXpm-4.dll - os=4.0 img=1.0 sys=4.0
"cygXpm-4.dll" v0.0 ts=2010/11/1 2:19
25k 2011/08/22 D:\cygwin\root\bin\cygXrandr-2.dll - os=4.0 img=1.0 sys=4.0
"cygXrandr-2.dll" v0.0 ts=2011/8/22 17:55
32k 2010/08/03 D:\cygwin\root\bin\cygXrender-1.dll - os=4.0 img=1.0 sys=4.0
"cygXrender-1.dll" v0.0 ts=2010/8/3 5:48
278k 2011/06/07 D:\cygwin\root\bin\cygXt-6.dll - os=4.0 img=1.0 sys=4.0
"cygXt-6.dll" v0.0 ts=2011/6/7 4:40
71k 2012/05/13 D:\cygwin\root\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
"cygz.dll" v0.0 ts=2012/5/13 5:11
22k 2010/12/31 D:\cygwin\root\bin\cygzzip-0-13.dll - os=4.0 img=1.0 sys=4.0
"cygzzip-0-13.dll" v0.0 ts=2010/12/31 7:29
11k 2010/12/31 D:\cygwin\root\bin\cygzzipfseeko-0-13.dll - os=4.0 img=1.0 sys=4.0
"cygzzipfseeko-0-13.dll" v0.0 ts=2010/12/31 7:29
12k 2010/12/31 D:\cygwin\root\bin\cygzzipmmapped-0-13.dll - os=4.0 img=1.0 sys=4.0
"cygzzipmmapped-0-13.dll" v0.0 ts=2010/12/31 7:29
7k 2010/12/31 D:\cygwin\root\bin\cygzzipwrap-0-13.dll - os=4.0 img=1.0 sys=4.0
"cygzzipwrap-0-13.dll" v0.0 ts=2010/12/31 7:29
2235k 2012/05/09 D:\cygwin\root\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2012/5/9 9:25
Cygwin DLL version info:
DLL version: 1.7.15
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 260
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5
364k 2012/04/27 D:\cygwin\root\lib\lapack\cygblas-0.dll - os=4.0 img=1.0 sys=4.0
"cygblas-0.dll" v0.0 ts=2012/4/27 21:18
4497k 2012/04/27 D:\cygwin\root\lib\lapack\cyglapack-0.dll - os=4.0 img=1.0 sys=4.0
"cyglapack-0.dll" v0.0 ts=2012/4/27 21:18
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-15 12:17 ` Filipp Gunbin
@ 2012-05-15 12:27 ` Filipp Gunbin
2012-05-15 13:37 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Filipp Gunbin @ 2012-05-15 12:27 UTC (permalink / raw)
To: cygwin
Sorry, the message disappeared for some reason. Here it is.
Filipp
Ken Brown writes:
> On 5/15/2012 6:57 AM, Filipp Gunbin wrote:
>> I tried emacs-24, but with no luck: after hitting `C-x C-f C-g' emacs
>> almost always dumps core. I had to revert to emacs-23 for now (using
>> the workaround with emacs-nox, thanks for it!).
>>
>> Sorry for the poor report, probably I could provide more details if
>> needed.
>
> Please do provide details, including the cygcheck output requested at
>
> http://cygwin.com/problems.html
>
> Give a complete recipe for reproducing the problem, preferably
> starting with `emacs -Q'.
>
> Thanks.
>
> Ken
>
>
Attached the output from cygcheck. For some reason it dumped core too:
$ cygcheck -s -v -r > /tmp/cygcheck.out
Segmentation fault
Other programs seem to work normally (though I haven't tried many).
The steps to reproduce the problem with emacs-24 are:
1. start emacs: emacs -nw -Q
2. C-x C-f C-g
Here emacs either dumps core or hangs.
I didn't have any problems with other Cygwin programs in the last
months.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-15 12:27 ` Filipp Gunbin
@ 2012-05-15 13:37 ` Ken Brown
2012-05-15 14:28 ` Filipp Gunbin
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-15 13:37 UTC (permalink / raw)
To: cygwin
On 5/15/2012 8:26 AM, Filipp Gunbin wrote:
> Sorry, the message disappeared for some reason. Here it is.
>
> Filipp
>
>
> Ken Brown writes:
>
>> On 5/15/2012 6:57 AM, Filipp Gunbin wrote:
>>> I tried emacs-24, but with no luck: after hitting `C-x C-f C-g' emacs
>>> almost always dumps core. I had to revert to emacs-23 for now (using
>>> the workaround with emacs-nox, thanks for it!).
>>>
>>> Sorry for the poor report, probably I could provide more details if
>>> needed.
>>
>> Please do provide details, including the cygcheck output requested at
>>
>> http://cygwin.com/problems.html
>>
>> Give a complete recipe for reproducing the problem, preferably
>> starting with `emacs -Q'.
>>
>> Thanks.
>>
>> Ken
>>
>>
>
> Attached the output from cygcheck. For some reason it dumped core too:
>
> $ cygcheck -s -v -r> /tmp/cygcheck.out
> Segmentation fault
I wonder if this is the same problem as the one that was reported in
http://cygwin.com/ml/cygwin/2012-05/msg00292.html
and fixed in the 2012-05-14 snapshot.
> Other programs seem to work normally (though I haven't tried many).
>
> The steps to reproduce the problem with emacs-24 are:
>
> 1. start emacs: emacs -nw -Q
> 2. C-x C-f C-g
> Here emacs either dumps core or hangs.
I can reproduce this on XP but not on Windows 7. And I see from your
(partial) cygcheck output that you're running Vista. I'll try to debug
this on my XP system.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-15 13:37 ` Ken Brown
@ 2012-05-15 14:28 ` Filipp Gunbin
2012-05-16 16:04 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Filipp Gunbin @ 2012-05-15 14:28 UTC (permalink / raw)
To: Ken Brown; +Cc: cygwin
>
> I wonder if this is the same problem as the one that was reported in
>
> http://cygwin.com/ml/cygwin/2012-05/msg00292.html
>
> and fixed in the 2012-05-14 snapshot.
I tried that snapshot, but it didn't help. Both cygcheck and emacs-24 still dump core.
>
> I can reproduce this on XP but not on Windows 7. And I see from your
> (partial) cygcheck output that you're running Vista. I'll try to debug
> this on my XP system.
Ok, 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-15 14:28 ` Filipp Gunbin
@ 2012-05-16 16:04 ` Ken Brown
2012-05-21 8:12 ` Filipp Gunbin
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-16 16:04 UTC (permalink / raw)
To: cygwin
On 5/15/2012 10:27 AM, Filipp Gunbin wrote:
[Ken Brown wrote:]
>> I can reproduce this on XP but not on Windows 7. And I see from your
>> (partial) cygcheck output that you're running Vista. I'll try to debug
>> this on my XP system.
I think I've fixed this, in both emacs-23 and emacs-24. Please retest
once I announce that the new releases have been uploaded (23.4-2 and
24.0.96-2).
Thanks.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-16 16:04 ` Ken Brown
@ 2012-05-21 8:12 ` Filipp Gunbin
2012-05-21 8:50 ` Filipp Gunbin
0 siblings, 1 reply; 36+ messages in thread
From: Filipp Gunbin @ 2012-05-21 8:12 UTC (permalink / raw)
To: Ken Brown; +Cc: cygwin
> From: Ken Brown
>
> I think I've fixed this, in both emacs-23 and emacs-24. Please retest
> once I announce that the new releases have been uploaded (23.4-2 and
> 24.0.96-2).
>
I started emacs-23.4.2 as usual (emacs -nw) and it did not hang.
emacs-24.0.96-2 also seems to work normally, I've used it for some time without problems and will continue with it.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-21 8:12 ` Filipp Gunbin
@ 2012-05-21 8:50 ` Filipp Gunbin
2012-05-21 10:03 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Filipp Gunbin @ 2012-05-21 8:50 UTC (permalink / raw)
To: cygwin
> From: Filipp Gunbin
>
> I started emacs-23.4.2 as usual (emacs -nw) and it did not hang.
>
> emacs-24.0.96-2 also seems to work normally, I've used it for some time without problems and will continue with it.
>
emacs-24.0.96-2 crashes when I am doing the following:
1) emacs -Q -nw
2) M-x shell
3) C-x C-f C-g
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-21 8:50 ` Filipp Gunbin
@ 2012-05-21 10:03 ` Ken Brown
2012-05-21 15:32 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-21 10:03 UTC (permalink / raw)
To: cygwin
On 5/21/2012 4:50 AM, Filipp Gunbin wrote:
> emacs-24.0.96-2 crashes when I am doing the following:
>
> 1) emacs -Q -nw
> 2) M-x shell
> 3) C-x C-f C-g
I can reproduce this. I'll try again to fix it.
Thanks for the report.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-21 10:03 ` Ken Brown
@ 2012-05-21 15:32 ` Ken Brown
2012-05-21 16:29 ` Corinna Vinschen
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-21 15:32 UTC (permalink / raw)
To: cygwin
On 5/21/2012 6:02 AM, Ken Brown wrote:
> On 5/21/2012 4:50 AM, Filipp Gunbin wrote:
>> emacs-24.0.96-2 crashes when I am doing the following:
>>
>> 1) emacs -Q -nw
>> 2) M-x shell
>> 3) C-x C-f C-g
>
> I can reproduce this. I'll try again to fix it.
I've discovered something strange by running emacs under gdb. If I
start emacs-24 in a terminal (but not under X) and start a shell as you
did, then every press of C-g creates a new thread, and these are never
destroyed. I'm pretty sure the threads are created by Cygwin, not by emacs.
cgf and/or Corinna, could you take a look? I wonder if this is related
to the pthread problems that have been reported in a different
(mailing-list) thread. Here are simplified steps for reproducing:
1. Install emacs-24.0.96-2.
2. In a Cygwin terminal with DISPLAY not set, run 'emacs -Q'.
3. Type <Alt-x>shell<return>
4. Repeatedly press C-g until emacs crashes.
Thanks.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-21 15:32 ` Ken Brown
@ 2012-05-21 16:29 ` Corinna Vinschen
2012-05-21 18:51 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-21 16:29 UTC (permalink / raw)
To: cygwin
On May 21 11:31, Ken Brown wrote:
> On 5/21/2012 6:02 AM, Ken Brown wrote:
> >On 5/21/2012 4:50 AM, Filipp Gunbin wrote:
> >>emacs-24.0.96-2 crashes when I am doing the following:
> >>
> >>1) emacs -Q -nw
> >>2) M-x shell
> >>3) C-x C-f C-g
> >
> >I can reproduce this. I'll try again to fix it.
>
> I've discovered something strange by running emacs under gdb. If I
> start emacs-24 in a terminal (but not under X) and start a shell as
> you did, then every press of C-g creates a new thread, and these are
> never destroyed. I'm pretty sure the threads are created by Cygwin,
> not by emacs.
What does C-g mean in Emacs? What's it supposed to do? Does it
call select or poll?
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-21 16:29 ` Corinna Vinschen
@ 2012-05-21 18:51 ` Ken Brown
2012-05-22 11:29 ` Corinna Vinschen
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-21 18:51 UTC (permalink / raw)
To: cygwin
On 5/21/2012 12:29 PM, Corinna Vinschen wrote:
> On May 21 11:31, Ken Brown wrote:
>> On 5/21/2012 6:02 AM, Ken Brown wrote:
>>> On 5/21/2012 4:50 AM, Filipp Gunbin wrote:
>>>> emacs-24.0.96-2 crashes when I am doing the following:
>>>>
>>>> 1) emacs -Q -nw
>>>> 2) M-x shell
>>>> 3) C-x C-f C-g
>>>
>>> I can reproduce this. I'll try again to fix it.
>>
>> I've discovered something strange by running emacs under gdb. If I
>> start emacs-24 in a terminal (but not under X) and start a shell as
>> you did, then every press of C-g creates a new thread, and these are
>> never destroyed. I'm pretty sure the threads are created by Cygwin,
>> not by emacs.
>
> What does C-g mean in Emacs? What's it supposed to do? Does it
> call select or poll?
It's supposed to quit whatever operation is in progress. It doesn't
call select or poll. In the situation of Filipp's instructions above,
C-x C-f has caused emacs to prompt for a file name, and C-g should
interrupt that. It also rings the the terminal bell and prints "Quit"
in the echo area at the bottom of the screen.
The situation in my instructions is slightly different. Prior to the
user pressing C-g, emacs is running its idle loop, in which it
repeatedly calls select to see if there's any event it needs to respond
to. When C-g is pressed, select returns and emacs reacts to the
keypress. In this case there's nothing to do but ring the terminal bell
and print "Quit".
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-21 18:51 ` Ken Brown
@ 2012-05-22 11:29 ` Corinna Vinschen
2012-05-22 11:42 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-22 11:29 UTC (permalink / raw)
To: cygwin
On May 21 14:51, Ken Brown wrote:
> On 5/21/2012 12:29 PM, Corinna Vinschen wrote:
> >On May 21 11:31, Ken Brown wrote:
> >>On 5/21/2012 6:02 AM, Ken Brown wrote:
> >>>On 5/21/2012 4:50 AM, Filipp Gunbin wrote:
> >>>>emacs-24.0.96-2 crashes when I am doing the following:
> >>>>
> >>>>1) emacs -Q -nw
> >>>>2) M-x shell
> >>>>3) C-x C-f C-g
> >>>
> >>>I can reproduce this. I'll try again to fix it.
> >>
> >>I've discovered something strange by running emacs under gdb. If I
> >>start emacs-24 in a terminal (but not under X) and start a shell as
> >>you did, then every press of C-g creates a new thread, and these are
> >>never destroyed. I'm pretty sure the threads are created by Cygwin,
> >>not by emacs.
> >
> >What does C-g mean in Emacs? What's it supposed to do? Does it
> >call select or poll?
>
> It's supposed to quit whatever operation is in progress. It doesn't
> call select or poll. In the situation of Filipp's instructions
> above, C-x C-f has caused emacs to prompt for a file name, and C-g
> should interrupt that. It also rings the the terminal bell and
> prints "Quit" in the echo area at the bottom of the screen.
>
> The situation in my instructions is slightly different. Prior to
> the user pressing C-g, emacs is running its idle loop, in which it
> repeatedly calls select to see if there's any event it needs to
> respond to. When C-g is pressed, select returns and emacs reacts
> to the keypress. In this case there's nothing to do but ring the
> terminal bell and print "Quit".
Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd
or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I
try it under Cygwin 1.7.15 or current CVS.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-22 11:29 ` Corinna Vinschen
@ 2012-05-22 11:42 ` Ken Brown
2012-05-22 13:42 ` Corinna Vinschen
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-22 11:42 UTC (permalink / raw)
To: cygwin
On 5/22/2012 7:28 AM, Corinna Vinschen wrote:
> On May 21 14:51, Ken Brown wrote:
>> On 5/21/2012 12:29 PM, Corinna Vinschen wrote:
>>> On May 21 11:31, Ken Brown wrote:
>>>> On 5/21/2012 6:02 AM, Ken Brown wrote:
>>>>> On 5/21/2012 4:50 AM, Filipp Gunbin wrote:
>>>>>> emacs-24.0.96-2 crashes when I am doing the following:
>>>>>>
>>>>>> 1) emacs -Q -nw
>>>>>> 2) M-x shell
>>>>>> 3) C-x C-f C-g
>>>>>
>>>>> I can reproduce this. I'll try again to fix it.
>>>>
>>>> I've discovered something strange by running emacs under gdb. If I
>>>> start emacs-24 in a terminal (but not under X) and start a shell as
>>>> you did, then every press of C-g creates a new thread, and these are
>>>> never destroyed. I'm pretty sure the threads are created by Cygwin,
>>>> not by emacs.
>>>
>>> What does C-g mean in Emacs? What's it supposed to do? Does it
>>> call select or poll?
>>
>> It's supposed to quit whatever operation is in progress. It doesn't
>> call select or poll. In the situation of Filipp's instructions
>> above, C-x C-f has caused emacs to prompt for a file name, and C-g
>> should interrupt that. It also rings the the terminal bell and
>> prints "Quit" in the echo area at the bottom of the screen.
>>
>> The situation in my instructions is slightly different. Prior to
>> the user pressing C-g, emacs is running its idle loop, in which it
>> repeatedly calls select to see if there's any event it needs to
>> respond to. When C-g is pressed, select returns and emacs reacts
>> to the keypress. In this case there's nothing to do but ring the
>> terminal bell and print "Quit".
>
> Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd
> or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I
> try it under Cygwin 1.7.15 or current CVS.
That's strange. All my tests were done in mintty. Would it help if I
sent some strace output and/or a gdb backtrace? I assumed you could get
those (or at least the strace output) yourself, and I didn't want to
spam the list.
Ken
P.S. BTW, I tested today's snapshot, and the problem is still there.
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-22 11:42 ` Ken Brown
@ 2012-05-22 13:42 ` Corinna Vinschen
2012-05-22 13:50 ` Corinna Vinschen
0 siblings, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-22 13:42 UTC (permalink / raw)
To: cygwin
On May 22 07:42, Ken Brown wrote:
> On 5/22/2012 7:28 AM, Corinna Vinschen wrote:
> >On May 21 14:51, Ken Brown wrote:
> >>On 5/21/2012 12:29 PM, Corinna Vinschen wrote:
> >>>On May 21 11:31, Ken Brown wrote:
> >>>>On 5/21/2012 6:02 AM, Ken Brown wrote:
> >>>>I've discovered something strange by running emacs under gdb. If I
> >>>>start emacs-24 in a terminal (but not under X) and start a shell as
> >>>>you did, then every press of C-g creates a new thread, and these are
> >>>>never destroyed. I'm pretty sure the threads are created by Cygwin,
> >>>>not by emacs.
> >>>[...]
> >Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd
> >or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I
> >try it under Cygwin 1.7.15 or current CVS.
>
> That's strange. All my tests were done in mintty. Would it help if
> I sent some strace output and/or a gdb backtrace? I assumed you
> could get those (or at least the strace output) yourself, and I
> didn't want to spam the list.
>
> Ken
>
> P.S. BTW, I tested today's snapshot, and the problem is still there.
I doubt that an strace is sufficient, but you could send me one created
with the latest snapshot off-list, to the address I'm using in the
Changelogs. Please point out the places which seem suspicious to you.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-22 13:42 ` Corinna Vinschen
@ 2012-05-22 13:50 ` Corinna Vinschen
2012-05-23 12:01 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-22 13:50 UTC (permalink / raw)
To: cygwin
On May 22 15:41, Corinna Vinschen wrote:
> On May 22 07:42, Ken Brown wrote:
> > On 5/22/2012 7:28 AM, Corinna Vinschen wrote:
> > >On May 21 14:51, Ken Brown wrote:
> > >>On 5/21/2012 12:29 PM, Corinna Vinschen wrote:
> > >>>On May 21 11:31, Ken Brown wrote:
> > >>>>On 5/21/2012 6:02 AM, Ken Brown wrote:
> > >>>>I've discovered something strange by running emacs under gdb. If I
> > >>>>start emacs-24 in a terminal (but not under X) and start a shell as
> > >>>>you did, then every press of C-g creates a new thread, and these are
> > >>>>never destroyed. I'm pretty sure the threads are created by Cygwin,
> > >>>>not by emacs.
> > >>>[...]
> > >Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd
> > >or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I
> > >try it under Cygwin 1.7.15 or current CVS.
> >
> > That's strange. All my tests were done in mintty. Would it help if
> > I sent some strace output and/or a gdb backtrace? I assumed you
> > could get those (or at least the strace output) yourself, and I
> > didn't want to spam the list.
> >
> > Ken
> >
> > P.S. BTW, I tested today's snapshot, and the problem is still there.
>
> I doubt that an strace is sufficient, but you could send me one created
> with the latest snapshot off-list, to the address I'm using in the
> Changelogs. Please point out the places which seem suspicious to you.
Ouch! Hang on. I didn't test with the 24.x version, but with the
old one. Sorry about that. Now I can reproduce the SEGV.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-22 13:50 ` Corinna Vinschen
@ 2012-05-23 12:01 ` Ken Brown
2012-05-23 13:24 ` Ken Brown
2012-05-23 15:54 ` Corinna Vinschen
0 siblings, 2 replies; 36+ messages in thread
From: Ken Brown @ 2012-05-23 12:01 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
On 5/22/2012 9:49 AM, Corinna Vinschen wrote:
> On May 22 15:41, Corinna Vinschen wrote:
>> On May 22 07:42, Ken Brown wrote:
>>> On 5/22/2012 7:28 AM, Corinna Vinschen wrote:
>>>> On May 21 14:51, Ken Brown wrote:
>>>>> On 5/21/2012 12:29 PM, Corinna Vinschen wrote:
>>>>>> On May 21 11:31, Ken Brown wrote:
>>>>>>> On 5/21/2012 6:02 AM, Ken Brown wrote:
>>>>>>> I've discovered something strange by running emacs under gdb. If I
>>>>>>> start emacs-24 in a terminal (but not under X) and start a shell as
>>>>>>> you did, then every press of C-g creates a new thread, and these are
>>>>>>> never destroyed. I'm pretty sure the threads are created by Cygwin,
>>>>>>> not by emacs.
I've gotten some more information from gdb. The crash occurs after a
call to _longjmp, and gdb shows a new thread created right at that
point. This doesn't happen when I run emacs under X instead of in
mintty. Here's an excerpt from the gdb session, with the strange thread
marked:
$ gdb -p 6492
[...]
Attaching to process 6048
[New Thread 6048.0x668]
[New Thread 6048.0x1a5c]
[New Thread 6048.0x2630]
[New Thread 6048.0x1d14]
Reading symbols from /home/kbrown/src/emacs/test-nox/src/emacs.exe...done.
[...]
(gdb) b unwind_to_catch
Breakpoint 3 at 0x52aca2: file eval.c, line 1234.
(gdb) c
Continuing.
[Switching to Thread 6048.0x668]
[...]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12985830) at
eval.c:1234
1234 catch->val = value;
(gdb) n
[...]
1272 _longjmp (catch->jmp, 1);
(gdb)
[New Thread 6048.0x1e04] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Program received signal SIGSEGV, Segmentation fault.
0x76f3f8b1 in ntdll!RtlUpdateClonedSRWLock () from
/c/windows/SysWOW64/ntdll.dll
(gdb) thread apply all bt full
[compressed output attached]
And here's the stackdump:
Exception: STATUS_ACCESS_VIOLATION at eip=610CFA77
eax=80106D50 ebx=34322D73 ecx=766231E7 edx=00000000 esi=00000001
edi=00000050
ebp=048FACC8 esp=048FACA0
program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
6492, thread pipesel
Ken
[-- Attachment #2: bt.out.bz2 --]
[-- Type: application/octet-stream, Size: 2904 bytes --]
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-23 12:01 ` Ken Brown
@ 2012-05-23 13:24 ` Ken Brown
2012-05-23 15:54 ` Corinna Vinschen
1 sibling, 0 replies; 36+ messages in thread
From: Ken Brown @ 2012-05-23 13:24 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
On 5/22/2012 9:49 AM, Corinna Vinschen wrote:
> On May 22 15:41, Corinna Vinschen wrote:
>> On May 22 07:42, Ken Brown wrote:
>>> On 5/22/2012 7:28 AM, Corinna Vinschen wrote:
>>>> On May 21 14:51, Ken Brown wrote:
>>>>> On 5/21/2012 12:29 PM, Corinna Vinschen wrote:
>>>>>> On May 21 11:31, Ken Brown wrote:
>>>>>>> On 5/21/2012 6:02 AM, Ken Brown wrote:
>>>>>>> I've discovered something strange by running emacs under gdb. If I
>>>>>>> start emacs-24 in a terminal (but not under X) and start a shell as
>>>>>>> you did, then every press of C-g creates a new thread, and these are
>>>>>>> never destroyed. I'm pretty sure the threads are created by Cygwin,
>>>>>>> not by emacs.
I've gotten some more information from gdb. The crash occurs after a
call to _longjmp, and gdb shows a new thread created right at that
point. This doesn't happen when I run emacs under X instead of in
mintty. Here's an excerpt from the gdb session, with the strange thread
marked:
$ gdb -p 6492
[...]
Attaching to process 6048
[New Thread 6048.0x668]
[New Thread 6048.0x1a5c]
[New Thread 6048.0x2630]
[New Thread 6048.0x1d14]
Reading symbols from /home/kbrown/src/emacs/test-nox/src/emacs.exe...done.
[...]
(gdb) b unwind_to_catch
Breakpoint 3 at 0x52aca2: file eval.c, line 1234.
(gdb) c
Continuing.
[Switching to Thread 6048.0x668]
[...]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12985830) at
eval.c:1234
1234 catch->val = value;
(gdb) n
[...]
1272 _longjmp (catch->jmp, 1);
(gdb)
[New Thread 6048.0x1e04] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Program received signal SIGSEGV, Segmentation fault.
0x76f3f8b1 in ntdll!RtlUpdateClonedSRWLock () from
/c/windows/SysWOW64/ntdll.dll
(gdb) thread apply all bt full
[compressed output attached]
And here's the stackdump:
Exception: STATUS_ACCESS_VIOLATION at eip=610CFA77
eax=80106D50 ebx=34322D73 ecx=766231E7 edx=00000000 esi=00000001
edi=00000050
ebp=048FACC8 esp=048FACA0
program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
6492, thread pipesel
Ken
[-- Attachment #2: bt.out.bz2 --]
[-- Type: application/octet-stream, Size: 2904 bytes --]
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-23 12:01 ` Ken Brown
2012-05-23 13:24 ` Ken Brown
@ 2012-05-23 15:54 ` Corinna Vinschen
2012-05-23 16:03 ` Ken Brown
1 sibling, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-23 15:54 UTC (permalink / raw)
To: cygwin
On May 23 08:00, Ken Brown wrote:
> I've gotten some more information from gdb. The crash occurs after
> a call to _longjmp, and gdb shows a new thread created right at that
> point. This doesn't happen when I run emacs under X instead of in
> mintty. Here's an excerpt from the gdb session, with the strange
> thread marked:
>
> $ gdb -p 6492
> [...]
> Attaching to process 6048
> [New Thread 6048.0x668]
> [New Thread 6048.0x1a5c]
> [New Thread 6048.0x2630]
> [New Thread 6048.0x1d14]
> Reading symbols from /home/kbrown/src/emacs/test-nox/src/emacs.exe...done.
> [...]
> (gdb) b unwind_to_catch
> Breakpoint 3 at 0x52aca2: file eval.c, line 1234.
> (gdb) c
> Continuing.
> [Switching to Thread 6048.0x668]
> [...]
> Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12985830) at
> eval.c:1234
> 1234 catch->val = value;
> (gdb) n
> [...]
> 1272 _longjmp (catch->jmp, 1);
> (gdb)
> [New Thread 6048.0x1e04] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> Program received signal SIGSEGV, Segmentation fault.
I don't know what this has to do with the longjmp, but the thread
which gets crated right after pressing Ctrl-G is due to a select or
poll call. The descriptor is a pipe, fifo, or pty.
> 0x76f3f8b1 in ntdll!RtlUpdateClonedSRWLock () from
> /c/windows/SysWOW64/ntdll.dll
> (gdb) thread apply all bt full
>
> [compressed output attached]
>
> And here's the stackdump:
>
> Exception: STATUS_ACCESS_VIOLATION at eip=610CFA77
The problem with stackdumps is that the addresses only make sense
for a single version of the Cygwin DLL. If that's a self-built
version, what does `addr2line -e /bin/cygwin1.dll 610CFA77' print?
If it's 1.7.15, please install the cygwin-debug package and call
the same addr2line.
I assume the address corresponds to select.cc, line 625, but I'm
quite busy with the pthread_cancel stuff, so I didn't look deeper
into this problem.
> eax=80106D50 ebx=34322D73 ecx=766231E7 edx=00000000 esi=00000001
> edi=00000050
> ebp=048FACC8 esp=048FACA0
> program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
> 6492, thread pipesel
^^^^^^^
Yes, that's exactly the created thread. Do you happen to know what
kind of descriptor has been given to select at this point? Is that
a pty master side perhaps?
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-23 15:54 ` Corinna Vinschen
@ 2012-05-23 16:03 ` Ken Brown
2012-05-23 16:07 ` Corinna Vinschen
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-23 16:03 UTC (permalink / raw)
To: cygwin
On 5/23/2012 10:15 AM, Corinna Vinschen wrote:
> On May 23 08:00, Ken Brown wrote:
> I don't know what this has to do with the longjmp, but the thread
> which gets crated right after pressing Ctrl-G is due to a select or
> poll call. The descriptor is a pipe, fifo, or pty.
After the longjmp, emacs has finished processing the C-g and goes back
into its idle loop, in which it repeatedly calls select.
gdb doesn't normally show the threads created by select. If it did, it
would always create voluminous output. Can you infer anything from the
fact that it shows this one?
> The problem with stackdumps is that the addresses only make sense
> for a single version of the Cygwin DLL. If that's a self-built
> version, what does `addr2line -e /bin/cygwin1.dll 610CFA77' print?
> If it's 1.7.15, please install the cygwin-debug package and call
> the same addr2line.
>
> I assume the address corresponds to select.cc, line 625, but I'm
> quite busy with the pthread_cancel stuff, so I didn't look deeper
> into this problem.
Yes, that's correct. (I'm using the 20120516 snapshot.)
>> eax=80106D50 ebx=34322D73 ecx=766231E7 edx=00000000 esi=00000001
>> edi=00000050
>> ebp=048FACC8 esp=048FACA0
>> program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
>> 6492, thread pipesel
> ^^^^^^^
> Yes, that's exactly the created thread. Do you happen to know what
> kind of descriptor has been given to select at this point? Is that
> a pty master side perhaps?
Based on the emacs code, I think that's right. But maybe I need to
download the source for the snapshot I'm using (or build cygwin1.dll
myself) so that I can step through the first call to select after the
longjmp and see exactly where the crash is happening.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-23 16:03 ` Ken Brown
@ 2012-05-23 16:07 ` Corinna Vinschen
2012-05-24 12:19 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-23 16:07 UTC (permalink / raw)
To: cygwin
On May 23 11:56, Ken Brown wrote:
> On 5/23/2012 10:15 AM, Corinna Vinschen wrote:
> >On May 23 08:00, Ken Brown wrote:
> >I don't know what this has to do with the longjmp, but the thread
> >which gets crated right after pressing Ctrl-G is due to a select or
> >poll call. The descriptor is a pipe, fifo, or pty.
>
> After the longjmp, emacs has finished processing the C-g and goes
> back into its idle loop, in which it repeatedly calls select.
>
> gdb doesn't normally show the threads created by select. If it did,
> it would always create voluminous output. Can you infer anything
> from the fact that it shows this one?
>
> >The problem with stackdumps is that the addresses only make sense
> >for a single version of the Cygwin DLL. If that's a self-built
> >version, what does `addr2line -e /bin/cygwin1.dll 610CFA77' print?
> >If it's 1.7.15, please install the cygwin-debug package and call
> >the same addr2line.
> >
> >I assume the address corresponds to select.cc, line 625, but I'm
> >quite busy with the pthread_cancel stuff, so I didn't look deeper
> >into this problem.
>
> Yes, that's correct. (I'm using the 20120516 snapshot.)
>
> >>eax=80106D50 ebx=34322D73 ecx=766231E7 edx=00000000 esi=00000001
> >>edi=00000050
> >>ebp=048FACC8 esp=048FACA0
> >>program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
> >>6492, thread pipesel
> > ^^^^^^^
> >Yes, that's exactly the created thread. Do you happen to know what
> >kind of descriptor has been given to select at this point? Is that
> >a pty master side perhaps?
>
> Based on the emacs code, I think that's right. But maybe I need to
> download the source for the snapshot I'm using (or build cygwin1.dll
> myself) so that I can step through the first call to select after
> the longjmp and see exactly where the crash is happening.
That would be most helpful. I don't grok this crash. It's one of
the "this should never possibly happen" kind...
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-23 16:07 ` Corinna Vinschen
@ 2012-05-24 12:19 ` Ken Brown
2012-05-25 10:12 ` Corinna Vinschen
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-24 12:19 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 8887 bytes --]
On 5/23/2012 12:02 PM, Corinna Vinschen wrote:
> On May 23 11:56, Ken Brown wrote:
>> On 5/23/2012 10:15 AM, Corinna Vinschen wrote:
>>> On May 23 08:00, Ken Brown wrote:
>>> I don't know what this has to do with the longjmp, but the thread
>>> which gets crated right after pressing Ctrl-G is due to a select or
>>> poll call. The descriptor is a pipe, fifo, or pty.
>>
>> After the longjmp, emacs has finished processing the C-g and goes
>> back into its idle loop, in which it repeatedly calls select.
>>
>> gdb doesn't normally show the threads created by select. If it did,
>> it would always create voluminous output. Can you infer anything
>> from the fact that it shows this one?
>>
>>> The problem with stackdumps is that the addresses only make sense
>>> for a single version of the Cygwin DLL. If that's a self-built
>>> version, what does `addr2line -e /bin/cygwin1.dll 610CFA77' print?
>>> If it's 1.7.15, please install the cygwin-debug package and call
>>> the same addr2line.
>>>
>>> I assume the address corresponds to select.cc, line 625, but I'm
>>> quite busy with the pthread_cancel stuff, so I didn't look deeper
>>> into this problem.
>>
>> Yes, that's correct. (I'm using the 20120516 snapshot.)
>>
>>>> eax=80106D50 ebx=34322D73 ecx=766231E7 edx=00000000 esi=00000001
>>>> edi=00000050
>>>> ebp=048FACC8 esp=048FACA0
>>>> program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
>>>> 6492, thread pipesel
>>> ^^^^^^^
>>> Yes, that's exactly the created thread. Do you happen to know what
>>> kind of descriptor has been given to select at this point? Is that
>>> a pty master side perhaps?
>>
>> Based on the emacs code, I think that's right. But maybe I need to
>> download the source for the snapshot I'm using (or build cygwin1.dll
>> myself) so that I can step through the first call to select after
>> the longjmp and see exactly where the crash is happening.
>
> That would be most helpful. I don't grok this crash. It's one of
> the "this should never possibly happen" kind...
I'm now using an unoptimized build of the 20120523 snapshot. The gdb
session is below. I first started emacs and started the shell process;
this guarantees that when emacs calls select, one of the descriptors is
a pty master. Then I attached gdb and put a breakpoint at the emacs
function unwind_to_catch, which is triggered when I press C-g. It took
two presses of C-g to get the crash. I think the rest is self-explanatory.
(gdb) b unwind_to_catch
Breakpoint 3 at 0x52aca2: file eval.c, line 1234.
(gdb) c
Continuing.
[Switching to Thread 860.0x2390]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12929854) at
eval.c:1234
1234 catch->val = value;
(gdb) b thread_pipe
Breakpoint 4 at 0x610d871a: file
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc,
line 618.
(gdb) n
1237 set_poll_suppress_count (catch->poll_suppress_count);
[stepping through unwind_to_catch...]
1272 _longjmp (catch->jmp, 1);
(gdb)
[Switching to Thread 860.0x1d8c]
Breakpoint 4, thread_pipe (arg=0x80104d00)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) n
619 DWORD sleep_time = 0;
(gdb)
620 bool looping = true;
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
636 if (!looping)
(gdb)
638 Sleep (sleep_time >> 3);
(gdb)
639 if (sleep_time < 80)
(gdb)
640 ++sleep_time;
(gdb)
641 if (pi->stop_thread)
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
631 select_printf ("stopping");
(gdb)
632 looping = false;
(gdb)
633 break;
(gdb)
636 if (!looping)
(gdb)
637 break;
(gdb)
644 return 0;
(gdb)
645 }
(gdb)
cygthread::callfunc (this=0x6119e080, issimplestub=false)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/cygthread.cc:53
53 }
(gdb) c
Continuing.
Breakpoint 4, thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) disable 4
(gdb) c
Continuing.
[Switching to Thread 860.0x2390]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12996910) at
eval.c:1234
1234 catch->val = value;
[stepping through unwind_to_catch...]
1272 _longjmp (catch->jmp, 1);
(gdb)
[New Thread 860.0x2280] <<<<<<<<<<<<<<<<<<<<<<<<<<<
[Switching to Thread 860.0x2280]
Breakpoint 4, thread_pipe (arg=0x80104d00)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) n
619 DWORD sleep_time = 0;
(gdb)
620 bool looping = true;
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
636 if (!looping)
(gdb)
638 Sleep (sleep_time >> 3);
(gdb)
639 if (sleep_time < 80)
(gdb)
640 ++sleep_time;
(gdb)
641 if (pi->stop_thread)
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 860.0x1d8c]
0x610d87df in thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
638 Sleep (sleep_time >> 3);
(gdb) n
Program received signal SIGILL, Illegal instruction.
0x610d87df in thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
638 Sleep (sleep_time >> 3);
(gdb) n
Program received signal SIGILL, Illegal instruction.
0x610d87df in thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
638 Sleep (sleep_time >> 3);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 860.0x2390]
0x76f3f8b1 in ntdll!RtlUpdateClonedSRWLock () from
/c/windows/SysWOW64/ntdll.dll
(gdb) thread apply all bt full
[compressed output attached]
The stackdump this time contains only one line:
Exception: STATUS_PRIVILEGED_INSTRUCTION at eip=610D87DF
But the following was printed on the terminal:
eax=9FA8007D ebx=079ACE64 ecx=766231E7 edx=00000000 esi=00000000
edi=00000000
ebp=079AACA8 esp=079AAC80
program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
9636, thread pipesel
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
079AACA8 610D873E (80104830, 00000000, 00000000, 00000000)
079AACE8 61003902 (611B048C, 00000000, 00000000, 00000000)
079AFF88 61003AC4 (6119E470, 079AFFD4, 76F59EF2, 6119E470)
079AFF94 74F6339A (6119E470, 5A1FC24C, 00000000, 00000000)
079AFFD4 76F59EF2 (61083BE2, 6119E470, 00000000, 00000000)
Segmentation fault
$ addr2line -e /bin/cygwin1.dll 610D87DF
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:638
$ addr2line -e /bin/cygwin1.dll 61003902
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/cygthread.cc:51
$ addr2line -e /bin/cygwin1.dll 61003AC4
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/cygthread.cc:101
I still wonder why gdb shows the creation of that one pipesel thread
that I marked.
Let me know if there's some other place I should be setting a breakpoint
in order to track this down.
Ken
[-- Attachment #2: bt.out.bz2 --]
[-- Type: application/octet-stream, Size: 4615 bytes --]
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-24 12:19 ` Ken Brown
@ 2012-05-25 10:12 ` Corinna Vinschen
2012-05-25 10:39 ` Noel Grandin
2012-05-25 12:46 ` Ken Brown
0 siblings, 2 replies; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-25 10:12 UTC (permalink / raw)
To: cygwin
On May 24 08:17, Ken Brown wrote:
> On 5/23/2012 12:02 PM, Corinna Vinschen wrote:
> >On May 23 11:56, Ken Brown wrote:
> >>Based on the emacs code, I think that's right. But maybe I need to
> >>download the source for the snapshot I'm using (or build cygwin1.dll
> >>myself) so that I can step through the first call to select after
> >>the longjmp and see exactly where the crash is happening.
> >
> >That would be most helpful. I don't grok this crash. It's one of
> >the "this should never possibly happen" kind...
>
> I'm now using an unoptimized build of the 20120523 snapshot. The
> gdb session is below. I first started emacs and started the shell
> process; this guarantees that when emacs calls select, one of the
> descriptors is a pty master. Then I attached gdb and put a
> breakpoint at the emacs function unwind_to_catch, which is triggered
> when I press C-g. It took two presses of C-g to get the crash. I
> think the rest is self-explanatory.
Just to let you know, I looked into this on and off yesterday, but I
still don't understand what's going on.
In theory starting the new thread should be harmless. The threads in
Cygwin are "cygthreads", which is our own thread pool implementation.
It doesn't stop existing threads but reuses them. Only if all
cygthreads are still in use, another one is started and added to the
pool.
I'll look further into this, but I am wondering about this: Is the
new Fsignal/Fthrow implementation so much different than the old one
in emacs 23.x? If not, why does it work in 23.x? Any chance 24.x
produces a stack or heap corruption? Double free or something?
And then again, do we know if 24.x works on older Cygwin release or
snapshots? If it's a Cygwin problem, it might help to nail it down.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-25 10:12 ` Corinna Vinschen
@ 2012-05-25 10:39 ` Noel Grandin
2012-05-25 12:46 ` Ken Brown
1 sibling, 0 replies; 36+ messages in thread
From: Noel Grandin @ 2012-05-25 10:39 UTC (permalink / raw)
To: cygwin
On 2012-05-25 12:03, Corinna Vinschen wrote:
> I'll look further into this, but I am wondering about this: Is the new
> Fsignal/Fthrow implementation so much different than the old one in
> emacs 23.x? If not, why does it work in 23.x? Any chance 24.x produces
> a stack or heap corruption? Double free or something? And then again,
> do we know if 24.x works on older Cygwin release or snapshots? If it's
> a Cygwin problem, it might help to nail it down. Corinna
Might be worth running it under Dr Memory to check this.
http://www.drmemory.org/
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-25 10:12 ` Corinna Vinschen
2012-05-25 10:39 ` Noel Grandin
@ 2012-05-25 12:46 ` Ken Brown
2012-05-25 13:05 ` Corinna Vinschen
1 sibling, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-25 12:46 UTC (permalink / raw)
To: cygwin
On 5/25/2012 6:03 AM, Corinna Vinschen wrote:
> On May 24 08:17, Ken Brown wrote:
>> On 5/23/2012 12:02 PM, Corinna Vinschen wrote:
>>> On May 23 11:56, Ken Brown wrote:
>>>> Based on the emacs code, I think that's right. But maybe I need to
>>>> download the source for the snapshot I'm using (or build cygwin1.dll
>>>> myself) so that I can step through the first call to select after
>>>> the longjmp and see exactly where the crash is happening.
>>>
>>> That would be most helpful. I don't grok this crash. It's one of
>>> the "this should never possibly happen" kind...
>>
>> I'm now using an unoptimized build of the 20120523 snapshot. The
>> gdb session is below. I first started emacs and started the shell
>> process; this guarantees that when emacs calls select, one of the
>> descriptors is a pty master. Then I attached gdb and put a
>> breakpoint at the emacs function unwind_to_catch, which is triggered
>> when I press C-g. It took two presses of C-g to get the crash. I
>> think the rest is self-explanatory.
>
> Just to let you know, I looked into this on and off yesterday, but I
> still don't understand what's going on.
>
> In theory starting the new thread should be harmless. The threads in
> Cygwin are "cygthreads", which is our own thread pool implementation.
> It doesn't stop existing threads but reuses them. Only if all
> cygthreads are still in use, another one is started and added to the
> pool.
>
> I'll look further into this, but I am wondering about this: Is the
> new Fsignal/Fthrow implementation so much different than the old one
> in emacs 23.x? If not, why does it work in 23.x? Any chance 24.x
> produces a stack or heap corruption? Double free or something?
There's nothing that jumps out at me.
> And then again, do we know if 24.x works on older Cygwin release or
> snapshots? If it's a Cygwin problem, it might help to nail it down.
It works on the 20120111 snapshot but fails on the 20120122 snapshot.
Thanks for suggesting this. It should have been the first thing I checked.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-25 12:46 ` Ken Brown
@ 2012-05-25 13:05 ` Corinna Vinschen
2012-05-25 14:49 ` Corinna Vinschen
0 siblings, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-25 13:05 UTC (permalink / raw)
To: cygwin
On May 25 08:45, Ken Brown wrote:
> On 5/25/2012 6:03 AM, Corinna Vinschen wrote:
> >And then again, do we know if 24.x works on older Cygwin release or
> >snapshots? If it's a Cygwin problem, it might help to nail it down.
>
> It works on the 20120111 snapshot but fails on the 20120122
> snapshot. Thanks for suggesting this. It should have been the first
> thing I checked.
Cool! That only leaves three checkins to be the culprit. I'm not
sure I can get to it over the weekend (and Monday is a holiday here),
but I'll certainly try to track it down next week.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-25 13:05 ` Corinna Vinschen
@ 2012-05-25 14:49 ` Corinna Vinschen
2012-05-25 19:44 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Corinna Vinschen @ 2012-05-25 14:49 UTC (permalink / raw)
To: cygwin
On May 25 15:03, Corinna Vinschen wrote:
> On May 25 08:45, Ken Brown wrote:
> > On 5/25/2012 6:03 AM, Corinna Vinschen wrote:
> > >And then again, do we know if 24.x works on older Cygwin release or
> > >snapshots? If it's a Cygwin problem, it might help to nail it down.
> >
> > It works on the 20120111 snapshot but fails on the 20120122
> > snapshot. Thanks for suggesting this. It should have been the first
> > thing I checked.
>
> Cool! That only leaves three checkins to be the culprit. I'm not
> sure I can get to it over the weekend (and Monday is a holiday here),
> but I'll certainly try to track it down next week.
Ok, I had a look already and I see where the problem is, but that
doesn't mean I understand it yet.
C-g results in calling an emacs signal handler from select. Up to the
change from 20120122 in select.cc, all select threads have been stopped
before the signal handler is called. This works fine.
After the change from 20120122, the signal handler is called first, and
only afterwards the select threads are cleaned up. This results in
starting another pipesel thread and the subsequent crash.
I applied a patch which calls the signal handler after cleanup. The
downside is that the signal handler is only called if select is called
from the main thread. A better patch would perhaps be to stop all
threads, call the signal handler, and restart the threads afterwards,
but this is more tricky.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-25 14:49 ` Corinna Vinschen
@ 2012-05-25 19:44 ` Ken Brown
2012-05-25 20:10 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-25 19:44 UTC (permalink / raw)
To: cygwin
On 5/25/2012 10:35 AM, Corinna Vinschen wrote:
> On May 25 15:03, Corinna Vinschen wrote:
>> On May 25 08:45, Ken Brown wrote:
>>> On 5/25/2012 6:03 AM, Corinna Vinschen wrote:
>>>> And then again, do we know if 24.x works on older Cygwin release or
>>>> snapshots? If it's a Cygwin problem, it might help to nail it down.
>>>
>>> It works on the 20120111 snapshot but fails on the 20120122
>>> snapshot. Thanks for suggesting this. It should have been the first
>>> thing I checked.
>>
>> Cool! That only leaves three checkins to be the culprit. I'm not
>> sure I can get to it over the weekend (and Monday is a holiday here),
>> but I'll certainly try to track it down next week.
>
> Ok, I had a look already and I see where the problem is, but that
> doesn't mean I understand it yet.
>
> C-g results in calling an emacs signal handler from select. Up to the
> change from 20120122 in select.cc, all select threads have been stopped
> before the signal handler is called. This works fine.
>
> After the change from 20120122, the signal handler is called first, and
> only afterwards the select threads are cleaned up. This results in
> starting another pipesel thread and the subsequent crash.
>
> I applied a patch which calls the signal handler after cleanup. The
> downside is that the signal handler is only called if select is called
> from the main thread. A better patch would perhaps be to stop all
> threads, call the signal handler, and restart the threads afterwards,
> but this is more tricky.
Thanks! That fixes it. I appreciate all your work on this.
I'm in the process now of testing to see if this also fixes an emacs
crash I've been getting when I build emacs with GSettings support
(http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html).
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-25 19:44 ` Ken Brown
@ 2012-05-25 20:10 ` Ken Brown
2012-06-03 3:08 ` Christopher Faylor
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-05-25 20:10 UTC (permalink / raw)
To: cygwin
On 5/25/2012 2:49 PM, Ken Brown wrote:
> On 5/25/2012 10:35 AM, Corinna Vinschen wrote:
>> I applied a patch which calls the signal handler after cleanup. The
>> downside is that the signal handler is only called if select is called
>> from the main thread. A better patch would perhaps be to stop all
>> threads, call the signal handler, and restart the threads afterwards,
>> but this is more tricky.
>
> Thanks! That fixes it. I appreciate all your work on this.
>
> I'm in the process now of testing to see if this also fixes an emacs
> crash I've been getting when I build emacs with GSettings support
> (http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html).
Here's what I'm now seeing with that build. If I start emacs and do
'M-x shell', emacs hangs (but doesn't crash). Attaching gdb and doing a
backtrace of all threads, I see that cygwin_select has been called in
two threads other than the main one:
Thread 8 (Thread 2784.0x19c):
#0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from /c/windows/SysWOW64/ntdll.dll
#1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from /c/windows/SysWOW64/ntdll.dll
#2 0x74fe0bdd in WaitForMultipleObjectsEx ()
from /c/windows/syswow64/KERNELBASE.dll
#3 0x00000004 in ?? ()
#4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
from /c/windows/syswow64/kernel32.dll
#5 0xff11c868 in ?? ()
#6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
from /c/windows/syswow64/kernel32.dll
#7 0x00000004 in ?? ()
#8 0x610d0b24 in select_stuff::wait (this=0xff11cba4, readfds=0xff11cb00,
writefds=0xff11cae0, exceptfds=0xff11cac0, ms=4294967295)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
#9 0x610d154b in cygwin_select (maxfds=13, readfds=0xff11cc70,
writefds=0xff11cc50, exceptfds=0xff11cc30, to=0x0)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
#10 0x610b2b5a in poll (fds=0x8012db00, nfds=3, timeout=-1)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
#11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
#12 0xffffffff in ?? ()
#13 0x8012db00 in ?? ()
#14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
#15 0x6ad96d40 in g_dbus_proxy_call_with_unix_fd_list_sync ()
from /usr/bin/cyggio-2.0-0.dll
#16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
#17 0x610fca42 in pthread::thread_init_wrapper (arg=0x80130e00)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
#18 0x61086f62 in thread_wrapper (arg=0x0)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
#19 0x00000000 in ?? ()
Thread 7 (Thread 2784.0xb4c):
#0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from /c/windows/SysWOW64/ntdll.dll
#1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from /c/windows/SysWOW64/ntdll.dll
#2 0x74fe0bdd in WaitForMultipleObjectsEx ()
from /c/windows/syswow64/KERNELBASE.dll
#3 0x00000003 in ?? ()
#4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
from /c/windows/syswow64/kernel32.dll
#5 0xff21c858 in ?? ()
#6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
from /c/windows/syswow64/kernel32.dll
#7 0x00000003 in ?? ()
#8 0x610d0b24 in select_stuff::wait (this=0xff21cb94, readfds=0xff21caf0,
writefds=0xff21cad0, exceptfds=0xff21cab0, ms=4294967295)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
#9 0x610d154b in cygwin_select (maxfds=8, readfds=0xff21cc60,
writefds=0xff21cc40, exceptfds=0xff21cc20, to=0x0)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
#10 0x610b2b5a in poll (fds=0x8009b3c0, nfds=1, timeout=-1)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
#11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
#12 0xffffffff in ?? ()
#13 0x8009b3c0 in ?? ()
#14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
#15 0x63e32eca in gvdb_table_walk ()
from /usr/lib/gio/modules/cygdconfsettings.dll
#16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
#17 0x610fca42 in pthread::thread_init_wrapper (arg=0x8009c700)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
#18 0x61086f62 in thread_wrapper (arg=0x0)
at
/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
#19 0x00000000 in ?? ()
It looks like these threads are being used by GLib, which is running a
loop that calls poll, which calls cygwin_select. So maybe the "better
patch" that you referred to would fix this hang.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-05-25 20:10 ` Ken Brown
@ 2012-06-03 3:08 ` Christopher Faylor
2012-06-03 12:55 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Christopher Faylor @ 2012-06-03 3:08 UTC (permalink / raw)
To: cygwin
On Fri, May 25, 2012 at 04:07:32PM -0400, Ken Brown wrote:
>On 5/25/2012 2:49 PM, Ken Brown wrote:
>> On 5/25/2012 10:35 AM, Corinna Vinschen wrote:
>>> I applied a patch which calls the signal handler after cleanup. The
>>> downside is that the signal handler is only called if select is called
>>> from the main thread. A better patch would perhaps be to stop all
>>> threads, call the signal handler, and restart the threads afterwards,
>>> but this is more tricky.
>>
>> Thanks! That fixes it. I appreciate all your work on this.
>>
>> I'm in the process now of testing to see if this also fixes an emacs
>> crash I've been getting when I build emacs with GSettings support
>> (http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html).
>
>Here's what I'm now seeing with that build. If I start emacs and do
>'M-x shell', emacs hangs (but doesn't crash). Attaching gdb and doing a
>backtrace of all threads, I see that cygwin_select has been called in
>two threads other than the main one:
>
>Thread 8 (Thread 2784.0x19c):
>#0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
> from /c/windows/SysWOW64/ntdll.dll
>#1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
> from /c/windows/SysWOW64/ntdll.dll
>#2 0x74fe0bdd in WaitForMultipleObjectsEx ()
> from /c/windows/syswow64/KERNELBASE.dll
>#3 0x00000004 in ?? ()
>#4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
> from /c/windows/syswow64/kernel32.dll
>#5 0xff11c868 in ?? ()
>#6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
> from /c/windows/syswow64/kernel32.dll
>#7 0x00000004 in ?? ()
>#8 0x610d0b24 in select_stuff::wait (this=0xff11cba4, readfds=0xff11cb00,
> writefds=0xff11cae0, exceptfds=0xff11cac0, ms=4294967295)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>#9 0x610d154b in cygwin_select (maxfds=13, readfds=0xff11cc70,
> writefds=0xff11cc50, exceptfds=0xff11cc30, to=0x0)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>#10 0x610b2b5a in poll (fds=0x8012db00, nfds=3, timeout=-1)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>#11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>#12 0xffffffff in ?? ()
>#13 0x8012db00 in ?? ()
>#14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>#15 0x6ad96d40 in g_dbus_proxy_call_with_unix_fd_list_sync ()
> from /usr/bin/cyggio-2.0-0.dll
>#16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>#17 0x610fca42 in pthread::thread_init_wrapper (arg=0x80130e00)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>#18 0x61086f62 in thread_wrapper (arg=0x0)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>#19 0x00000000 in ?? ()
>
>Thread 7 (Thread 2784.0xb4c):
>#0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
> from /c/windows/SysWOW64/ntdll.dll
>#1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
> from /c/windows/SysWOW64/ntdll.dll
>#2 0x74fe0bdd in WaitForMultipleObjectsEx ()
> from /c/windows/syswow64/KERNELBASE.dll
>#3 0x00000003 in ?? ()
>#4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
> from /c/windows/syswow64/kernel32.dll
>#5 0xff21c858 in ?? ()
>#6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
> from /c/windows/syswow64/kernel32.dll
>#7 0x00000003 in ?? ()
>#8 0x610d0b24 in select_stuff::wait (this=0xff21cb94, readfds=0xff21caf0,
> writefds=0xff21cad0, exceptfds=0xff21cab0, ms=4294967295)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>#9 0x610d154b in cygwin_select (maxfds=8, readfds=0xff21cc60,
> writefds=0xff21cc40, exceptfds=0xff21cc20, to=0x0)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>#10 0x610b2b5a in poll (fds=0x8009b3c0, nfds=1, timeout=-1)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>#11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>#12 0xffffffff in ?? ()
>#13 0x8009b3c0 in ?? ()
>#14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>#15 0x63e32eca in gvdb_table_walk ()
> from /usr/lib/gio/modules/cygdconfsettings.dll
>#16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>#17 0x610fca42 in pthread::thread_init_wrapper (arg=0x8009c700)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>#18 0x61086f62 in thread_wrapper (arg=0x0)
> at
>/ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>#19 0x00000000 in ?? ()
>
>It looks like these threads are being used by GLib, which is running a
>loop that calls poll, which calls cygwin_select. So maybe the "better
>patch" that you referred to would fix this hang.
Ken, can you confirm/deny that the changes that I just made to select()
at least still work as well as Corinna's temporary (that's what the
ChangeLog says at least) change above? They are in the latest 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-06-03 3:08 ` Christopher Faylor
@ 2012-06-03 12:55 ` Ken Brown
2012-06-03 16:53 ` Christopher Faylor
0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2012-06-03 12:55 UTC (permalink / raw)
To: cygwin
On 6/2/2012 11:08 PM, Christopher Faylor wrote:
> On Fri, May 25, 2012 at 04:07:32PM -0400, Ken Brown wrote:
>> On 5/25/2012 2:49 PM, Ken Brown wrote:
>>> On 5/25/2012 10:35 AM, Corinna Vinschen wrote:
>>>> I applied a patch which calls the signal handler after cleanup. The
>>>> downside is that the signal handler is only called if select is called
>>>> from the main thread. A better patch would perhaps be to stop all
>>>> threads, call the signal handler, and restart the threads afterwards,
>>>> but this is more tricky.
>>>
>>> Thanks! That fixes it. I appreciate all your work on this.
>>>
>>> I'm in the process now of testing to see if this also fixes an emacs
>>> crash I've been getting when I build emacs with GSettings support
>>> (http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html).
>>
>> Here's what I'm now seeing with that build. If I start emacs and do
>> 'M-x shell', emacs hangs (but doesn't crash). Attaching gdb and doing a
>> backtrace of all threads, I see that cygwin_select has been called in
>> two threads other than the main one:
>>
>> Thread 8 (Thread 2784.0x19c):
>> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>> from /c/windows/SysWOW64/ntdll.dll
>> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>> from /c/windows/SysWOW64/ntdll.dll
>> #2 0x74fe0bdd in WaitForMultipleObjectsEx ()
>> from /c/windows/syswow64/KERNELBASE.dll
>> #3 0x00000004 in ?? ()
>> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
>> from /c/windows/syswow64/kernel32.dll
>> #5 0xff11c868 in ?? ()
>> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
>> from /c/windows/syswow64/kernel32.dll
>> #7 0x00000004 in ?? ()
>> #8 0x610d0b24 in select_stuff::wait (this=0xff11cba4, readfds=0xff11cb00,
>> writefds=0xff11cae0, exceptfds=0xff11cac0, ms=4294967295)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>> #9 0x610d154b in cygwin_select (maxfds=13, readfds=0xff11cc70,
>> writefds=0xff11cc50, exceptfds=0xff11cc30, to=0x0)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>> #10 0x610b2b5a in poll (fds=0x8012db00, nfds=3, timeout=-1)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>> #12 0xffffffff in ?? ()
>> #13 0x8012db00 in ?? ()
>> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>> #15 0x6ad96d40 in g_dbus_proxy_call_with_unix_fd_list_sync ()
>> from /usr/bin/cyggio-2.0-0.dll
>> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x80130e00)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>> #18 0x61086f62 in thread_wrapper (arg=0x0)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>> #19 0x00000000 in ?? ()
>>
>> Thread 7 (Thread 2784.0xb4c):
>> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>> from /c/windows/SysWOW64/ntdll.dll
>> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>> from /c/windows/SysWOW64/ntdll.dll
>> #2 0x74fe0bdd in WaitForMultipleObjectsEx ()
>> from /c/windows/syswow64/KERNELBASE.dll
>> #3 0x00000003 in ?? ()
>> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
>> from /c/windows/syswow64/kernel32.dll
>> #5 0xff21c858 in ?? ()
>> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
>> from /c/windows/syswow64/kernel32.dll
>> #7 0x00000003 in ?? ()
>> #8 0x610d0b24 in select_stuff::wait (this=0xff21cb94, readfds=0xff21caf0,
>> writefds=0xff21cad0, exceptfds=0xff21cab0, ms=4294967295)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>> #9 0x610d154b in cygwin_select (maxfds=8, readfds=0xff21cc60,
>> writefds=0xff21cc40, exceptfds=0xff21cc20, to=0x0)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>> #10 0x610b2b5a in poll (fds=0x8009b3c0, nfds=1, timeout=-1)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>> #12 0xffffffff in ?? ()
>> #13 0x8009b3c0 in ?? ()
>> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>> #15 0x63e32eca in gvdb_table_walk ()
>> from /usr/lib/gio/modules/cygdconfsettings.dll
>> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x8009c700)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>> #18 0x61086f62 in thread_wrapper (arg=0x0)
>> at
>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>> #19 0x00000000 in ?? ()
>>
>> It looks like these threads are being used by GLib, which is running a
>> loop that calls poll, which calls cygwin_select. So maybe the "better
>> patch" that you referred to would fix this hang.
>
> Ken, can you confirm/deny that the changes that I just made to select()
> at least still work as well as Corinna's temporary (that's what the
> ChangeLog says at least) change above? They are in the latest snapshot.
No, they don't. There's no crash, but I'm seeing two problems in emacs
and a problem with the X server. My emacs tests were done with emacs-24
in mintty on 64-bit Windows 7. I wanted to test it under X also, but I
couldn't because of the X server problem.
1. When I type into emacs, it's very slow to echo the keystrokes and
respond.
2. When I start a shell under emacs (<Alt-X>shell<return>), the shell
doesn't finish initializing. It doesn't display a prompt, and it
doesn't execute commands I type.
3. If I start the X server using the Start Menu shortcut, startxwin
never finishes, and the xterm window doesn't display. I have to kill
startxwin from a terminal.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-06-03 12:55 ` Ken Brown
@ 2012-06-03 16:53 ` Christopher Faylor
2012-06-03 21:26 ` Ken Brown
0 siblings, 1 reply; 36+ messages in thread
From: Christopher Faylor @ 2012-06-03 16:53 UTC (permalink / raw)
To: cygwin
On Sun, Jun 03, 2012 at 08:54:20AM -0400, Ken Brown wrote:
>On 6/2/2012 11:08 PM, Christopher Faylor wrote:
>> On Fri, May 25, 2012 at 04:07:32PM -0400, Ken Brown wrote:
>>> On 5/25/2012 2:49 PM, Ken Brown wrote:
>>>> On 5/25/2012 10:35 AM, Corinna Vinschen wrote:
>>>>> I applied a patch which calls the signal handler after cleanup. The
>>>>> downside is that the signal handler is only called if select is called
>>>>> from the main thread. A better patch would perhaps be to stop all
>>>>> threads, call the signal handler, and restart the threads afterwards,
>>>>> but this is more tricky.
>>>>
>>>> Thanks! That fixes it. I appreciate all your work on this.
>>>>
>>>> I'm in the process now of testing to see if this also fixes an emacs
>>>> crash I've been getting when I build emacs with GSettings support
>>>> (http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html).
>>>
>>> Here's what I'm now seeing with that build. If I start emacs and do
>>> 'M-x shell', emacs hangs (but doesn't crash). Attaching gdb and doing a
>>> backtrace of all threads, I see that cygwin_select has been called in
>>> two threads other than the main one:
>>>
>>> Thread 8 (Thread 2784.0x19c):
>>> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>> from /c/windows/SysWOW64/ntdll.dll
>>> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>> from /c/windows/SysWOW64/ntdll.dll
>>> #2 0x74fe0bdd in WaitForMultipleObjectsEx ()
>>> from /c/windows/syswow64/KERNELBASE.dll
>>> #3 0x00000004 in ?? ()
>>> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
>>> from /c/windows/syswow64/kernel32.dll
>>> #5 0xff11c868 in ?? ()
>>> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
>>> from /c/windows/syswow64/kernel32.dll
>>> #7 0x00000004 in ?? ()
>>> #8 0x610d0b24 in select_stuff::wait (this=0xff11cba4, readfds=0xff11cb00,
>>> writefds=0xff11cae0, exceptfds=0xff11cac0, ms=4294967295)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>>> #9 0x610d154b in cygwin_select (maxfds=13, readfds=0xff11cc70,
>>> writefds=0xff11cc50, exceptfds=0xff11cc30, to=0x0)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>>> #10 0x610b2b5a in poll (fds=0x8012db00, nfds=3, timeout=-1)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>>> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>>> #12 0xffffffff in ?? ()
>>> #13 0x8012db00 in ?? ()
>>> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>>> #15 0x6ad96d40 in g_dbus_proxy_call_with_unix_fd_list_sync ()
>>> from /usr/bin/cyggio-2.0-0.dll
>>> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>>> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x80130e00)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>>> #18 0x61086f62 in thread_wrapper (arg=0x0)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>>> #19 0x00000000 in ?? ()
>>>
>>> Thread 7 (Thread 2784.0xb4c):
>>> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>> from /c/windows/SysWOW64/ntdll.dll
>>> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>> from /c/windows/SysWOW64/ntdll.dll
>>> #2 0x74fe0bdd in WaitForMultipleObjectsEx ()
>>> from /c/windows/syswow64/KERNELBASE.dll
>>> #3 0x00000003 in ?? ()
>>> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
>>> from /c/windows/syswow64/kernel32.dll
>>> #5 0xff21c858 in ?? ()
>>> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
>>> from /c/windows/syswow64/kernel32.dll
>>> #7 0x00000003 in ?? ()
>>> #8 0x610d0b24 in select_stuff::wait (this=0xff21cb94, readfds=0xff21caf0,
>>> writefds=0xff21cad0, exceptfds=0xff21cab0, ms=4294967295)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>>> #9 0x610d154b in cygwin_select (maxfds=8, readfds=0xff21cc60,
>>> writefds=0xff21cc40, exceptfds=0xff21cc20, to=0x0)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>>> #10 0x610b2b5a in poll (fds=0x8009b3c0, nfds=1, timeout=-1)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>>> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>>> #12 0xffffffff in ?? ()
>>> #13 0x8009b3c0 in ?? ()
>>> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>>> #15 0x63e32eca in gvdb_table_walk ()
>>> from /usr/lib/gio/modules/cygdconfsettings.dll
>>> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>>> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x8009c700)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>>> #18 0x61086f62 in thread_wrapper (arg=0x0)
>>> at
>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>>> #19 0x00000000 in ?? ()
>>>
>>> It looks like these threads are being used by GLib, which is running a
>>> loop that calls poll, which calls cygwin_select. So maybe the "better
>>> patch" that you referred to would fix this hang.
>>
>> Ken, can you confirm/deny that the changes that I just made to select()
>> at least still work as well as Corinna's temporary (that's what the
>> ChangeLog says at least) change above? They are in the latest snapshot.
>
>No, they don't. There's no crash, but I'm seeing two problems in emacs
>and a problem with the X server. My emacs tests were done with emacs-24
>in mintty on 64-bit Windows 7. I wanted to test it under X also, but I
>couldn't because of the X server problem.
>
>1. When I type into emacs, it's very slow to echo the keystrokes and
>respond.
>
>2. When I start a shell under emacs (<Alt-X>shell<return>), the shell
>doesn't finish initializing. It doesn't display a prompt, and it
>doesn't execute commands I type.
>
>3. If I start the X server using the Start Menu shortcut, startxwin
>never finishes, and the xterm window doesn't display. I have to kill
>startxwin from a terminal.
All of the above should be fixed in the upcoming snapshot.
Sorry for wasting your time with this. It was late and I didn't do the
basic checking that I should have before checking this in. I had a
very stupid typo in the last 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: "emacs -nw" hangs in a terminal
2012-06-03 16:53 ` Christopher Faylor
@ 2012-06-03 21:26 ` Ken Brown
0 siblings, 0 replies; 36+ messages in thread
From: Ken Brown @ 2012-06-03 21:26 UTC (permalink / raw)
To: cygwin
On 6/3/2012 12:52 PM, Christopher Faylor wrote:
> On Sun, Jun 03, 2012 at 08:54:20AM -0400, Ken Brown wrote:
>> On 6/2/2012 11:08 PM, Christopher Faylor wrote:
>>> On Fri, May 25, 2012 at 04:07:32PM -0400, Ken Brown wrote:
>>>> On 5/25/2012 2:49 PM, Ken Brown wrote:
>>>>> On 5/25/2012 10:35 AM, Corinna Vinschen wrote:
>>>>>> I applied a patch which calls the signal handler after cleanup. The
>>>>>> downside is that the signal handler is only called if select is called
>>>>>> from the main thread. A better patch would perhaps be to stop all
>>>>>> threads, call the signal handler, and restart the threads afterwards,
>>>>>> but this is more tricky.
>>>>>
>>>>> Thanks! That fixes it. I appreciate all your work on this.
>>>>>
>>>>> I'm in the process now of testing to see if this also fixes an emacs
>>>>> crash I've been getting when I build emacs with GSettings support
>>>>> (http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html).
>>>>
>>>> Here's what I'm now seeing with that build. If I start emacs and do
>>>> 'M-x shell', emacs hangs (but doesn't crash). Attaching gdb and doing a
>>>> backtrace of all threads, I see that cygwin_select has been called in
>>>> two threads other than the main one:
>>>>
>>>> Thread 8 (Thread 2784.0x19c):
>>>> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>>> from /c/windows/SysWOW64/ntdll.dll
>>>> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>>> from /c/windows/SysWOW64/ntdll.dll
>>>> #2 0x74fe0bdd in WaitForMultipleObjectsEx ()
>>>> from /c/windows/syswow64/KERNELBASE.dll
>>>> #3 0x00000004 in ?? ()
>>>> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
>>>> from /c/windows/syswow64/kernel32.dll
>>>> #5 0xff11c868 in ?? ()
>>>> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
>>>> from /c/windows/syswow64/kernel32.dll
>>>> #7 0x00000004 in ?? ()
>>>> #8 0x610d0b24 in select_stuff::wait (this=0xff11cba4, readfds=0xff11cb00,
>>>> writefds=0xff11cae0, exceptfds=0xff11cac0, ms=4294967295)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>>>> #9 0x610d154b in cygwin_select (maxfds=13, readfds=0xff11cc70,
>>>> writefds=0xff11cc50, exceptfds=0xff11cc30, to=0x0)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>>>> #10 0x610b2b5a in poll (fds=0x8012db00, nfds=3, timeout=-1)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>>>> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>>>> #12 0xffffffff in ?? ()
>>>> #13 0x8012db00 in ?? ()
>>>> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>>>> #15 0x6ad96d40 in g_dbus_proxy_call_with_unix_fd_list_sync ()
>>>> from /usr/bin/cyggio-2.0-0.dll
>>>> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>>>> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x80130e00)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>>>> #18 0x61086f62 in thread_wrapper (arg=0x0)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>>>> #19 0x00000000 in ?? ()
>>>>
>>>> Thread 7 (Thread 2784.0xb4c):
>>>> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>>> from /c/windows/SysWOW64/ntdll.dll
>>>> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
>>>> from /c/windows/SysWOW64/ntdll.dll
>>>> #2 0x74fe0bdd in WaitForMultipleObjectsEx ()
>>>> from /c/windows/syswow64/KERNELBASE.dll
>>>> #3 0x00000003 in ?? ()
>>>> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
>>>> from /c/windows/syswow64/kernel32.dll
>>>> #5 0xff21c858 in ?? ()
>>>> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource ()
>>>> from /c/windows/syswow64/kernel32.dll
>>>> #7 0x00000003 in ?? ()
>>>> #8 0x610d0b24 in select_stuff::wait (this=0xff21cb94, readfds=0xff21caf0,
>>>> writefds=0xff21cad0, exceptfds=0xff21cab0, ms=4294967295)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320
>>>> #9 0x610d154b in cygwin_select (maxfds=8, readfds=0xff21cc60,
>>>> writefds=0xff21cc40, exceptfds=0xff21cc20, to=0x0)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158
>>>> #10 0x610b2b5a in poll (fds=0x8009b3c0, nfds=1, timeout=-1)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87
>>>> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll
>>>> #12 0xffffffff in ?? ()
>>>> #13 0x8009b3c0 in ?? ()
>>>> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll
>>>> #15 0x63e32eca in gvdb_table_walk ()
>>>> from /usr/lib/gio/modules/cygdconfsettings.dll
>>>> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
>>>> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x8009c700)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104
>>>> #18 0x61086f62 in thread_wrapper (arg=0x0)
>>>> at
>>>> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547
>>>> #19 0x00000000 in ?? ()
>>>>
>>>> It looks like these threads are being used by GLib, which is running a
>>>> loop that calls poll, which calls cygwin_select. So maybe the "better
>>>> patch" that you referred to would fix this hang.
>>>
>>> Ken, can you confirm/deny that the changes that I just made to select()
>>> at least still work as well as Corinna's temporary (that's what the
>>> ChangeLog says at least) change above? They are in the latest snapshot.
>>
>> No, they don't. There's no crash, but I'm seeing two problems in emacs
>> and a problem with the X server. My emacs tests were done with emacs-24
>> in mintty on 64-bit Windows 7. I wanted to test it under X also, but I
>> couldn't because of the X server problem.
>>
>> 1. When I type into emacs, it's very slow to echo the keystrokes and
>> respond.
>>
>> 2. When I start a shell under emacs (<Alt-X>shell<return>), the shell
>> doesn't finish initializing. It doesn't display a prompt, and it
>> doesn't execute commands I type.
>>
>> 3. If I start the X server using the Start Menu shortcut, startxwin
>> never finishes, and the xterm window doesn't display. I have to kill
>> startxwin from a terminal.
>
> All of the above should be fixed in the upcoming snapshot.
Confirmed. Everything seems to work as it did after Corinna's change.
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
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2012-06-03 21:26 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-14 12:31 "emacs -nw" hangs in a terminal cygwin
2012-05-14 13:58 ` Ken Brown
2012-05-15 11:00 ` Filipp Gunbin
2012-05-15 11:47 ` Ken Brown
2012-05-15 12:17 ` Filipp Gunbin
2012-05-15 12:27 ` Filipp Gunbin
2012-05-15 13:37 ` Ken Brown
2012-05-15 14:28 ` Filipp Gunbin
2012-05-16 16:04 ` Ken Brown
2012-05-21 8:12 ` Filipp Gunbin
2012-05-21 8:50 ` Filipp Gunbin
2012-05-21 10:03 ` Ken Brown
2012-05-21 15:32 ` Ken Brown
2012-05-21 16:29 ` Corinna Vinschen
2012-05-21 18:51 ` Ken Brown
2012-05-22 11:29 ` Corinna Vinschen
2012-05-22 11:42 ` Ken Brown
2012-05-22 13:42 ` Corinna Vinschen
2012-05-22 13:50 ` Corinna Vinschen
2012-05-23 12:01 ` Ken Brown
2012-05-23 13:24 ` Ken Brown
2012-05-23 15:54 ` Corinna Vinschen
2012-05-23 16:03 ` Ken Brown
2012-05-23 16:07 ` Corinna Vinschen
2012-05-24 12:19 ` Ken Brown
2012-05-25 10:12 ` Corinna Vinschen
2012-05-25 10:39 ` Noel Grandin
2012-05-25 12:46 ` Ken Brown
2012-05-25 13:05 ` Corinna Vinschen
2012-05-25 14:49 ` Corinna Vinschen
2012-05-25 19:44 ` Ken Brown
2012-05-25 20:10 ` Ken Brown
2012-06-03 3:08 ` Christopher Faylor
2012-06-03 12:55 ` Ken Brown
2012-06-03 16:53 ` Christopher Faylor
2012-06-03 21:26 ` Ken Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).