Perl module Net::SMTP->auth() error with Authen::SASL::XS
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: 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
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
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: 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
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: 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 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: 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: 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 #include 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; i<100; 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 * 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 handle<0x7DC> 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 sy
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 __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 __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/
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/
xargs
Can't find xargs. Help! Is it anywhere in Cygwin? BTW, how does one go about figuring out which package contains a given program or file? 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/
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: 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/
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: 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/
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: 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/
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/