DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:cc:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=MeuNnUJSEKai1/bAnyCsObp4JkPVI
	98qbFHYQvqw7YwwIfxgQy0PS1v/AMiZZzVGTizUglXsmRdf9Tjncsql328NAcSk0
	uCoNgaUwaXWzyH8c7E8NFREHMSfnNlq2SUB5MvPbjxeMyEZrgC8j+NZYGnI7mB5D
	TDVCtX7rUxXVuM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE01-DOR.bell.corp.bce.ca
From: "Martens, Robert (EY28737)" <robert DOT martens AT bell DOT ca>
To: Maarten Jacobs <maarten256 AT hotmail DOT com>
CC: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: RE: Python stackdump on "succesful" exit after import of python-requests
Date: Tue, 2 Feb 2016 05:58:11 +0000
Message-ID: <109e1012-ea7f-4852-b548-2116de770061@email.android.com>
References: <7dd1bf85a74041df90f65fb31e9279fe AT DG4MBX01-WYN DOT bell DOT corp DOT bce DOT ca>,<BLU170-W99FA16FE5288347E01FB999EDC0 AT phx DOT gbl>,<BLU170-W28BA1FA3D09DE0C786414E9EDE0 AT phx DOT gbl>,<BLU170-W78DB57E642F57E3BB5F70A9EDE0 AT phx DOT gbl>,<BLU170-W44598E53FF6CD3776E07549EDF0 AT phx DOT gbl>
In-Reply-To: <BLU170-W44598E53FF6CD3776E07549EDF0@phx.gbl>
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Received-SPF: SoftFail (EX13EDGE01-DOR.bell.corp.bce.ca: domain of transitioning robert DOT martens AT bell DOT ca discourages use of 142.182.18.35 as permitted sender)
X-OrganizationHeadersPreserved: EX13EDGE01-DOR.bell.corp.bce.ca
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u125wZ7w013326

Hello Maarten,
I won't be a lot of help with the low level debugging here but I do have some suggestions.
The issue occurs for me whenever I import 'requests', could you try importing that module in your tests see if it also happens to you?

I'm wondering if this is just a common problem between modules or if it is inherit in python itself.

The other thing I noticed is that in a fresh install of 64 bit cygwin, the issue does not occur!

I'm going to see if I can isolate it further...

Thanks for your help!
--
Robert Martens
613 807 6137
ADMS System Administrator

On Feb 1, 2016 9:05 PM, Maarten Jacobs <maarten256 AT hotmail DOT com> wrote:
Still whittling away at this issue. I installed a few more debug libraries, and the traceback now looks like:

(gdb) r generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
Starting program: /usr/bin/python generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
[New Thread 6688.0x730]
[New Thread 6688.0x1d44]
[New Thread 6688.0x1c68]
[New Thread 6688.0x12d8]
Found 406 functions in /usr/share/libvirt/api/libvirt-api.xml
Found 0 functions in libvirt-override-api.xml
Generated 338 wrapper functions
Done!

Program received signal SIGABRT, Aborted.
0x66b73de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
1780        exit(sts);
(gdb) bt
#0  0x66b73de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
#1  0x76e8e091 in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
#2  0x76e8dff2 in WaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
#3  0x610f2730 in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12 (p=p AT entry=0x60fd0000, si=..., tls=tls AT entry=0x0)
    at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/sigproc.cc:716
#4  0x610ef4cc in _pinfo::kill(siginfo_t&)@8 (this=0x60fd0000, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:252
#5  0x610ef9d8 in kill0 (pid=pid AT entry=6688, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:303
#6  0x610efbb2 in kill (sig=sig AT entry=6, pid=6688) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:312
#7  raise (sig=sig AT entry=6) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:288
#8  0x610efe79 in abort () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:375
#9  0x6deb43c1 in __deregister_frame_info_bases (begin=0x6e200000 <__EH_FRAME_BEGIN__>) at /usr/src/debug/gcc-4.9.3-1/libgcc/unwind-dw2-fde.c:216
#10 0x6e1e10e2 in __gcc_deregister_frame () from /usr/bin/cygexpat-1.dll
#11 0x61028bb7 in per_module::run_dtors (this=0x6130d658) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:81
#12 dll::run_dtors (this=0x6130d650) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.h:72
#13 dll_global_dtors () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:53
#14 0x6118d64d in __call_exitprocs (code=code AT entry=0, d=d AT entry=0x0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/__call_atexit.c:118
#15 0x6114ae88 in exit (code=0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/exit.c:66
#16 0x61006e79 in cygwin_exit (n=0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dcrt0.cc:1337
#17 0x610ebf85 in _sigfe () at sigfe.s:38
#18 0x66b73de4 in Py_Exit (sts=sts AT entry=0) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
#19 0x66ba5281 in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1152
#20 0x66b7413e in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1193
#21 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars AT entry=1) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1162
#22 0x66b74bc7 in PyErr_Print () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1065
#23 PyRun_SimpleFileExFlags (fp=<optimized out>, filename=0x60cc5c "generator.py", closeit=1, flags=0x60cb5c)
    at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:953
#24 0x66b8ae9e in Py_Main (argc=argc AT entry=4, argv=argv AT entry=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/main.c:640
#25 0x00401750 in main (argc=4, argv=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/python.c:23

Having pored over this traceback 100 times now, the current questions I'm trying to figure out, and I'd like some help with:

1. #20 of the traceback shows "0x66b7413e in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1193" doesn't make sense since line 1193 of pythonrun.c is not anywhere near "handle_system_exit()". Line 1152 on #19 IS in handle_system_exit(). Does this mean the traceback is no good?

2. #10 of the traceback shows "#10 0x6e1e10e2 in __gcc_deregister_frame () from /usr/bin/cygexpat-1.dll" - I cannot for the life of me figure out how I get debug symbols for this?

Thanks,

Maarten Jacobs

----------------------------------------
> From: maarten256 AT hotmail DOT com
> To: cygwin AT cygwin DOT com
> CC: robert DOT martens AT bell DOT ca
> Subject: RE: Python stackdump on "succesful" exit after import of python-requests
> Date: Mon, 1 Feb 2016 00:36:02 -0500
>
> I installed the debug version of gcc and the traceback became a little more readable:
>
> (gdb) bt
> #0 0x66b73de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
> #1 0x76e8e091 in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
> #2 0x76e8dff2 in WaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
> #3 0x610f2730 in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12 (p=p AT entry=0x60fd0000, si=..., tls=tls AT entry=0x0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/sigproc.cc:716
> #4 0x610ef4cc in _pinfo::kill(siginfo_t&)@8 (this=0x60fd0000, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:252
> #5 0x610ef9d8 in kill0 (pid=pid AT entry=4080, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:303
> #6 0x610efbb2 in kill (sig=sig AT entry=6, pid=4080) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:312
> #7 raise (sig=sig AT entry=6) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:288
> #8 0x610efe79 in abort () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:375
> #9 0x6deb43c1 in __deregister_frame_info_bases (begin=0x6e200000) at /usr/src/debug/gcc-4.9.3-1/libgcc/unwind-dw2-fde.c:216
> #10 0x6e1e10e2 in ?? () from /usr/bin/cygexpat-1.dll
> #11 0x61028bb7 in per_module::run_dtors (this=0x6130d6c0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:81
> #12 dll::run_dtors (this=0x6130d6b8) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.h:72
> #13 dll_global_dtors () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:53
> #14 0x6118d64d in __call_exitprocs (code=code AT entry=0, d=d AT entry=0x0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/__call_atexit.c:118
> #15 0x6114ae88 in exit (code=0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/exit.c:66
> #16 0x61006e79 in cygwin_exit (n=0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dcrt0.cc:1337
> #17 0x610ebf85 in _sigfe () at sigfe.s:38
> #18 0x66b73de4 in Py_Exit (sts=sts AT entry=0) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
> #19 0x66ba5281 in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1152
> #20 0x66b7413e in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1193
> #21 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars AT entry=1) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1162
> #22 0x66b74bc7 in PyErr_Print () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1065
> #23 PyRun_SimpleFileExFlags (fp=<optimized out>, filename=0x60cc5c "generator.py", closeit=1, flags=0x60cb5c) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:953
> #24 0x66b8ae9e in Py_Main (argc=argc AT entry=4, argv=argv AT entry=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/main.c:640
> #25 0x00401750 in main (argc=4, argv=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/python.c:23
> (gdb) up 9
> #9 0x6deb43c1 in __deregister_frame_info_bases (begin=0x6e200000) at /usr/src/debug/gcc-4.9.3-1/libgcc/unwind-dw2-fde.c:216
> 216 gcc_assert (ob);
> (gdb)
>
> So looks like the problem occurs on an "assert". I need to dig further into this - but that's for tomorrow / later this week.
>
> Thanks,
>
> Maarten Jacobs
>
> ----------------------------------------
>> From: maarten256 AT hotmail DOT com
>> To: cygwin AT cygwin DOT com
>> CC: robert DOT martens AT bell DOT ca
>> Subject: RE: Python stackdump on "succesful" exit after import of python-requests
>> Date: Sun, 31 Jan 2016 23:55:14 -0500
>>
>> I realized that for me, the "work-around" to use python3 was not practical, so I am back to analyzing this problem... And not making much progress. Some help/assistance would be appreciated!
>>
>> I got the following traceback:
>>
>> (gdb) r generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
>> Starting program: /usr/bin/python generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
>> [New Thread 7028.0xb4]
>> [New Thread 7028.0x1998]
>> [New Thread 7028.0x1070]
>> [New Thread 7028.0x15d8]
>> [New Thread 7028.0x1d38]
>>
>> Found 406 functions in /usr/share/libvirt/api/libvirt-api.xml
>> Found 0 functions in libvirt-override-api.xml
>> Generated 338 wrapper functions
>>
>> Program received signal SIGABRT, Aborted.
>> 0x66b73de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
>> 1780 exit(sts);
>> (gdb) bt
>> #0 0x66b73de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
>> #1 0x76e8e091 in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
>> #2 0x76e8dff2 in WaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
>> #3 0x610f2730 in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12 (p=p AT entry=0x60fd0000, si=..., tls=tls AT entry=0x0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/sigproc.cc:716
>> #4 0x610ef4cc in _pinfo::kill(siginfo_t&)@8 (this=0x60fd0000, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:252
>> #5 0x610ef9d8 in kill0 (pid=pid AT entry=7028, si=...) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:303
>> #6 0x610efbb2 in kill (sig=sig AT entry=6, pid=7028) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:312
>> #7 raise (sig=sig AT entry=6) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:288
>> #8 0x610efe79 in abort () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:375
>> #9 0x6deb43c1 in cyggcc_s-1!.deregister_frame_info_bases () from /usr/bin/cyggcc_s-1.dll
>> #10 0x6e1e10e2 in ?? () from /usr/bin/cygexpat-1.dll
>> #11 0x61028bb7 in per_module::run_dtors (this=0x6130d980) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:81
>> #12 dll::run_dtors (this=0x6130d978) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.h:72
>> #13 dll_global_dtors () at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:53
>> #14 0x6118d64d in __call_exitprocs (code=code AT entry=0, d=d AT entry=0x0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/__call_atexit.c:118
>> #15 0x6114ae88 in exit (code=0) at /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/exit.c:66
>> #16 0x61006e79 in cygwin_exit (n=0) at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dcrt0.cc:1337
>> #17 0x610ebf85 in _sigfe () at sigfe.s:38
>> #18 0x66b73de4 in Py_Exit (sts=sts AT entry=0) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
>> #19 0x66ba5281 in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1152
>> #20 0x66b7413e in handle_system_exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1193
>> #21 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars AT entry=1) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1162
>> #22 0x66b74bc7 in PyErr_Print () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1065
>> #23 PyRun_SimpleFileExFlags (fp=<optimized out>, filename=0x60cc5c "generator.py", closeit=1, flags=0x60cb5c) at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:953
>> #24 0x66b8ae9e in Py_Main (argc=argc AT entry=4, argv=argv AT entry=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/main.c:640
>> #25 0x00401750 in main (argc=4, argv=0x60cc1c) at /usr/src/debug/python-2.7.10-1/Modules/python.c:23
>>
>> I'm used to looking at tracebacks from C++ executables, so most of this feels familiar.
>>
>> It would appear that deregister_frame_info_bases () (on #9) causes the abort to happen. As far as I have been able to figure out, all of this happens while the instance of Python is being shut down.
>>
>> This is also not a new problem, as this was apparently already reported in November of 2014:
>>
>> http://readlist.com/lists/cygwin.com/cygwin/15/75280.html
>>
>> Unfortunately that thread does not go any further than what is also apparent from my traceback.
>>
>> Does anybody have suggestions on how to further debug this issue?
>>
>> Thanks,
>>
>> Maarten Jacobs
>>
>>> From: maarten256 AT hotmail DOT com
>>> To: robert DOT martens AT bell DOT ca; cygwin AT cygwin DOT com
>>> Subject: RE: Python stackdump on "succesful" exit after import of python-requests
>>> Date: Sat, 30 Jan 2016 18:21:45 -0500
>>>
>>> Interesting - I had the same issue earlier this week; I worked around it by using python3 instead, which didn't cause the same issue. (I figured it was just me not doing something right).
>>>
>>> Obviously that doesn't explain the behavior but I didn't have time to further investigate the issue with python 2.7.
>>>
>>> I ran into the issue when I was trying to build libvirt-python on Cygwin.
>>>
>>> I'd be curious to know what the real root cause for this abort is.
>>>
>>> Thanks,
>>>
>>> Maarten Jacobs
>>>
>>> ----------------------------------------
>>> From: robert DOT martens AT bell DOT ca
>>> To: cygwin AT cygwin DOT com
>>> Subject: Python stackdump on "succesful" exit after import of python-requests
>>> Date: Fri, 29 Jan 2016 21:38:54 +0000
>>>
>>>
>>> Hello,
>>> I am having a strange issue with Python 2.7 on cygwin.
>>> Whenever a script of mine imports 'requests' (python-requests installed via cygwin installer), after it closes I get an "Aborted" message and a stack dump.
>>>
>>> This consistently causes the issue:
>>> $ python
>>> Python 2.7.10 (default, Jun 1 2015, 18:17:45)
>>> [GCC 4.9.2] on cygwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> import requests
>>>>>> exit()
>>> Aborted (core dumped)
>>>
>>> And here is the stackdump
>>> $ cat python2.7.exe.stackdump
>>> Stack trace:
>>> Frame Function Args
>>> 0028C868 61033A23 (00000244, 0000EA60, 000000A4, 0028C8D8)
>>> 0028C998 610F27E2 (000000C8, 000000CC, 000000B8, 6111295F)
>>>
>>> This is what gdb says:
>>> (gdb) r
>>> Starting program: /usr/bin/python
>>> [New Thread 8744.0x1ca0]
>>> [New Thread 8744.0x24f4]
>>> [New Thread 8744.0x192c]
>>> [New Thread 8744.0x11f0]
>>> Python 2.7.10 (default, Jun 1 2015, 18:17:45)
>>> [GCC 4.9.2] on cygwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> import requests
>>> [New Thread 8744.0x2380]
>>>>>> quit()
>>>
>>> Program received signal SIGABRT, Aborted.
>>> 0x65c63de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
>>> 1780 exit(sts);
>>> (gdb) bt
>>> #0 0x65c63de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
>>> #1 0x770ff8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SysWOW64/ntdll.dll
>>> #2 0x765014b9 in WaitForSingleObjectEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
>>> #3 0x000002f8 in ?? ()
>>> #4 0x00000000 in ?? ()
>>> (gdb) continue
>>> Continuing.
>>> [New Thread 8744.0x25c4]
>>> 3 [main] python2.7 8744 cygwin_exception::open_stackdumpfile: Dumping stack trace to python2.7.exe.stackdump
>>> [Thread 8744.0x24f4 exited with code 34304]
>>> [Thread 8744.0x25c4 exited with code 34304]
>>> [Thread 8744.0x2380 exited with code 34304]
>>> [Thread 8744.0x192c exited with code 34304]
>>> [Inferior 1 (process 8744) exited with code 0103000]
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> Robert Martens
>>> ADMS
>>>
>>>
>>> --
>>> 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
>>>
>>> --
>>> 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
>>>
>>
>> --
>> 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
>>
>
> --
> 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
>


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