* RE: pthread app hangs after Ctrl+C
@ 2001-09-06 20:00 Bryant, Nathan
0 siblings, 0 replies; 3+ messages in thread
From: Bryant, Nathan @ 2001-09-06 20:00 UTC (permalink / raw)
To: 'bucweat_20657', cygwin
Hi, Charlie.
Both my application and DLL are built with Cygwin, using GNU libtool; so the
DLL is also linked to Cygwin.
As a little bit of background, this was necessary in order to port a network
service written for Unix. The service used dlopen()able modules that link
against the main executable, which was built with --export-dynamic. DLL's
can't link to an EXE on Windows, so most of the application had to be moved
into a DLL so that the dlopen modules could link.
So unless i reshuffle code a bit further, there are some signal handlers
that are being built into the DLL, because I've moved everything except
main() into the DLL.
It certainly sounds like the same or similar problem; when I get a moment of
free time, I'll go over the sources you mentioned and try to find some
common threads.
This app spends a lot of time select()ing on a set of TCP sockets, and
blocking on thread mutexes while waiting for another thread to get done
select()ing. It also uses a pipe for communication between threads; one
thread can force the select()ing thread to wake up early by sending a byte
down this pipe. Occasionally it will write a message to the console, but
normally only when there's some sort of activity. There wasn't much activity
at the times I hit Ctrl-C to shut it down. So at the time of the ^C there
were probably 4-5 threads in pthread_mutex_lock() and one in select().
-----Original Message-----
From: bucweat_20657 [ mailto:bucweat_20657@yahoo.com ]
Sent: Thursday, September 06, 2001 10:05 PM
To: Bryant, Nathan; cygwin@cygwin.com
Subject: RE: pthread app hangs after Ctrl+C
Hi Nathan,
I've run into some similar issues recently and so would like to add my $0.02
to show that more than one person has encountered it... check out the
following from this list regarding issues with signals (35104 contains some
good gouge from Troy Noble on this and some source code to try):
signals and VC++
34947 by: "bucweat_20657" <bucweat_20657@yahoo.com>
control-c issue when running VC++ console programs in bash.exe
35104 by: "bucweat_20657" <bucweat_20657@yahoo.com>
I also sent the emails follow this to the person who developed a cygwin port
of wpcap.dll, which sounds very similar to your description. Question: where
did your .dll/.lib come from? Did you do a mapping of the .lib as described
by the FAQ (a la < http://cygwin.com/faq/faq_toc.html#TOC91 >) to a lib.a? Do
you have a simple example program that illustrates the problem?
*********** first email ( a little light reading :-) ****************
I've been playing around with the cygwin version of wpcap. I've come across
some interesting things that I was hoping to run by you to see if you've had
similar issues. So, if you've got a moment or too, please read on...
I currently have a command line program that I've written using MSVC++ that
uses winpcap (it's similar to ngrep actually). However, I'd like to be able
to run in bash shell. It turns out that signals from MSVC++ compiled
programs don't work well when run in bash (long story...minor details
coming). So, I tried compiling using g++ now that it is supported, thanks to
yourself :). I ran into some initial problems, so I simplified things by
working with a copy of the pcap_filter example that comes with Wpdpack
(version 2.2). I've implement a simple signal handler that sets a flag, and
replaced pcap_loop() with pcap_dispatch() so I can handle some event loop
stuff and allow for cleanup at the end via a clean_exit() function. Now when
I run the app and press control-c, the signal is trapped, calling a handler
which sets a flag. This exits a while( exitFlag == false) loop, where a
clean_exit() function is called, and then the program exits (firing off
destructors as required). This works fine. But keep reading...
In order to get signals to work correctly, I had to remove the -mno-cygwin
option. Why, you wonder? When you use this you end up with a DOS shell
program, which runs inside a stealth bash (compare windows NT/2000 task
manager to results of ps). When you control-c, the stealth bash shell and
its child app are killed immediately...no chance for destructors and
clean_exit() type functions to run. When compiled without -mno-cygwin the
program is compiled as a cygwin app and signals are handled correctly.
So, if you've got this far, the issue I'm seeing is that when the control-c
is issued, it takes awhile for the signal to get to the program. If you
comment out the pcap_dispatch() and replace with a usleep() to simulate the
timeout, the signal is handled immediately. Any ideas on how the cygwin
version of the library handles signals? Did you do a mapping of the .lib as
described by the FAQ (a la < http://cygwin.com/faq/faq_toc.html#TOC91 >)? Any
help or insights you could provide would be greatly appreciated.
************* followup ********************
A possible major update...I've noticed that when I run the example program I
sent to you and control-c, the program seems to exit relatively quickly if
the program is writing periods (".") to the screen AND when you select
another window (i.e. as soon as the bash window looses focus). However, if
you comment out "theDot()" function (in while loop at end of main) and
recompile, the program "hangs" with the CPU at 100% like before (a la
endless loop) and clicking another window has no affect, and it takes much
longer to exit if at all (ps -KILL still works).
So it would appear that writing to the console and changing window focus has
some affect on how control is passed around. I've tried running in the
debugger and it locks up. If you get a chance to try the program I'd be
interested to see if you get similar results.
BTW this program is available upon request, but you'll need wpcap to compile
and run it.
***************************************
VR, Charlie
-----Original Message-----
From: Bryant, Nathan [ mailto:nbryant@allegientsystems.com ]
Sent: Wednesday, September 05, 2001 8:28 PM
To: 'cygwin@cygwin.com'
Subject: pthread app hangs after Ctrl+C
Hi,
I have an application that hangs after Ctrl+C is pressed. I'm currently
running Cygwin DLL 1.3.2. Windows 2000's Task Manager shows the CPU at 100%
after ctrl+c, as long as the command window is in the foreground -- it idles
again if I Alt+tab somewhere else.
there are a couple oddball things that it's doing:
- the signal handler for SIGINT is a static function in a DLL. (the signal
handler just immediately returns, at the moment, but the behavior is the
same if it sets a volatile int to 1, signalling the main loop to quit...)
- the app uses pthreads.
it dies properly if i remove the signal handler entirely, and also exits
normally if i just do 'kill -INT' from another bash window, even if the
signal handler is installed; the problem only seems to appear with Ctrl+C.
If there is need, I could try to come up with a minimal test case, but maybe
this is already known and fixed in cygwin-current?
cygcheck output is attached.
<<cygcheck.out>>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: pthread app hangs after Ctrl+C
2001-09-05 17:26 Bryant, Nathan
@ 2001-09-06 19:05 ` bucweat_20657
0 siblings, 0 replies; 3+ messages in thread
From: bucweat_20657 @ 2001-09-06 19:05 UTC (permalink / raw)
To: Bryant, Nathan, cygwin
Hi Nathan,
I've run into some similar issues recently and so would like to add my $0.02
to show that more than one person has encountered it... check out the
following from this list regarding issues with signals (35104 contains some
good gouge from Troy Noble on this and some source code to try):
signals and VC++
34947 by: "bucweat_20657" <bucweat_20657@yahoo.com>
control-c issue when running VC++ console programs in bash.exe
35104 by: "bucweat_20657" <bucweat_20657@yahoo.com>
I also sent the emails follow this to the person who developed a cygwin port
of wpcap.dll, which sounds very similar to your description. Question: where
did your .dll/.lib come from? Did you do a mapping of the .lib as described
by the FAQ (a la < http://cygwin.com/faq/faq_toc.html#TOC91 >) to a lib.a? Do
you have a simple example program that illustrates the problem?
*********** first email ( a little light reading :-) ****************
I've been playing around with the cygwin version of wpcap. I've come across
some interesting things that I was hoping to run by you to see if you've had
similar issues. So, if you've got a moment or too, please read on...
I currently have a command line program that I've written using MSVC++ that
uses winpcap (it's similar to ngrep actually). However, I'd like to be able
to run in bash shell. It turns out that signals from MSVC++ compiled
programs don't work well when run in bash (long story...minor details
coming). So, I tried compiling using g++ now that it is supported, thanks to
yourself :). I ran into some initial problems, so I simplified things by
working with a copy of the pcap_filter example that comes with Wpdpack
(version 2.2). I've implement a simple signal handler that sets a flag, and
replaced pcap_loop() with pcap_dispatch() so I can handle some event loop
stuff and allow for cleanup at the end via a clean_exit() function. Now when
I run the app and press control-c, the signal is trapped, calling a handler
which sets a flag. This exits a while( exitFlag == false) loop, where a
clean_exit() function is called, and then the program exits (firing off
destructors as required). This works fine. But keep reading...
In order to get signals to work correctly, I had to remove the -mno-cygwin
option. Why, you wonder? When you use this you end up with a DOS shell
program, which runs inside a stealth bash (compare windows NT/2000 task
manager to results of ps). When you control-c, the stealth bash shell and
its child app are killed immediately...no chance for destructors and
clean_exit() type functions to run. When compiled without -mno-cygwin the
program is compiled as a cygwin app and signals are handled correctly.
So, if you've got this far, the issue I'm seeing is that when the control-c
is issued, it takes awhile for the signal to get to the program. If you
comment out the pcap_dispatch() and replace with a usleep() to simulate the
timeout, the signal is handled immediately. Any ideas on how the cygwin
version of the library handles signals? Did you do a mapping of the .lib as
described by the FAQ (a la < http://cygwin.com/faq/faq_toc.html#TOC91 >)? Any
help or insights you could provide would be greatly appreciated.
************* followup ********************
A possible major update...I've noticed that when I run the example program I
sent to you and control-c, the program seems to exit relatively quickly if
the program is writing periods (".") to the screen AND when you select
another window (i.e. as soon as the bash window looses focus). However, if
you comment out "theDot()" function (in while loop at end of main) and
recompile, the program "hangs" with the CPU at 100% like before (a la
endless loop) and clicking another window has no affect, and it takes much
longer to exit if at all (ps -KILL still works).
So it would appear that writing to the console and changing window focus has
some affect on how control is passed around. I've tried running in the
debugger and it locks up. If you get a chance to try the program I'd be
interested to see if you get similar results.
BTW this program is available upon request, but you'll need wpcap to compile
and run it.
***************************************
VR, Charlie
-----Original Message-----
From: Bryant, Nathan [ mailto:nbryant@allegientsystems.com ]
Sent: Wednesday, September 05, 2001 8:28 PM
To: 'cygwin@cygwin.com'
Subject: pthread app hangs after Ctrl+C
Hi,
I have an application that hangs after Ctrl+C is pressed. I'm currently
running Cygwin DLL 1.3.2. Windows 2000's Task Manager shows the CPU at 100%
after ctrl+c, as long as the command window is in the foreground -- it idles
again if I Alt+tab somewhere else.
there are a couple oddball things that it's doing:
- the signal handler for SIGINT is a static function in a DLL. (the signal
handler just immediately returns, at the moment, but the behavior is the
same if it sets a volatile int to 1, signalling the main loop to quit...)
- the app uses pthreads.
it dies properly if i remove the signal handler entirely, and also exits
normally if i just do 'kill -INT' from another bash window, even if the
signal handler is installed; the problem only seems to appear with Ctrl+C.
If there is need, I could try to come up with a minimal test case, but maybe
this is already known and fixed in cygwin-current?
cygcheck output is attached.
<<cygcheck.out>>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 3+ messages in thread
* pthread app hangs after Ctrl+C
@ 2001-09-05 17:26 Bryant, Nathan
2001-09-06 19:05 ` bucweat_20657
0 siblings, 1 reply; 3+ messages in thread
From: Bryant, Nathan @ 2001-09-05 17:26 UTC (permalink / raw)
To: 'cygwin@cygwin.com'
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
Hi,
I have an application that hangs after Ctrl+C is pressed. I'm currently
running Cygwin DLL 1.3.2. Windows 2000's Task Manager shows the CPU at 100%
after ctrl+c, as long as the command window is in the foreground -- it idles
again if I Alt+tab somewhere else.
there are a couple oddball things that it's doing:
- the signal handler for SIGINT is a static function in a DLL. (the signal
handler just immediately returns, at the moment, but the behavior is the
same if it sets a volatile int to 1, signalling the main loop to quit...)
- the app uses pthreads.
it dies properly if i remove the signal handler entirely, and also exits
normally if i just do 'kill -INT' from another bash window, even if the
signal handler is installed; the problem only seems to appear with Ctrl+C.
If there is need, I could try to come up with a minimal test case, but maybe
this is already known and fixed in cygwin-current?
cygcheck output is attached.
<<cygcheck.out>>
[-- Attachment #2: cygcheck.out --]
[-- Type: text/x-Algol68, Size: 8648 bytes --]
Cygnus Win95/NT Configuration Diagnostics
Current System Time: Wed Sep 5 20:28:46 2001
WinNT Ver 5.0 build 2195 Service Pack 2
Path: /c/j2sdkee1.2.1/bin
/usr/local/bin
/usr/bin
/bin
/c/Tcl/bin
/c/oracle/ora81/bin
/c/Program Files/Oracle/jre/1.1.7/bin
/c/WINNT/system32
/c/WINNT
/c/WINNT/System32/Wbem
/c/jbuilder4/jdk1.3/bin
/c/emacs-20.7/bin
/c/weblogic/bin/oci815_8
/c/jikes/bin
/c/Python20
/c/Program Files/rksupport
/c/program files/gnu/wincvs 1.3
/usr/bin
/usr/X11R6/bin
/usr/local/bin
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
PWD = `/home/Administrator'
USER = `Administrator'
MAKE_MODE = `unix'
HOME = `/home/Administrator'
NUMBER_OF_PROCESSORS = `1'
LOGONSERVER = `\\MADMAX'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
JAVAC = `javac'
COMSPEC = `C:\WINNT\system32\cmd.exe'
J2EE_HOME = `c:\j2sdkee1.2.1'
SYSTEMDRIVE = `C:'
CLASSPATH11 = ` '
HOSTNAME = `LASN-001'
PROCESSOR_REVISION = `0806'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
COMPUTERNAME = `LASN-001'
CLASSPATH = `.;c:\jakarta-regexp-1.2\jakarta-regexp-1.2.jar;c:\jakarta-oro-2.0.1\jakarta-oro-2.0.1.jar;c:\oreilly\classes;c:\oracle\ora81\jdbc\lib\classes12.zip;c:\weblogic\lib\weblogic510sp9.jar;c:\weblogic\lib\weblogicaux.jar;c:\weblogic\classes;c:\jbuilder4\jdk1.3\jre\lib\rt.jar;c:\cryptix\build\jars\cryptix-jce-api.jar;c:\cryptix\build\jars\cryptix-jce-provider.jar;c:\ssce\runtime\lib\ssce.jar'
WINDIR = `C:\WINNT'
USERPROFILE = `C:\Documents and Settings\nbryant'
PS1 = `\[\033]0;\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ '
PROGRAMFILES = `C:\Program Files'
MACHTYPE = `i686-pc-cygwin'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
OS = `Windows_NT'
CVS_RSH = `ssh'
OLDPWD = `/usr/bin'
PROCESSOR_ARCHITECTURE = `x86'
TEMP = `/tmp'
NTRESKIT = `C:\Program Files\rksupport'
PROCESSOR_LEVEL = `6'
SYSTEMROOT = `C:\WINNT'
HOMEDRIVE = `C:'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
SHLVL = `1'
JAVAC_FLAGS = ` '
APPDATA = `C:\Documents and Settings\nbryant\Application Data'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
HOMEPATH = `\'
USERDOMAIN = `GO-DATA'
USERNAME = `nbryant'
SHELL = `/bin/sh'
HOSTTYPE = `i686'
OSTYPE = `cygwin'
TERM = `cygwin'
JIKESPATH = `c:\jbuilder4\jdk1.3\jre\lib\rt.jar'
_ = `/usr/bin/cygcheck'
TZ = `EST5EDT4,M4.1.0/2,M10.5.0/2'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x00000022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\Programs\Cygnus Solutions
(default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:/cygwin'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
(default) = `C:'
flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/devel
(default) = `c:\development'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/london
(default) = `c:\weblogic\myserver\london'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/tmp
(default) = `c:\WINNT\TEMP'
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
a: fd N/A N/A
c: hd FAT32 19075Mb 45% CP UN
d: cd N/A N/A
q: net NTFS 12997Mb 45% CP CS UN PA FC
c:\weblogic\myserver\london /london system textmode
c:\development /devel system textmode
C:\cygwin\bin /usr/bin system binmode
C:\cygwin\lib /usr/lib system binmode
c:\WINNT\TEMP /tmp system binmode
C:\cygwin / system binmode
C: /c system binmode
q: /cygdrive/q user binmode,noumount
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\sh.exe
90k 2001/09/05 C:\cygwin\usr\local\bin\cygltdl-3.dll - os=4.0 img=1.0 sys=4.0
"cygltdl-3.dll" v0.0 ts=2001/9/4 20:46
841k 2001/09/06 C:\cygwin\usr\local\bin\cygcitserver.dll - os=4.0 img=1.0 sys=4.0
"cygcitserver.dll" v0.0 ts=2001/9/5 20:05
41k 2001/05/28 C:\cygwin\bin\cygXpm-noX4.dll - os=4.0 img=1.0 sys=4.0
"cygXpm-noX4.dll" v0.0 ts=2001/5/28 13:57
56k 2000/12/03 C:\cygwin\bin\cygbz21.0.dll - os=4.0 img=1.0 sys=4.0
"cygbz21.0.dll" v0.0 ts=2000/11/20 18:53
18k 2000/10/23 C:\cygwin\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm.dll" v0.0 ts=2000/10/22 22:26
14k 2000/10/23 C:\cygwin\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0
"cygintl.dll" v0.0 ts=2000/10/23 15:02
45k 2000/10/22 C:\cygwin\bin\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
"cygjbig1.dll" v0.0 ts=2000/10/22 19:06
17k 2001/01/07 C:\cygwin\bin\cyghistory4.dll - os=4.0 img=1.0 sys=4.0
"cyghistory4.dll" v0.0 ts=2001/1/6 23:34
108k 2001/01/07 C:\cygwin\bin\cygreadline4.dll - os=4.0 img=1.0 sys=4.0
"cygreadline4.dll" v0.0 ts=2001/1/6 23:34
45k 2000/11/20 C:\cygwin\bin\cygXpm-X4.dll - os=4.0 img=1.0 sys=4.0
"cygXpm-X4.dll" v0.0 ts=2000/11/19 21:45
49k 2001/02/03 C:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
"cygz.dll" v0.0 ts=2001/2/3 15:35
81k 2001/04/28 C:\cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
"cygitcl30.dll" v0.0 ts=2001/4/28 18:57
35k 2001/04/28 C:\cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
"cygitk30.dll" v0.0 ts=2001/4/28 18:57
390k 2001/04/28 C:\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
"cygtcl80.dll" v0.0 ts=2001/4/28 18:56
5k 2001/04/28 C:\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
10k 2001/04/28 C:\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
"cygtclreg80.dll" v0.0 ts=2001/4/28 18:56
623k 2001/04/28 C:\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
"cygtk80.dll" v0.0 ts=2001/4/28 18:57
119k 2001/06/06 C:\cygwin\bin\cygjpeg6b.dll - os=4.0 img=1.0 sys=4.0
"cygjpeg6b.dll" v0.0 ts=2001/6/6 0:27
163k 2001/05/06 C:\cygwin\bin\cygpng2.dll - os=4.0 img=1.0 sys=4.0
"cygpng2.dll" v0.0 ts=2001/5/6 0:05
45k 2001/04/25 C:\cygwin\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
"cygform5.dll" v0.0 ts=2001/4/25 1:28
26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll - os=4.0 img=1.0 sys=4.0
"cygmenu5.dll" v0.0 ts=2001/4/25 1:27
156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++5.dll" v0.0 ts=2001/4/25 1:29
226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll - os=4.0 img=1.0 sys=4.0
"cygncurses5.dll" v0.0 ts=2001/4/25 1:17
15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll - os=4.0 img=1.0 sys=4.0
"cygpanel5.dll" v0.0 ts=2001/4/25 1:27
245k 2001/06/12 C:\cygwin\bin\cygtiff3.dll - os=4.0 img=1.0 sys=4.0
"cygtiff3.dll" v0.0 ts=2001/6/12 13:25
678k 2001/05/21 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2001/5/20 23:28
Cygwin DLL version info:
dll major: 1003
dll minor: 2
dll epoch: 19
dll bad signal mask: 19005
dll old termios: 5
dll malloc env: 28
api major: 0
api minor: 39
shared data: 3
dll identifier: cygwin1
mount registry: 2
cygnus registry name: Cygnus Solutions
cygwin registry name: Cygwin
program options name: Program Options
cygwin mount registry name: mounts v2
cygdrive flags: cygdrive flags
cygdrive prefix: cygdrive prefix
cygdrive default prefix:
build date: Sun May 20 23:28:17 EDT 2001
shared id: cygwin1S3
Use -h to see help about each section
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-09-06 20:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-06 20:00 pthread app hangs after Ctrl+C Bryant, Nathan
-- strict thread matches above, loose matches on Subject: below --
2001-09-05 17:26 Bryant, Nathan
2001-09-06 19:05 ` bucweat_20657
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).