Perl module Net::SMTP->auth() error with Authen::SASL::XS
MTP::_SSL=GLOB(0x206715f0)>>>
Net::SMTP::_SSL=GLOB(0x206715f0)>>> Best regards.
Net::SMTP::_SSL=GLOB(0x206715f0)>>> .
Net::SMTP::_SSL=GLOB(0x206715f0)<<< 250 2.0.0 Ok: queued on
smtp1h.mail.yandex.net as 1464747226-BQFvPGbm8R-DjMKLPln
Net::SMTP::_SSL=GLOB(0x206715f0)>>> QUIT
Net::SMTP::_SSL=GLOB(0x206715f0)<<< 221 2.0.0 Closing connection.
Authen::SASL POD says:
The framework allows different implementations of the connection class to be
plugged in...
By default the order in which these plugins are selected is
Authen::SASL::XS, Authen::SASL::Cyrus and then Authen::SASL::Perl.
If you want to change it or want to specifically use one implementation only
simply do
use Authen::SASL qw(Perl);
but I don't want to change Net::SMTP module that uses that code (uses default
Authen::SASL plugin):
/usr/lib/perl5/5.22/Net/SMTP.pm (160):
eval {
require MIME::Base64;
require Authen::SASL;
} or $self->set_status(500, ["Need MIME::Base64 and Authen::SASL todo
auth"]), return 0;
Problem? Is Authen::SASL::XS so required to install with Authen::SASL if
Authen::SASL works fine without it? I'm not expert in Perl, but I think that
module's code says "use what you found":
/usr/lib/perl5/vendor_perl/5.22/Authen/SASL.pm (13):
@Plugins = qw(
Authen::SASL::XS
Authen::SASL::Cyrus
Authen::SASL::Perl
);
sub import {
shift;
return unless @_;
local $SIG{__DIE__};
@Plugins = grep { /^[:\w]+$/ and eval "require $_" } map { /::/ ? $_ :
"Authen::SASL::$_" } @_
or croak "no valid Authen::SASL plugins found";
}
Google found couple pages for me where advised to remove Authen::SASL::XS.
https://foswiki.org/Support/Faq69
Authen::SASL comes with a pure perl version of the mechanism, and can also
use some optional implementations: Authen::SASL::XS or Authen::SASL:Cyrus.
If either the XS or Cyrus modules are installed, try removing them.
https://rtcpan.develooper.com/Public/Bug/Display.html?id=100235
$client is now set but $client->mechanism returns undef. Therefore
$mechanisms =~ s/\b\Q$failed_mechanism\E\b//; does not change $mechanisms at
all and the loop tries the same $mechanisms over and over again.
Uninstalling Authen::SASL::XS is as a workaround for us since with
Authen::SASL::Perl everything seems to work just fine.
They says about "Error: Use of uninitialized value $_..." and unknown
authentication mechanism but about removing Authen::SMTP::XS too.
Thanks.
Sorry for the verbosity.
--
Oleg
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: SSHD not connecting from outside(real) IP
04.01.2016 22:05, João Paulo writes: Hello all, I have a mystery and I need help. I have openssh(Cygwin) installed and working just fine in here. I can connect normally from any of my machines to the server using local IPs. Ex: ssh localhost or ssh 192.168.0.2. BUT, when using my external IP(over internet->real IP) it times out. I can validate that the service is up and running on http://www.canyouseeme.org/ on the port FW I did for this service. Port 22 is correctly FW to my SSHD server. On windows, I can only see an entry on Security Events(attached) and nothing else after that. (Means it is reaching my machine) I have tried to reinstall Cygwin, change ports. sshd_config is in default, disable firewall, AV. I ran out of ideas.. I had this working fine on previous window 7, now I am on Windows 10. Thanks. Try to issue the `traceroute' command to your real IP over the Internet from a Linux computer and specify packet length 1452. If it fails, then maybe a misconfigured router (e.g. CISCO) on the way has a lesser MTU set and large packets sent by SSH do not get through. If your Internet service provider indeed has this problem, then "MSS FIX 1452" command issued on a CISCO router may fix it. Oleg -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH] Fix errno codes set by opendir() in case of problems with the path argument
On Mon, 3 Mar 2014 14:32:01 -0500, Christopher Faylor wrote: On Mon, Mar 03, 2014 at 10:34:59PM +0400, Oleg Kravtsov wrote: Currently cygwin has a problem with errno code set by opendir() function. It always sets errno to ENOENT. After applying the path opendir() sets errno to 'ENAMETOOLONG' when path or a path component is too long, 'ELOOP' when a loop of symbolic links exits in the path. 2014-02-18 Oleg Kravtsov oleg.kravt...@oktetlabs.ru * dir.cc (opendir): Set errno code depending on the type of an error instead of always setting it to ENOENT. Thanks for the patch but I don't see any reason for a goto here. Also you seem to be skipping over a free which could result in a memory leak. Actually I wanted opendir() to be in sync with other functions (mkdir, rmdir), i.e. use the same style. There is no memory leak in the proposed patch, but it does not matter, your patch is also a valid one, though not comply the style used in other functions. I think the below should do the same thing without those limitations. Yes, please fix it in a way you think is the most preferable. Does it work for you? Yes, thanks. Oleg
[PATCH] Fix errno codes set by opendir() in case of problems with the path argument
Currently cygwin has a problem with errno code set by opendir()
function. It always sets errno to ENOENT.
After applying the path opendir() sets errno to 'ENAMETOOLONG' when path
or a path component is too long,
'ELOOP' when a loop of symbolic links exits in the path.
Best regards,
Oleg
2014-02-18 Oleg Kravtsov oleg.kravt...@oktetlabs.ru
* dir.cc (opendir): Set errno code depending on the type of an error
instead of always setting it to ENOENT.
Index: cygwin/dir.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dir.cc,v
retrieving revision 1.136
diff -u -p -r1.136 dir.cc
--- cygwin/dir.cc 31 Jan 2014 19:27:26 - 1.136
+++ cygwin/dir.cc 3 Mar 2014 18:33:55 -
@@ -57,7 +57,16 @@ opendir (const char *name)
fh = build_fh_name (name, PC_SYM_FOLLOW);
if (!fh)
-res = NULL;
+{
+ res = NULL;
+ goto done;
+}
+
+ if (fh-error ())
+{
+ debug_printf (got %d error from build_fh_name, fh-error ());
+ set_errno (fh-error ());
+}
else if (fh-exists ())
res = fh-opendir (-1);
else
@@ -71,6 +80,8 @@ opendir (const char *name)
/* Applications calling flock(2) on dirfd(fd) need this... */
if (res !fh-nohandle ())
fh-set_unique_id ();
+
+done:
return res;
}
RE: UDP/DTLS sockets communication pattern is broken in Cygwin
However, I think I found a workaround on the application level. Apparently all packets sent to a specific address are sent to the first socket which has been bound to the address. If that socket has been closed, the next in line gets the packets (unless it has been connected and the sender is not the connected address). So what I did was this: Before starting step 14, I created a third socket, which then replaced the server socket: Thank you, Corinna, for the reply and for the idea. Unfortunately, the workaround will work well only in the case of a single client. In the multiple clients scenario, it will create a sort of race condition: 1) some packets already scheduled by OS to the original packet will be lost; 2) some packets delivered in between the sockets destruction/creation will be wrongly rejected. But this is better than nothing. I'll think whether we can live with it. Regards, Oleg
RE: UDP/DTLS sockets communication pattern is broken in Cygwin
Too bad. I don't know the DTLS protocol, but isn't it possible to do the server part with a single UDP socket? If you keep track of the already connected clients, you know if the just incoming packet is a connected or connecting client, and then you can use different threads to handle the packet further. Corinna Corinna, I suppose that it would be possible with a different API. The API that OpenSSL provides makes it rather difficult. A DTLS session is served by a BIO object that has a dedicated socket underneath it. I am not aware whether a workaround is possible. May be application can replace that BIO with something artificial but I am not sure that that's possible. The same problem happens even with plain UDP when many clients (thousands) are talking to the same single UDP port (for example, a TURN server). The workaround would be to create an extra application layer on top of sockets layer to differentiate packet streams by their remote address. With POSIX behavior, such a layer is not necessary. Oleg
UDP/DTLS sockets communication pattern is broken in Cygwin
Hi All I found a non-standard behavior of UDP sockets in Cygwin. Normally, people = do not experience it, but the communication pattern that I am going to desc= ribe here is often used in DTLS (actually, this is virtually the only way t= o make OpenSSL working with DTLS on the server side), so I suppose that wit= h the growing DTLS popularity people will experience the problem often. So this is how to reproduce the problem in plain UDP (without actually using DTLS): 1) Server application: open a UDP socket (socket A); 2) Server application: bind socket A to a local server address (say, 172.17.17.107:3478); 3) Server application: wait for a packet from a client application; 4) Client application: open a UDP socket (socket C); 5) Client application: bind socket C it to a local client address (say, 168.16.16.106:12345); 6) Client application: send a UDP packet P1 from socket C to server socket A (to 172.17.17.107:3478); 7) Server application: socket A receives the packet P1 from socket C; 8) Server application: create another UDP socket B; 9) Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket A (172.17.17.107:3478); 10) Server application: connect socket B to the remote address of socket C (168.16.16.106:12345) by calling connect() on the datagram socket B. 11) Server application: send packet P2 from socket B to socket C (to 168.16.16.106:12345). 12) Client application: on socket C, receive packet P2 from socket B (from 172.17.17.107:3478). 13) Client application: from socket C, send packet P3 to the server address 172.17.17.107:3478. 14) Server application: socket A receives the packet P3 from the client socket. ERROR !!! Step 14 is wrong: the packet P3 must be delivered to socket B, because socket B is connected to the remote address 168.16.16.106:12345, but socket A is unconnected. Both sockets (A and B) are bound to the same server ad= dress (172.17.17.107:3478) but the connected one (socket B) must be obtaining packets from the remote address that it is connected to. This is a very essential functionality for anybody who wants to implement the server-side DTLS communications. This patterns works in any OS that I tried (all FreeBSD versions, all Linux versions and Solaris) but Cygwin fails, unfortunately. I am trying to migrate (port) our server application to Cygwin, and it stops us completely. It works everywhere else. Please take a look if this is something that can be fixed quickly. Thanks! Oleg Moskalenko -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: UDP/DTLS sockets communication pattern is broken in Cygwin
I can write a simple test server and client programs and I'll post it here,= in a few hours. Our existing code is just too large. Thanks Oleg On Thu, Apr 11, 2013 at 02:19:25PM -0700, Oleg Moskalenko wrote: Hi All I found a non-standard behavior of UDP sockets in Cygwin. Normally, people = do not experience it, but the communication pattern that I am going to desc= ribe here is often used in DTLS (actually, this is virtually the only way t= o make OpenSSL working with DTLS on the server side), so I suppose that wit= h the growing DTLS popularity people will experience the problem often. So this is how to reproduce the problem in plain UDP (without actually using DTLS): 1) Server application: open a UDP socket (socket A); 2) Server application: bind socket A to a local server address (say, 172.17.17.107:3478); 3) Server application: wait for a packet from a client application; 4) Client application: open a UDP socket (socket C); 5) Client application: bind socket C it to a local client address (say, 168.16.16.106:12345); 6) Client application: send a UDP packet P1 from socket C to server socket A (to 172.17.17.107:3478); 7) Server application: socket A receives the packet P1 from socket C; 8) Server application: create another UDP socket B; 9) Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket A (172.17.17.107:3478); 10) Server application: connect socket B to the remote address of socket C (168.16.16.106:12345) by calling connect() on the datagram socket B. 11) Server application: send packet P2 from socket B to socket C (to 168.16.16.106:12345). 12) Client application: on socket C, receive packet P2 from socket B (from 172.17.17.107:3478). 13) Client application: from socket C, send packet P3 to the server address 172.17.17.107:3478. 14) Server application: socket A receives the packet P3 from the client socket. ERROR !!! Step 14 is wrong: the packet P3 must be delivered to socket B, because socket B is connected to the remote address 168.16.16.106:12345, but socket A is unconnected. Both sockets (A and B) are bound to the same server ad= dress (172.17.17.107:3478) but the connected one (socket B) must be obtaining packets from the remote address that it is connected to. This is a very essential functionality for anybody who wants to implement the server-side DTLS communications. This patterns works in any OS that I tried (all FreeBSD versions, all Linux versions and Solaris) but Cygwin fails, unfortunately. I am trying to migrate (port) our server application to Cygwin, and it stops us completely. It works everywhere else. Please take a look if this is something that can be fixed quickly. How about a simple test case? 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 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: UDP/DTLS sockets communication pattern is broken in Cygwin
I am sending the test case in the attachment. In the attachment, you will find source code for two programs - udpbugserver and udpbugclient. make will build them both. They work perfectly together in Linux, FreeBSD and Solaris. But they fail in Cygwin. Thanks Oleg On Thu, Apr 11, 2013 at 02:19:25PM -0700, Oleg Moskalenko wrote: Hi All I found a non-standard behavior of UDP sockets in Cygwin. Normally, people = do not experience it, but the communication pattern that I am going to desc= ribe here is often used in DTLS (actually, this is virtually the only way t= o make OpenSSL working with DTLS on the server side), so I suppose that wit= h the growing DTLS popularity people will experience the problem often. So this is how to reproduce the problem in plain UDP (without actually using DTLS): 1) Server application: open a UDP socket (socket A); 2) Server application: bind socket A to a local server address (say, 172.17.17.107:3478); 3) Server application: wait for a packet from a client application; 4) Client application: open a UDP socket (socket C); 5) Client application: bind socket C it to a local client address (say, 168.16.16.106:12345); 6) Client application: send a UDP packet P1 from socket C to server socket A (to 172.17.17.107:3478); 7) Server application: socket A receives the packet P1 from socket C; 8) Server application: create another UDP socket B; 9) Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket A (172.17.17.107:3478); 10) Server application: connect socket B to the remote address of socket C (168.16.16.106:12345) by calling connect() on the datagram socket B. 11) Server application: send packet P2 from socket B to socket C (to 168.16.16.106:12345). 12) Client application: on socket C, receive packet P2 from socket B (from 172.17.17.107:3478). 13) Client application: from socket C, send packet P3 to the server address 172.17.17.107:3478. 14) Server application: socket A receives the packet P3 from the client socket. ERROR !!! Step 14 is wrong: the packet P3 must be delivered to socket B, because socket B is connected to the remote address 168.16.16.106:12345, but socket A is unconnected. Both sockets (A and B) are bound to the same server ad= dress (172.17.17.107:3478) but the connected one (socket B) must be obtaining packets from the remote address that it is connected to. This is a very essential functionality for anybody who wants to implement the server-side DTLS communications. This patterns works in any OS that I tried (all FreeBSD versions, all Linux versions and Solaris) but Cygwin fails, unfortunately. I am trying to migrate (port) our server application to Cygwin, and it stops us completely. It works everywhere else. Please take a look if this is something that can be fixed quickly. How about a simple test case? 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 cygwinbug.tar.gz Description: cygwinbug.tar.gz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please test latest developer snapshot
I have got error similar to one described in http://www.mail-archive.com/cygwin at cygwin.com/msg114840.html Cygwin works fine until I install screens, try using git in screens, get error related to git repository name in prompt and then uninstall screens. In screens: sh: __git_ps1: command not found omarchuk@OMarchuk /cygdrive/c/git/gpag $rm /cygdrive/c/git/gpag/.git/index.lock rm: cannot remove `/cygdrive/c/git/gpag/.git/index.lock': No such file or directory sh: __git_ps1: command not found Then: omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java 6 [main] git 12192 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487 Stack trace: Frame Function Args 00229AF4 6102792B (00229AF4, , , ) 00229DE4 6102792B (6117DC60, 8000, , 6117F977) 0022AE14 61004F3B (6117F101, 0022AE40, 6C2E6D6F, 666F7875) 0022B074 6100176E (610EECC1, 0022B0A0, 70697263, 690A3B74) 0022B0B8 6115DE2C (6123D0E0, 666F7875, 64652E74, 672E736D) 0022B0E8 610EF04E (0022B130, , 726F706D, 6F632074) 0022B148 610C2C45 (0053A820, , 0124, 0010) 0022B168 00467C20 (0053A820, 0124, 0010, 00482D3E) 0022B198 00482F4A (0022C2D4, 746E656D, 6E616542, 74786520) 0022C298 0048315B (7FF8, 00022468, , 006E0910) 0022C2F8 00485A04 (7FF8, 00022468, 004FF6E4, 006CE684) 0022C338 00485A84 (0001, 0003, 00605908, 0002) 0022C378 00485CBA (006CE684, 0005, 0022C458, 0001) 0022C3B8 00485E3A (006CE684, 00605908, 0022C458, 0001) 0022C438 0046DD75 (00550E00, 00605908, 0022C458, ) 0022C4C8 004179C9 (00510B90, 0001, , ) End of stack trace (more stack frames may be present) Hangup omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java fatal: Unable to create '/cygdrive/c/git/gpag/.git/index.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$rm /cygdrive/c/git/gpag/.git/index.lock omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$uname -a CYGWIN_NT-5.1 OMarchuk 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 Cygwin -- King Oleg -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please test latest developer snapshot
I fixed error with downgrade cygwin package from 1.7.8-1 to 1.7.7-1 On Thu, Mar 3, 2011 at 2:22 PM, Oleg Marchuk kingo...@gmail.com wrote: I have got error similar to one described in http://www.mail-archive.com/cygwin at cygwin.com/msg114840.html Cygwin works fine until I install screens, try using git in screens, get error related to git repository name in prompt and then uninstall screens. In screens: sh: __git_ps1: command not found omarchuk@OMarchuk /cygdrive/c/git/gpag $rm /cygdrive/c/git/gpag/.git/index.lock rm: cannot remove `/cygdrive/c/git/gpag/.git/index.lock': No such file or directory sh: __git_ps1: command not found Then: omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java 6 [main] git 12192 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487 Stack trace: Frame Function Args 00229AF4 6102792B (00229AF4, , , ) 00229DE4 6102792B (6117DC60, 8000, , 6117F977) 0022AE14 61004F3B (6117F101, 0022AE40, 6C2E6D6F, 666F7875) 0022B074 6100176E (610EECC1, 0022B0A0, 70697263, 690A3B74) 0022B0B8 6115DE2C (6123D0E0, 666F7875, 64652E74, 672E736D) 0022B0E8 610EF04E (0022B130, , 726F706D, 6F632074) 0022B148 610C2C45 (0053A820, , 0124, 0010) 0022B168 00467C20 (0053A820, 0124, 0010, 00482D3E) 0022B198 00482F4A (0022C2D4, 746E656D, 6E616542, 74786520) 0022C298 0048315B (7FF8, 00022468, , 006E0910) 0022C2F8 00485A04 (7FF8, 00022468, 004FF6E4, 006CE684) 0022C338 00485A84 (0001, 0003, 00605908, 0002) 0022C378 00485CBA (006CE684, 0005, 0022C458, 0001) 0022C3B8 00485E3A (006CE684, 00605908, 0022C458, 0001) 0022C438 0046DD75 (00550E00, 00605908, 0022C458, ) 0022C4C8 004179C9 (00510B90, 0001, , ) End of stack trace (more stack frames may be present) Hangup omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java fatal: Unable to create '/cygdrive/c/git/gpag/.git/index.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$rm /cygdrive/c/git/gpag/.git/index.lock omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$uname -a CYGWIN_NT-5.1 OMarchuk 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 Cygwin -- King Oleg -- King Oleg http://kingoleg.livejournal.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin speed
I had come across with the following problem: after upgrading Cygwin from
version 1.5.19-4 to 1.5.24-2 my application (relational database)
began to function several times slower. The reason was a slowdown of
a function, which performs rebalancing of table index tree; this function
calls write() function very many times, at each call 4 bytes are updated
in index file (row number in tree node). To test performance of write()
function I created the following test program:
#include fcntl.h
#include unistd.h
int main(int argc, char **argv)
{
char chunk[64]=;
int i, fd;
if ((fd=open(tst_chunks.bin,
O_CREAT|O_WRONLY|O_TRUNC,
0666))0) return 1;
for (i=0; i100; i++)
if (write(fd,chunk,sizeof(chunk))!=sizeof(chunk)) return 1;
close(fd);
return 0;
}
When launched on Celeron 1.3MHz via time -p, it works:
on 1.5.24-2 : 48 seconds;
on 1.5.19-4 : 18 seconds.
After investigating differences between 1.5.24-2 and 1.5.19-4 I have found
out, that the problem is in function sig_dispatch_pending(), which is
called in the beginning of writev() function, which is called from write().
In function sig_dispatch_pending() the following has been changed:
void __stdcall
sig_dispatch_pending (bool fast)
{
if (exit_state || _my_tls == _sig_tls || !sigq.start.next) //
version 1.5.19-4
// if (exit_state || _my_tls == _sig_tls) //
version 1.5.24-2
{
//...
return;
}
//...
sig_send (myself, fast ? __SIGFLUSHFAST : __SIGFLUSH);
}
When make this modification in sources for 1.5.24-2 and rebuild cygwin1.dll,
my test program begins to work as fast as on 1.5.19-4. In message
http://cygwin.com/ml/cygwin-developers/2006-07/msg00034.html
Brian Ford pointed to the following description of a change between
1.5.19-4 and 1.5.24-2:
2006-02-24 Christopher Faylor cgf at timesys dot com
* sigproc.cc (sigheld): Define new variable.
- (sig_dispatch_pending): Don't check sigq since that's racy.
(sig_send): Set sigheld flag if __SIGHOLD is specified, reset it if
__SIGNOHOLD is specified. Ignore flush signals if we're holding
signals.
I think, that maybe checking of sigq is a little bit racy, but it turns,
that getting rid of such a cheap check results in a great slowdown of
sig_dispatch_pending() function for most calls, when there are no pending
signals.
Maybe introducing a critical section or some other synchronization
mechanism would be a solution.
Oleg Volkov
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
WSADuplicateSocket error
Hi, On my PC, any cygwin app which has a socket open (inetd, cddbd, whatever) seems to be unable to fork. I've included a strace excerpt below. As I see from strace, WSADuplicateSocket fails with error 10024 (too many open sockets). Could someone help me with this? I understand that quite probably it's caused by some third party software hooked into winsock, but I couldn't find the cause. I tried clearing out the LSP chains and uninstalling all applications which could be linked to this (firewall and VPN client), this did not help. Running on XP SP2, cygwin 1.5.12. Regards, Oleg Semenov Strace excerpt comes here: 33 10100382 [main] cddbd 3148 fork: entering 25 10100407 [main] cddbd 3148 sig_send: sendsig 0x700, pid 3148, signal -40, its_me 1 27 10100434 [main] cddbd 3148 sig_send: wakeup 0x66C 32 10100466 [main] cddbd 3148 sig_send: Waiting for pack.wakeup 0x66C 29 10100495 [sig] cddbd 3148 wait_sig: signalled 0x66C 33 10100528 [main] cddbd 3148 sig_send: returning 0x0 from sending signal -40 25 10100553 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 22 10100575 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 22 10100597 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 21 10100618 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 21 10100639 [main] cddbd 3148 __cygwin_lock_unlock: threadcount 1. not unlocking 27 10100666 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 21 10100687 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 21 10100708 [main] cddbd 3148 __cygwin_lock_unlock: threadcount 1. not unlocking 22 10100730 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 21 10100751 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 21 10100772 [main] cddbd 3148 __cygwin_lock_unlock: threadcount 1. not unlocking 22 10100794 [main] cddbd 3148 __cygwin_lock_unlock: threadcount 1. not unlocking 60 10100854 [main] cddbd 3148 subproc_init: started wait_subproc thread 54 10100908 [main] cddbd 3148 __cygwin_lock_lock: threadcount 1. not locking 24 10100932 [main] cddbd 3148 __cygwin_lock_unlock: threadcount 1. not unlocking 34 10100966 [main] cddbd 3148 stack_base: bottom 0x23, top 0x3, stack 0x22E410, size 7152, reserve 2097152 27 10100993 [main] cddbd 3148 fork_parent: CreateProcess (C:\cygwin\usr\local\bin\cddbd.exe, C:\cygwin\usr\local\bin\cddbd.exe, 0, 0, 1, 24, 0, 0, 0x22E4B0, 0x22E500) 2786 10103779 [proc] cddbd 3148 wait_subproc: starting 3069 10106848 [main] cddbd 3148 dtable::fixup_before_fork: fd 0 (/dev/console) 57 10106905 [main] cddbd 3148 dtable::fixup_before_fork: fd 1 (/usr/local/bin/f) 23 10106928 [main] cddbd 3148 dtable::fixup_before_fork: fd 2 (/usr/local/bin/f2) 22 10106950 [main] cddbd 3148 dtable::fixup_before_fork: fd 3 () 169 10107119 [main] cddbd 3148 fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 0x6AC, win_proc_id 512, prot_info_ptr 0x6179165C 32 10107151 [main] cddbd 3148 __set_winsock_errno: fixup_before_fork_exec:269 - winsock error 10024 - errno 1 25 10107176 [main] cddbd 3148 dtable::fixup_before_fork: fd 4 () 29 10107205 [main] cddbd 3148 fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 0x67C, win_proc_id 512, prot_info_ptr 0x61791A6C 24 10107229 [main] cddbd 3148 __set_winsock_errno: fixup_before_fork_exec:269 - winsock error 10024 - errno 1 135 10107364 [main] cddbd 3148 proc_subproc: args: 1, 2286752 32 10107396 [main] cddbd 3148 proc_subproc: Couldn't duplicate my handle0x7DC for pid 512, Win32 error 5 485 10107881 [main] cddbd 3148 proc_subproc: added pid 512 to wait list, slot 0, winpid 0x200, handle 0x64C 26 10107907 [main] cddbd 3148 proc_subproc: returning 1 24 10107931 [main] cddbd 3148 sync_with_child: waiting for child. reason: waiting for longjmp, hang_child 1 89 10108020 [proc] cddbd 3148 wait_subproc: looping 54 10108074 [proc] cddbd 3148 proc_subproc: args: 2, 0 79 10108153 [proc] cddbd 3148 proc_subproc: pid 512[0] terminated, handle 0x64C, nchildren 1, nzombies 0 27 10108180 [proc] cddbd 3148 proc_subproc: zombifying [0], pid 512, handle 0x64C, nchildren 1 23 10108203 [proc] cddbd 3148 proc_subproc: returning 1 23 10108226 [proc] cddbd 3148 sig_send: sendsig 0x700, pid 3148, signal 20, its_me 1 31 10108257 [proc] cddbd 3148 sig_send: Not waiting for sigcomplete. its_me 1 signal 20 24 10108281 [proc] cddbd 3148 sig_send: returning 0x0 from sending signal 20 22 10108303 [proc] cddbd 3148 wait_subproc: looping -327 10107976 [main] cddbd 3148 sync_with_child: child 512(0x64C) died before initialization with status code 0xC005 516 10108492 [main] cddbd 3148 sync_with_child: *** child state waiting for longjmp 365 10108857 [main] cddbd 3148 sync_with_child: Child died before
using xfree86 4.4.0 from remote host
What is the difference between XFree86 4.4.0 binaries for cygwin and the cygwin X packages? Is there any info on why XFree86 is removed from cygwin? Do the cygwin packages support font server usage? I want to use font packages and font server running on the linux box which lacks the video card. I am currently trying to use XFree86/cygwin 4.4.0. Maybe I would have been more successful with cygwin stuff? The problem is that I can't use the X server from the remote host. I have tried xhost +remoteIP and xhost + on the windows machine running xfree86. Both succeeded, but the remote says the same thing as before - Xlib: connection to 10.0.5.1:0.0 refused by server Xlib: No protocol specified Error: Can't open display: 10.0.5.1:0.0 zsh: exit 1 xsysinfo Log file does not says anything useful. I am running X by just starting XWin.exe, having /etc/X11/XF86Config with following contents: Section Files FontPath tcp/10.0.5.5:7100 EndSection Section Device Identifier a Driver cygwin EndSection Section Screen Identifier 0 Device a EndSection What am I doing wrong?
Re: reentrant functions
Wouldn't you just want to export all _*_r symbols listed in the Reentrancy section of info libc, which are: _Equivalent for errno variable:_ _errno_r _Locale functions:_ _localeconv_r _setlocale_r _Equivalents for stdio variables:_ _stdin_r_stdout_r _stderr_r _Stdio functions:_ _fdopen_r _perror_r _tempnam_r _fopen_r_putchar_r _tmpnam_r _getchar_r _puts_r _tmpfile_r _gets_r _remove_r _vfprintf_r _iprintf_r _rename_r _vsnprintf_r _mkstemp_r _snprintf_r _vsprintf_r _mktemp_t _sprintf_r _Signal functions:_ _init_signal_r _signal_r _kill_r __sigtramp_r _raise_r _Stdlib functions:_ _calloc_r _mblen_r_setenv_r _dtoa_r _mbstowcs_r _srand_r _free_r _mbtowc_r _strtod_r _getenv_r _memalign_r _strtol_r _mallinfo_r _mstats_r _strtoul_r _malloc_r _putenv_r _system_r _malloc_r _rand_r _wcstombs_r _malloc_stats_r _realloc_r _wctomb_r _String functions:_ _strdup_r _strtok_r _System functions:_ _close_r_link_r _unlink_r _execve_r _lseek_r_wait_r _fcntl_r_open_r _write_r _fork_r _read_r _fstat_r_sbrk_r _gettimeofday_r _stat_r _getpid_r _times_r _Additional 64-bit I/O System functions:_ _fstat64_r _lseek64_r _open64_r _Time function:_ _asctime_r Someone's already came up with this list, and even included it in the documentation, right? Oleg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
reentrant functions
I have a question about writing a multi-threaded program (using POSIX.1 threads) in Cygwin. info libc has a nice chapter about reentrancy, which talks about _func_r reentrant variants for functions that are not thread-safe. But when as an example I try using _gets_r(), I'm getting a link error that this function does not exist: ~ $ gcc -g threadtest.c /cygdrive/c/.../cc3s8dTu.o(.text+0xb4): In function `main': threadtest.c:26: undefined reference to `__gets_r' collect2: ld returned 1 exit status ~ $ I can't find it anywhere in the libraries. The prototype is in stdio.h, so the compile step works. What do I need to do to make it work? I've just updated to the latest Cygwin (1.5.9) and gcc (3.3.1), with no change (running under Windows 2000 and Windows XP). Here are a couple of other notes that I had while working on this: - info libc mentions the use of struct _reent, and that it needs to be initialized for each process (shouldn't it be thread here? As well as in a few other places). Unfortunately it neglects to say how to initialize it. I found _REENT_INIT and _REENT_INIT_PTR macros in sys/reent.h. It seems that the first one needs to be used as struct _reent thread_one = _REENT_INIT(thread_one); - I don't understand this part, as a possible way of achieving reentrancy (also from info libc): 2. Ensure that each thread of execution control has a pointer to its own unique reentrancy structure in the global variable `_impure_ptr', and call the standard library subroutines. How is it possible for two threads sharing global variables have the same global variable point to different structures? (reentrancy is only an issue when address space is shared, right? so it isn't possible to have separate _impure_ptr's, as I understand. What am I understanding wrong?) - Is it ok to use the regular functions, that use the global reentrancy structure, in one thread (or at least until multiple threads are created), and _func_r ones in the other ones? - In stdio.h there is a typo where the comment says Recursive versions of the above. I believe it should say Reentrant, not Recursive. Thank you! Oleg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
fatal error
Dear support team, Cygwin is installed on the new machine (Pentium III 533, 384Mb). It works perfect on the previous computer (Pentium 4 2400, 256Mb) but on this machine shows fatal error, when I start startxwin.bat with the line: XWin -query morpheus.tran.wau.nl (Linux Debian server) XWin.log file is attached. Please help to get it working right, thank you very much Oleg, Wageningen University, The Netherlands. XWin.log Description: Binary data
Broken link XFree86-base on ftp server
Hello cygwin. File ftp://cygwin.csie.ntu.edu.tw/pub/cygwin/release/XFree86/XFree86-base/XFree86-base-4.3.0-1.tar.bz2 is damaged. Can you put correct archive? thank you in advance. - Sign up for ICQmail at http://www.icq.com/icqmail/signup.html
RE: c++ ifstream problem with gcc 3.2
Hello Gerrit, I've faced the same problem after installation gcc 3.2. How I solved it in my program: ifstream cur_stream(file_name1, ios::in); .. cur_stream.close(); cur_stream.clear(); cur_stream.open(file_name2, ios::in); Hope, it'll help you. Best regards, Zhabitsky Oleg Hello, I recently encountered the problem with the gcc 3.2 compiler of cygwin using ifstream. Basically it is the same problem as mentioned in http://gcc.gnu.org/ml/gcc-help/2002-06/msg00079.html although this is about gnu cc 3.0. I thought that this was already fixed. The problem is that when a ifstream object is closed and than reopened with the open method to open another file, no data is returned. But if one uses 2 ifstream objects, everything works perfectly. Is this a known issue with c++ on cygwin ? Gerrit. -- 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/
cyrillic console
Currently, the character set in cyrillic console seems to be cp1251, while in cmd.exe it is cp866. Nothing too wrong with this, except that cp1251 lacks pseudographic symbols. I am using cygwin to run tin 1.4 with codepage translation table from koi8-r to cp1251. So the pseudographics does not survive this translation. If the codepage is altered from cp866 to cp1251, is that correct that it is easy to convert instead to koi8-r? Why not make this customizable? I've tried to build some release of cygwin dll but didn't succeed yet... well I'll keep trying if it worth it. Perhaps I need to update all utilities to newest versions? -- Oleg Leschov mailto:[EMAIL PROTECTED] FidoNET 2:5050/59.8 -- 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/
RE: ftell() bug
If you see to MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html /_crt_ftell.asp), you can find out: == Note that when a file is opened for appending data, the current file position is determined by the last I/O operation, not by where the next write would occur. For example, if a file is opened for an append and the last operation was a read, the file position is the point where the next read operation would start, not where the next write would start. (When a file is opened for appending, the file position is moved to end of file before any write operation.) If no I/O operation has yet occurred on a file opened for appending, the file position is the beginning of the file. == So, it is normal behaviour in your case. Kind regards, Zhabitsky Oleg -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 28, 2002 5:35 AM To: [EMAIL PROTECTED] Subject: Re: ftell() bug On Fri, Nov 22, 2002 at 10:53:56AM +0500, Serge P. Voronin wrote: I'm find a bug in ftell() while compiling with -mno-cygwin flag (see attachment). If we compile program without -mno-cygwin flag, then no bug present. Try compiling the program on linux or unix and see what you get. You'll see that cygwin output from your program agrees with linux or unix. IMO, the windows runtime that Mingw (-mno-cygwin) uses is wrong. However, it doesn't really matter. Cygwin adheres to UNIX conventions. Btw, in the future it would be better to 1) include your test case as text. There is no reason to encode a text file. 2) describe your problem rather than asking others to infer it. cgf -- Please do not send me personal email with cygwin questions or observations. Use the resources at http://cygwin.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/ -- 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/
Debian on Cygwin
Hi I remember reading that dpkg (of Debian/Linux) has been ported to Cygwin. For those who don't know, on Debian/Linux, all you need to do to install a package and automatically install the necessary dependencies is run `apt-get install $PACKAGE_NAME`, and to keep the system current with patches and upgrades, one simply does `apt-get update apt-get upgrade` once in a while. Is Debian packaging system [going to be] availabe as an alternative or an addition to Setup.exe? Thanks Oleg -- 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/
Re: terminal is not fully functional ***Rootdir problems***
- Original Message - From: Robert Mark Bram [EMAIL PROTECTED] To: Andrew Markebo [EMAIL PROTECTED]; Cygwin [EMAIL PROTECTED] Sent: Monday, March 18, 2002 4:26 AM Subject: RE: terminal is not fully functional ***Rootdir problems*** Howdy and thanks for the response! I have changed ROOTDIR so it is now C:\cygwin but I am still getting these problems: When I run Cygwin it is putting me in a home directory of /cygdrive/c (not my user directory) and some of my commands are not working. For example: Robert Mark Bram@DIJONG ~ $ pwd /cygdrive/c Robert Mark Bram@DIJONG ~ $ man ls | less WARNING: terminal is not fully functional - (press RETURN) Any other ideas please!!?? Rob :) I'm a Cygwin newbie, although a long time UNIX/Linux user, but here's an idea: check that you have ncurses cygcheck --check-setup | grep ncurses and maybe try reinstalling them libncurses5 5.2-1 libncurses6 5.2-8 ncurses 5.2-8 You could also check that `env | grep -i term` output makes sense to you HTH Oleg -- 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/
cygwin start-up options
Hi I'm curious, how does everyone start cygwin? I use a shortcut C:\cygwin\bin\rxvt.exe -sl 200 -fg white -bg black -geometry 110x43+0+0 -backspacekey ^H -fn 8x16 -e /bin/bash --login -i, starting in C:\cygwin\bin (the geometry matches my screen resolution) Is there a smarter/faster way to start cygwin? Thanks -- 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/
Re: termcap problem in RXVT?
I get the same rxvt behavior, so I start it with `rxvt -e /bin/bash` Oleg - Original Message - From: Randall R Schulz [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 18, 2002 6:34 PM Subject: Re: termcap problem in RXVT? Jon, For whatever reason, you've managed to invoke /bin/sh (ash) instead of BASH in the RXVT emulator context. Ash doesn't interpret the escape sequences in the PS1 variable set up by /etc/profile to make the prompt conform to someone's idea of utility and aesthetic merit. I don't know why on this machine you're getting a different shell than on the others, but I'd investigate spurious or extraneous settings of the SHELL environment variable, possibly originating at the Windows system level. Randall Schulz Mountain View, CA USA At 15:20 2002-03-18, BERNDT, JON wrote: I have installed CygWin on numerous machines using teh nice setup program at cygwin.com. Recently, however, I have installed CygWin on two machines (one a W2K machine and the other a Win98SE machine) and when I tried to run rxvt I got strange behavior for the prompt. If I bring up a bash shell immediately after installing, then type rxvt at the bash prompt, this is what shows up in the rxvt console: --- start --- \[\033]0;\w\007 \033[32m\]\u@\h \[\033[33m\w\033[0m\] $ --- end --- I am at a loss to explain what to do. This has not happened to me in prior cygwin installs. I checked the FAQ and the mailing list archives for March, but could not find any reference to anything new that should have caused this. Jon -- 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/ -- 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/
Re: Start up script
- Original Message -
From: Robert Mark Bram [EMAIL PROTECTED]
To: Andrew Markebo [EMAIL PROTECTED]
Cc: Cygwin [EMAIL PROTECTED]
Sent: Monday, March 18, 2002 8:21 PM
Subject: RE: Start up script
Howdy all!
Read the documentation.. made my .bashrc script!
Here it is so far:
function ll
{
ls -l
}
alias ls='/bin/ls --color -F'
alias l='ls'
alias ll='ls -l'
alias la='ls -A'
alias d='cd'
alias p='cd -'
alias s='cd ..'
alias g='grep'
alias G='grep -i'
alias me='ps -u `whoami`'
alias h='history'
alias c='clear'
alias x='exit'
alias e='vim'
are the ones I use often. No need for function BTW
Oh, and don't forget the all-time most important piece of .bashrc setup
when you are logged in as someone else: Run
echo echo sleep 1 .bashrc .bashrc
#(damn this system gets slower every time I log in :)
HTH
Oleg
function m
{
man $1 | less
}
Any one have any other nice tricks they use in theirs?
Rob
--
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/
Re: Start up script
I meant that there was no need for function in both of the examples given
by the previous poster. Yes, of course function has more functionality
than alias, but here, it's an overkill.
Consider
alias l='ls'
vs
function l() { /bin/ls $@; }
HTH
Oleg
- Original Message -
From: Randall R Schulz [EMAIL PROTECTED]
To: Oleg [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, March 18, 2002 9:28 PM
Subject: Re: Start up script
Oleg,
At 18:06 2002-03-18, Oleg wrote:
- Original Message -
...
are the ones I use often. No need for function BTW
You'll need functions when it's not sufficient to have the parameters to a
command simply tacked onto the end of the alias expansion.
If I recall, this is one place where BASH is not capable something CSH can
do: namely support the full syntax of !-expansions within an alias.
Oh,and don't forget the all-time most important piece of .bashrc setup
when you are logged in as someone else: Run
echo echo sleep 1 .bashrc .bashrc
#(damn this system gets slower every time I log in :)
HTH
Oleg
Randall Schulz
Mountain View, CA USA
--
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/
--
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/
copying and pasting in rxvt
Hi How can I get copying and pasting to work in rxvt like it does under X? I want to be able to slect text with the left button and paste it with the middle button (emulated actually: I just press both left and right buttons at the same time). I used to have it work on my other computer (laptop). The setup seems to be identical, but it doesn't work now. Thanks -- 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/
