pthread_mutex_init + gdb issue again
Alright, I'm aware of the "check for invalid memory region and throw
exception" issue present when debugging pthread applications under gdb
and that the actual segfault is innocuous. However, the following solutions:
1. "handle SIGSEGV nostop"
"handle SIGTRAP nostop"
2. (hit continue on every SIGSEGV raised).
Are unacceptable to me. I have functions which initialize mutexes for
1000s of objects at load time. e.g. parse, alloc struct, init mutex within
struct. For one, it becomes fruitless to try and debug a real segfault issue
when using gdb and pthreads under cygwin. The only option when working
with mass mutexes is disable stopping on SIGSEGV within gdb - rendering
useless the debugging of an actual real segfault situation.
This is the best I could come up with to get around it, and frankly it's a
ridiculous hack, that's entirely non-portable, possibly even with future
versions of cygwin libraries - but it's necessary to keep my sanity when
debugging pthreads based apps under cygwin:
#ifdef __CYGWIN__
# define PT_m_init(x, y) \
{ \
*x = malloc(sizeof(struct __pthread_mutex_t)); \
(**x).__dummy = 56; \
}
#else
# define PT_m_init(x, y) \
pthread_mutex_init((x), (y))
#endif
Someone throw me a bone here, please.
-cl
--
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: pthread_mutex_init + gdb issue again
On Mon, May 08, 2006 at 02:01:00AM -0700, Brian Dessent wrote: > > Rather than work-arounds, why not just use a recent build of gdb that > doesn't suffer from this problem? The issue was fixed in CVS earlier > this year. But do note that it requires functionality not present in > Cygwin 1.5.19, so you'll also need to use a recent Cygwin snapshot. Thanks. I'll look into it. My workaround isn't a proper workaround after all anyways. -cl -- 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: pthread_mutex_init + gdb issue again
On Mon, May 08, 2006 at 02:44:37AM -0700, [EMAIL PROTECTED] wrote: > > On Mon, May 08, 2006 at 02:01:00AM -0700, Brian Dessent wrote: > > > > Rather than work-arounds, why not just use a recent build of gdb that > > doesn't suffer from this problem? The issue was fixed in CVS earlier > > this year. But do note that it requires functionality not present in > > Cygwin 1.5.19, so you'll also need to use a recent Cygwin snapshot. > > Thanks. I'll look into it. My workaround isn't a proper workaround > after all anyways. > > -cl Thanks Brian, much better. The issue was that I could not find any reference to the problem ever being fixed - just a lot of threads where people were ending with "yea you gotta hit continue - it sucks." Everything is cool now with gdb 6.4 and the 4-27 snapshot. We'll see how stable it is. NX is working fine with it, however. -cl -- 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: pthread_mutex_init + gdb issue again
One thing about this 4-27 snap, and I noticed it with 4-03 as well (which I reverted from a while ago) is that disk i/o appears to be ridiculously slow in comparison to 1.5.19. In rough estimation, I'd have to say a 50% reduction in I/O throughput. I notice it while working with mass updating of files and builds. Is there any form of profiling, etc. enabled in the snap builds? As even if there were zero optimization, it wouldn't be this noticably slow. -cl On Mon, May 08, 2006 at 03:46:04AM -0700, Brian Dessent wrote: > > I expect that after 1.5.20 is out the door an updated gdb binary package > will happen, and hopefully at that point it will be a lot easier to say > "use the new version, see the release announcement" compared to "build > it yourself from CVS". > > Brian -- 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: Cygwin 1.5.19-4 issues
I suggest doing a google search on the following terms: "cygwin temporarily unavailable desktop heap" Or here's a pointer to one: http://www.cygwin.com/ml/cygwin/2002-02/msg01068.html On Mon, May 08, 2006 at 06:00:52PM -0700, Virgil Adumitroaie wrote: > fork: Resource temporarily unavailable" which I get during compilation, > indicates some other trouble. > Please let me know if you think otherwise, or if you don't get the same > behavior. > What changes made between 1.5.19-4 and 1.5.18-1 could produce these > problems? -- 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/
readv() questions
Warning - LONG and network code related - do not read if not interested
or not versed.
I'm trying to currently debug an issue where readv() seems to be filling
iovec's with bad data or otherwise overflowing when having to deal with a
large receive buffer. I say large receive buffer because I can replicate the
issue by writev()ing 1000+ iovec's on the sending side and readv()ing on
the cygwin side continously. I have multiply verified the sending side is
writev()ing the correct iovecs, with length intact and as I specified it -
however upon readv()ing the same back on the cygwin end, after a sporadic
number of data has been transfered (usually around 100 iovecs or so),
I get a spurious iovec filled with data I did not originally send out.
[ sending-side (Linux 2.6.9-22.0.1.EL) ]
--> writev() + write(variable length, sent in preceeded iovec)
--> 100mb uplink
--> 384/1500 dsl up/downlink
--> readv() + read(length derived from iovec received)
[ receiving-side (Cygwin 1.5.20s(0.155/4/2) 20060427) ]
The iovec itself is small, 13 bytes:
1 byte (total length)
1 byte (variable length)
1 byte (flag)
2 byte (header data)
4 byte (header data)
4 byte (header data)
On the sending side I writev() to the network stack, and then immediately
issue another write() afterwards containing the variable length data,
which I stored in the header (iovec[1]). On the receiving end, same deal,
just reverse. readv(), passing a char * to iovec[1], and relying on readv()
to fill it with the correct data received - which I then use as a length
to read() to get the variable length data following.
A few things:
1. Sanity test, nobody sees anything wrong with this fairly standard
procedure, correct?
2. What exactly is the purpose of dummytest() within
/winsup/cygwin/miscfuncs.cc?
The call to check_iovec_for_read from within readv():
440 extern "C" ssize_t
441 readv (int fd, const struct iovec *const iov, const int iovcnt)
442 {
443 extern int sigcatchers;
444 const int e = get_errno ();
445
446 int res = -1;
447
448 const ssize_t tot = check_iovec_for_read (iov, iovcnt);
check_iovec_for_read is a macro defined as:
winsup.h:#define check_iovec_for_read(a, b) check_iovec ((a), (b), false)
The actual check_iovec() call with preceeding dummytest():
162 static char __attribute__ ((noinline))
163 dummytest (volatile char *p)
164 {
165 return *p;
166 }
167 ssize_t
168 check_iovec (const struct iovec *iov, int iovcnt, bool forwrite)
169 {
170 if (iovcnt <= 0 || iovcnt > IOV_MAX)
171 {
172 set_errno (EINVAL);
173 return -1;
174 }
175
176 myfault efault;
177 if (efault.faulted (EFAULT))
178 return -1;
179
180 size_t tot = 0;
181
182 while (iovcnt != 0)
183 {
184 if (iov->iov_len > SSIZE_MAX || (tot += iov->iov_len) > SSIZE_MAX)
185 {
186 set_errno (EINVAL);
187 return -1;
188 }
189
190 volatile char *p = ((char *) iov->iov_base) + iov->iov_len - 1;
191 if (!iov->iov_len)
192 /* nothing to do */;
193 else if (!forwrite)
194 *p = dummytest (p);
195 else
196 dummytest (p);
197
198 iov++;
199 iovcnt--;
200 }
201
202 assert (tot <= SSIZE_MAX);
203
204 return (ssize_t) tot;
205 }
Lines 190 to 196 seem completely pointless to me unless I'm missing
something, which I believe to be the case here. Can someone explain it? Due
to the use of volatile and the explicit noinline attribute, I have a
feeling it's some form of memory assertion - but why?
Anyways, the cases where the situation *does not* happen are if I run it
under strace (which smells of a race) or if I throttle the data manually
by only sending a set amount and then requesting ack from the receiving
side (which I use the flags var for). If I go full unthrottled, no acks,
standard write it all to wire, read it all from wire - the s* hits the fan.
What I believe is causing the issue is an MTU related problem. It almost
always seems to get into weirdness right around 1452 bytes transfered. I
have verified, via Ethereal, that my assertions fail (which are checking
the variable length stored in the header I sent == what is stored in the
received iovec) when readv() reads data at the border of a TCP packet in
the stream (i.e. the next portion of an iovec or the next iovec entirely is
in the next packet). Ethereal also verifies that the data sent is exactly
as I had placed it on the sending stack via writev() from sending host.
Ethereal also verifies that the problems occur as iovec data or iovecs
within the array passed to readv() span TCP packets.
I'm slowly going through the code, which can be a mission, but I'm beginning
to wonder if this section:
219 void
220 fhandler_base::raw_read (void *ptr, size_t& ulen)
Re: /usr/bin/install: accessing `//filesrv/chj//.bashrc': Permission denied
Don't try to get shares working like that through sshd. You'll be missing hair afterwards. Specify the share as a mount point with mount. And then add your .bashrc: if ! ls /mount_point/. 2>&1 >/dev/null; then /c/WINDOWS/system32/net USE /USER:username '\\share' password fi Yep, about as secure as you can chmod it, but that's life with windows. -cl On Tue, May 09, 2006 at 10:02:03AM +0200, Lloeki wrote: > > > >so I guess this is really about shares... > > > > It's not really about shares, it's more about the user sshd runs > under, and which happens to be sent to the share auth system. > > Lloeki -- 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: readv() questions
On Tue, May 09, 2006 at 07:00:57AM -0700, Mark Pizzolato wrote:
> > 67
> > 68 for (error = 0; !error; ) {
> > 69 error = 1;
> > 70
> > 71 if ((hl = n_recv_iov(s, packet, NE(packet), 60))
> >== (size_t)-1)
> > 72 break;
> > 73
> > 74 assert(byte_vl < sizeof(byte_var));
> > 75
> > 76 if ((vl = n_recv(s, byte_var, byte_vl, 60)) ==
> >(size_t)-1)
> > 77 break;
> > 78 if (hl == 0 || vl == 0)
> > 79 break;
> > 80
> > 81 error = 0;
> > 82
> > 83 /* process_data(); */
> > 84 }
> >
> >Sorry for the ultra mail, but I know for a fact that readv() on cygwin is
> >doing bad things when faced with a lot of data to read from the wire. Any
> >insights?
>
> Well, to me this looks like a variation on the classic error made when
> coding applications which use tcp. Specifically that there is a 1<->1
> crrespondence between sends( write, writev, etc) on the sending side to
> rcvs(read, readv, etc) on the recieving side. TCP makes no such guarantee.
> It only guarantees tha the bytes put in on the sending side of the
> connection will come out in the same order on the recieving side. No
> guarantee about the size of the respective reads of the data delivered. If
> you are expecting to receive a certain size data element, the burden is
> yours to actually make sure you get as much data as you expect, and to
> continue reading until you are happy.
>
> Your code does not seem to do anything to validate that the length of the
> data returned by readv is indeed what you expected.
>
> - Mark Pizzolato
Understood, there are actually other assertions that I had not layed out in
the email - the code I use has a lot of other trivial checks just for this
type of situation. However, what exactly is one supposed to do when readv()
returns a short count within a stream of data? One is totally screwed and
must request retransmission entirely or wrap it all with a minimal protocol
that can handle a rerequest with an offset for x number of other items -
nevermind the fact that one just dumped a bit on wire that is actually
valid data but is no longer usable without heavy reassembly. You cannot
even use the idiom of "well let me just get the rest of this here and I'll
make a request for the dropped data after." If that's the cake to eat,
then I'll just rewrite my readv wrapper to deal with it I guess. Not like
that is trivial if data is disrupted mid-vector. :-|
>From a Solaris manpage (not Cygwin, but a likewise reasonable POSIX
implementation):
--
Each iovec entry specifies the base address and length of an area in
memory where data should be placed. The readv() function always
fills an area completely before proceeding to the next.
RETURN VALUES
Upon successful completion, read() and readv() return a
non-negative integer indicating the number of bytes actually
read. Otherwise, the functions return -1 and set errno to indicate
the error.
--
Technically this doesn't specify it will always return what's requested
(just like read() wouldn't in NB mode) so I guess onus is still on me. I'll
try to work out a simple test case after re-examining other options for
dealing with it in my readv() underlying call.
-cl
--
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: readv() questions
On Tue, May 09, 2006 at 03:54:16PM +0100, Dave Korn wrote:
> > You cannot
> > even use the idiom of "well let me just get the rest of this here and I'll
> > make a request for the dropped data after."
>
> Yes you absolutely can. Who said you can't? You're just not trying. It
> works fine.
Well 85% of it was honestly whining in retrospect.
> > If that's the cake to eat,
> > then I'll just rewrite my readv wrapper to deal with it I guess. Not like
> > that is trivial if data is disrupted mid-vector. :-|
>
> Yes, it so is trivial. It's barely the tiniest bit more complex than
> dealing with restarting a call to read().
>
> cheers,
> DaveK
Thanks for taking the time to go through the original mail Dave - I
appreciate it.
After refactoring (just kidding, I don't really subscrib to that word)^H^H
modifying my original n_recv_iov() code to deal with the edge-of-MSS
and other partial readv() occurences I'm not having a problem anymore -
unsurprisingly.
I actually just call my n_recv() (standard non-blocking linear read)
to read remaining bytes of a partially filled vector because I'd rather not
muck with the contents of the original iovec passed in. I just pass it to
n_iov_offset() with the bytes read as a value-result argument which returns
number of iovecs filled + offset within a partially filled iovec in the v-r
arg.
So far so good, but if anyone sees anything glaring might as well point it
out - although this is not really CW related at this point.
-cl
New stuff:
400 size_t n_iov_offset(const struct iovec *v, const size_t c, size_t *os)
401 {
402 size_t l, cv;
403
404 for (cv = 0; cv < c; cv++) {
405 if ((l = v[cv].iov_len) > *os) break;
406 *os -= l;
407 }
408
409 return cv;
410 }
411
412 size_t n_iov_total(const struct iovec *v, const size_t c)
413 {
414 size_t cv, bt;
415
416 for (cv = bt = 0; cv < c; cv++)
417 bt += v[cv].iov_len;
418
419 return bt;
420 }
421
422 size_t n_recv_iov(const int s, const struct iovec *v, size_t c, int
tout)
423 {
424 size_t cv, br, bre, brt = 0;
425 int res;
426 struct timeval to;
427 fd_set fds, fds_m;
428
429 FD_ZERO(&fds_m);
430 FD_SET(s, &fds_m);
431
432 bre = n_iov_total(v, c);
433
434 while (brt < bre) {
435 fds = fds_m;
436 to.tv_sec = tout;
437 to.tv_usec = 0;
438
439 if ((br = readv(s, v, c)) == (size_t)-1) {
440 switch (errno) {
441 case EWOULDBLOCK:
442 case EINTR:
443 break;
444 default:
445 perror("readv");
446 return -1;
447 }
448 } else if (br) {
449 if ((brt += br) < bre) {
450 /* short read, mid-vector offset
returned in br */
451 cv = n_iov_offset(v, c, &br);
452 v += cv;
453 c -= cv;
454
455 if (br == 0)
456 continue;
457
458 /* call read if we're short mid-vector
*/
459 br = n_recv(s, (char *)v->iov_base + br,
460 v->iov_len - br, tout);
461 if (br == (size_t)-1)
462 return -1;
463
464 /* done with mid-vector fill, proceed
with rest */
465 brt += br;
466 v++;
467 c--;
468 }
469 } else {
470 break;
471 }
472
473 if ((res = select(s + 1, &fds, NULL, NULL, &to)) == 0)
474 return -1; /* timeout */
475 else if (res == -1) {
476 perror("select"); /* never happen */
477 return -1;
478 }
479 }
480
481 return brt;
482 }
--
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: Call for testing Cygwin snapshot
On Wed, May 10, 2006 at 01:38:58AM -0400, Christopher Faylor wrote: > Would you be willing to try building a cygwin DLL with Corinna's > > 2006-04-04 Corinna Vinschen <[EMAIL PROTECTED]> > > * net.cc (fdsock): Raise default SO_RCVBUF/SO_SNDBUF buffer sizes to > the same values as on Linux. > > change reverted and see if that changes things? > > That's the only thing in the 20060412 that I can see which would make a > difference. > > cgf BTW: What's the easiest way to switch cygwin versions without having to reboot? I quite commonly come across changing snapshot dll's and having bash throw errors (probably relocation related or something of the sort) and immediately return. After reboot it's fine. But what's a way to quickly switch versions without reboot required? Or am I doing something wrong? (just following the FAQ, shutting down all cyg execs and services, then shuffling files around) -cl -- 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: readv() questions
On Tue, May 09, 2006 at 10:11:35PM -0700, [EMAIL PROTECTED] wrote:
>
> So far so good, but if anyone sees anything glaring might as well point it
> out - although this is not really CW related at this point.
>
> -cl
Just to follow up on this.. I did take your advice fully Dave, and decided
to just modify the partial iovec in place and restore a copy of it after
handling the partial situation. Reason being that it's beneficial to set
an iovec array once and pass it to read or writev on every call (if one
is using relatively non changing locations assigned to each iov_base per
vector - if not, it still works anyways). So far so good, I setup a test
case and have transfered over 20,000,000 records via 6 iovecs each at
around ~20-70 bytes average record size. I've also verified that partials
are occuring, in addition to both mid-vector and mid-array. 200K/sec - so
I think we can rest assured race conditions are out of the picture. My
code was the culprit, cygwin's was not :).
In case anyone needs the code for any purpose (I know that I searched usenet
and web quite a bit looking for any references to short|trunc|partial, etc.
WRT readv()/writev() and found very little, so this may come in handy to
others.
-cl
/* header */
#ifndef __NIOV_H
#define __NIOV_H
#define n_recv_iov(a,b,c,d) \
n_iov_generic(a,b,c,d,N_IOV_RECV)
#define n_send_iov(a,b,c,d) \
n_iov_generic(a,b,c,d,N_IOV_SEND)
enum n_iov_type__ {
N_IOV_RECV,
N_IOV_SEND
};
typedef enum n_iov_type__ n_iov_type;
ssize_t n_iov_generic(const int, struct iovec *, ssize_t, const int,
n_iov_type);
ssize_t n_iov_offset(const struct iovec *, const ssize_t, ssize_t *);
ssize_t n_iov_total(const struct iovec *, const ssize_t);
#endif /* __NIOV_H */
/* module */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "niov.h"
#define _POSIX_SOURCE 1
ssize_t n_iov_offset(const struct iovec *v, const ssize_t c, ssize_t *os)
{
ssize_t l, cv;
/*
* compute filled iovec count and set any partial offset in "os".
* "os" should point to the number of bytes previously read when
* called.
*/
for (cv = 0; cv < c; cv++) {
if ((l = v[cv].iov_len) > *os) break;
*os -= l;
}
return cv;
}
ssize_t n_iov_total(const struct iovec *v, const ssize_t c)
{
ssize_t cv, bt;
for (cv = bt = 0; cv < c; cv++)
bt += v[cv].iov_len;
return bt;
}
ssize_t n_iov_generic(const int s, struct iovec *v, ssize_t c, const int t,
n_iov_type nt)
{
struct timeval to;
struct ioveciov_o = { NULL, 0 };
fd_set fds, fds_m, *rfds = NULL, *wfds = NULL;
ssize_t (*nf_iov)(int, const struct iovec *, ssize_t);
ssize_t cv, b, be, bt;
int res;
switch (nt) {
case N_IOV_RECV:
nf_iov = readv;
rfds = &fds;
break;
case N_IOV_SEND:
nf_iov = writev;
wfds = &fds;
break;
default: break;
}
FD_ZERO(&fds_m);
FD_SET(s, &fds_m);
for (bt = 0, be = n_iov_total(v, c); bt < be; ) {
fds = fds_m;
to.tv_sec = t;
to.tv_usec = 0;
b = nf_iov(s, v, c);
if (b == -1) {
switch (errno) {
case EWOULDBLOCK:
case EINTR:
break;
default:
perror(nt == N_IOV_RECV ? "readv" : "writev");
bt = -1;
break;
}
if (bt == -1) break;
} else if (b && (bt += b) < be) {
/*
* short count situation.
*
* if not within mid-vector, advance past filled, else
* temporarily modify original iovec to make up the
* difference and restore on exit.
*/
/* if previously saved, restore before modify */
if (iov_o.iov_base) {
memcpy(v, &iov_o, sizeof(*v));
iov_o.iov_base = NULL;
}
/*
* cv = filled vectors returned, advance past these.
* b = mid-vector offset in case of partial vector.
*/
cv = n_iov_offset(v, c, &b);
v += cv;
c -= cv;
Re: how come #include "*.cpp" works?
On Thu, May 11, 2006 at 09:09:33PM +0200, Klaas Thoelen wrote:
>
> This seems a little strange to me. Does anybody know what's wrong here?
>
> Thanks and regards,
> Klaas Thoelen
It's just a classic mistake, pretty easily fixed with the following:
> datum.h
> **
Add this:
#ifndef DATUM_H
#define DATUM_H
> class Date {
> public:
>Date();
>Date(int dd, int mm, int yy);
>int day();
>int month();
>int year();
>static void set_default(int, int, int);
>Date& add_year(int);
>Date& add_month(int);
>Date& add_day(int);
>Date& print();
> private:
>int d, m, y;
>static Date default_date;
>static bool is_leapyear(int);
>static int daysinmonth(int, int);
> };
#endif /* DATUM_H */
That ifndef construct is a one-way trap-door to prevent a doubly included file
from clobbering itself. Pretty standard.
>
> datum.cpp
>
> #include "datum.h"
Probably should place this after your standard includes below.
> #include
> #include
> using namespace std;
--
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/
a simple cygwin snapshot regression finding script i wrote in bash
I wrote this script to help people streamline testing snapshot issues when they identify an issue in a snapshot but do not necessarily know where the issue might have occured (for instance they do not iteratively keep up on snapshot releases). Based on the snapshots available at "http://www.cygwin.com/snapshots/"; the script performs a binary deduction (simple divide/conquer) to provide quick automation of switching snapshot dlls to narrow down a regression or new bug so that it is trivialized into cut/paste -> test -> next. This is mainly useful to people who *have an alternate unix shell* which they typically connect to through putty, nx, etc., i.e. any system out of band from cygwin. For instance, through my own dedicated host, I run the script and it provides me with the proper order of snapshots to test to narrow down between what two snapshot releases a difference in behavior has been seen. It requires you to simple input "a" for "absent, doesn't exist," or "s" for "seen" as in you're still seeing the issue. You can also add an explicit first argument to specify the snapshot you're currently using - which will split the tree differently. In addition you can also use a template file which will be sourced after each iteration which is where the cut/paste action will come in. Apologies to everyone in advance for the long text after this, I'm just trying to show an example so it makes sense what I'm talking about. Example: Let's say I'm troubleshooting a new bug, such as rsync randomly crashing, for instance, in the latest snapshot I've switched to. Now you could go through each snapshot in a linear fashion, but that's pointless when there are better ways. [EMAIL PROTECTED] ~]$ bash /tmp/csnap.sh - :: date: 20060223 ::dll: http://www.cygwin.com/snapshots/cygwin1-20060223.dll.bz2 :: debug: http://www.cygwin.com/snapshots/cygwin1-20060223.dbg.bz2 :: source: http://www.cygwin.com/snapshots/cygwin-src-20060223.tar.bz2 :: winsup: http://www.cygwin.com/snapshots/winsup-src-20060223.tar.bz2 ::install: http://www.cygwin.com/snapshots/cygwin-inst-20060223.tar.bz2 :: diffs: http://www.cygwin.com/snapshots/winsup-changelog-20060222-20060223 :: changelog: http://www.cygwin.com/snapshots/winsup-diffs-20060222-20060223 :: :: [(l)og,(d)iff,(a)bsent,(s)een] --> a I specify that the behavior is absent, after testing this snapshot with a test case which can duplicate the behavior. - :: date: 20060321 ::dll: http://www.cygwin.com/snapshots/cygwin1-20060321.dll.bz2 :: debug: http://www.cygwin.com/snapshots/cygwin1-20060321.dbg.bz2 :: source: http://www.cygwin.com/snapshots/cygwin-src-20060321.tar.bz2 :: winsup: http://www.cygwin.com/snapshots/winsup-src-20060321.tar.bz2 ::install: http://www.cygwin.com/snapshots/cygwin-inst-20060321.tar.bz2 :: diffs: http://www.cygwin.com/snapshots/winsup-changelog-20060320-20060321 :: changelog: http://www.cygwin.com/snapshots/winsup-diffs-20060320-20060321 :: :: [(l)og,(d)iff,(a)bsent,(s)een] --> a Same. - :: date: 20060413 ::dll: http://www.cygwin.com/snapshots/cygwin1-20060413.dll.bz2 :: debug: http://www.cygwin.com/snapshots/cygwin1-20060413.dbg.bz2 :: source: http://www.cygwin.com/snapshots/cygwin-src-20060413.tar.bz2 :: winsup: http://www.cygwin.com/snapshots/winsup-src-20060413.tar.bz2 ::install: http://www.cygwin.com/snapshots/cygwin-inst-20060413.tar.bz2 :: diffs: http://www.cygwin.com/snapshots/winsup-changelog-20060412-20060413 :: changelog: http://www.cygwin.com/snapshots/winsup-diffs-20060412-20060413 :: :: [(l)og,(d)iff,(a)bsent,(s)een] --> a Same. - :: date: 20060424 ::dll: http://www.cygwin.com/snapshots/cygwin1-20060424.dll.bz2 :: debug: http://www.cygwin.com/snapshots/cygwin1-20060424.dbg.bz2 :: source: http://www.cygwin.com/snapshots/cygwin-src-20060424.tar.bz2 :: winsup: http://www.cygwin.com/snapshots/winsup-src-20060424.tar.bz2 ::install: http://www.cygwin.com/snapshots/cygwin-inst-20060424.tar.bz2 :: diffs: http://www.cygwin.com/snapshots/winsup-changelog-20060421-20060424 :: changelog: http://www.cygwin.com/snapshots/winsup-diffs-20060421-20060424 :: :: [(l)og,(d)iff,(a)bsent,(s)een] --> s At this point I see the observed behavior so I specify "seen." - :: date: 20060418 ::dll: http://www.cygwin.com/snapshots/cygwin1-20060418.dll.bz2 :: debug: http://www.cygwin.com/snapshots/cygwin1-20060418.dbg.bz2 :: source: http://www.cygwin.com/snapshots/cygwin-src-20060418.tar.bz2 :: winsup: http://www.cygwin.com/snapshots/winsup-src-20060418.tar.bz2 ::install: http://www.cygwin.com/snapshots/cygwin-inst-20060418.tar.bz2 :: diffs: http://www.cygwin.com/snapshots/winsup-changelog-20060417-20060418 :: changelog: http://www.cygwin.com/snapshots/winsup-diffs-20060
slowness issue between 20060309 and 20060313
I'm trying to debug a sever slowdown seen between 0309 and 0313 snapshots. I noticed this when upgrading to the latest and had to trace it back (part of the impetus for writing the script I mentioned earlier). It appears to affect all file operations within a shell, but not necessarily within a process itself, post-fork. E.g. tar runs fast on an extract, but if I were to extract the same amount of files, but through multiple calls to tar, even in a serial fashion, the slowdown is huge. It's not even slowdown that could be explained by typical fork overhead, it's literally 200% the difference. For my actual test, I'm using a small source directory of about 20-30 C source files from one of my projects and: $ make clean $ time make all Actual times seen: 20060309: real1m47.328s user0m17.074s sys 0m59.145s 20060318: real3m20.953s user0m11.703s sys 0m45.895s 20060314: real3m21.594s user0m11.713s sys 0m45.894s 20060313: real3m21.594s user0m11.715s sys 0m46.134s >From 20060313 and any snapshot above that, I see the exact same behavior. From >any below *and including* 20060309 I do *not* see the behavior. The changelog for 20060313 specifies: ChangeLog for 20060309 to 20060313 -- winsup/cygwin/ChangeLog -- 2006-03-13 Christopher Faylor <[EMAIL PROTECTED]> * child_info.h (child_info_fork::handle_failure): Declare new function. (child_info_fork::retry): New field. * dcrt0.cc (__api_fatal_exit_val): Define. (child_info_fork::handle_failure): Define new function. (__api_fatal): Exit using __api_fatal_exit_val value. * environ.cc (set_fork_retry): Set fork_retry based on CYGWIN environment variable. (parse_thing): Add "fork_retry" setting. * fork.cc (fork_retry): Define. (frok::parent): Reorganize to allow retry of failed child creation if child signalled that it was ok to do so. * heap.cc (heap_init): Signal parent via handle_failure when VirtualAlloc fails. * pinfo.h (EXITCODE_RETRY): Declare. * sigproc.cc (child_info::sync): Properly exit with failure condition if called for fork and didn't see subproc_ready. * spawn.cc (spawn_guts): Use windows pid as first argument. * winsup.h: Remove obsolete NEW_MACRO_VARARGS define. (__api_fatal_exit_val): Declare. (set_api_fatal_return): Define. (in_dllentry): Declare. * exceptions.cc (inside_kernel): Remove unneeded in_dllentry declaration. 2006-03-13 Christopher Faylor <[EMAIL PROTECTED]> * dcrt0.cc (dll_crt0_0): Reorganize so that sigproc_init is called a little later. Add a comment. * fork.cc (resume_child): Make void. (frok::parent): Only zero pi when necessary. Explicitly zero si. Set this_errno when child_copy fails. Accommodate change to resume_child. * sigproc.cc (sigalloc): Move global_sigs initialization here. (sigproc_init): Move global_sigs. (sig_send): Just check for flush signals once. * wincap.h: Define supports_setconsolectrlhandler_null throughout. * wincap.cc: Ditto. 2006-03-13 Corinna Vinschen <[EMAIL PROTECTED]> * autoload.cc (LoadDLLfuncNt): New define to wrap NT native functions. Use for NT native functions throughout. * dtable.cc (handle_to_fn): Treat return value of NtQueryObject as NTSTATUS value. 2006-03-12 Christopher Faylor <[EMAIL PROTECTED]> * cygtls.cc (_cygtls::remove): Reset initialized flag right away if we were previously initialized. * cygtls.h (_cygtls::initialized): Move nearer to the end to catch situation when Windows 98 mysteriously changes parts of _my_tls when thread is detaching. * gendef (__sigfe_maybe): Simplify slightly. * tlsoffsets.h: Regenerate. 2006-03-12 Christopher Faylor <[EMAIL PROTECTED]> * cygtls.h (CYGTLS_INITIALIZED): Change to a little more unlikely value. (CYGTLSMAGIC): Delete. * dcrt0.cc (dll_crt0_0): Call sigproc_init during init startup. (_dll_crt0): Don't worry about sync_startup. Just wait for sigthread here. * dll_init.cc (cygwin_detach_dll): Only pick up tls version of retaddr if we have a valid tls. * fork.cc (frok::child): Remove sigproc_init initialization since it happens much earlier now. * gendef: Recognize SIGFE_MAYBE. (fefunc): Generate calls to _sigfe_maybe, if appropriate. (_sigfe_maybe): New function. * init.cc (search_for): Always initialize search_for, even on fork. (calibration_thread): Delete. (calibration_id): Delete. (prime_threads): Delete. (munge_threadfunc): Remove calibration_thread special case. Avoid calling thread function if we haven't yet hit the "search_for" thread. (dll_entry): Remo
Re: slowness issue between 20060309 and 20060313
On Sun, May 14, 2006 at 01:24:04PM -0700, [EMAIL PROTECTED] wrote: > not even slowdown that could be explained by typical fork overhead, it's > literally > 200% the difference. > > >From 20060313 and any snapshot above that, I see the exact same behavior. > >From any > below *and including* 20060309 I do *not* see the behavior. > > -cl Based on looking over the diff, I'm starting to wonder if the slowdown is primiarly occuring due to later changes somewhere because of: * fork.cc (fork_retry): Define. (frok::parent): Reorganize to allow retry of failed child creation if child signalled that it was ok to do so. Since it now it appears to be operating in an infinite loop with breakouts. What's the best way of narrowing down the actual reason for slowdown? strace? Modifying the diff to add extra debugging output specifying the amount of retries that may have occured? -cl -- 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: slowness issue between 20060309 and 20060313
On Sun, May 14, 2006 at 01:49:49PM -0700, [EMAIL PROTECTED] wrote: > On Sun, May 14, 2006 at 01:24:04PM -0700, [EMAIL PROTECTED] wrote: > > not even slowdown that could be explained by typical fork overhead, it's > > literally > > 200% the difference. > > > > >From 20060313 and any snapshot above that, I see the exact same behavior. > > >From any > > below *and including* 20060309 I do *not* see the behavior. > > > > -cl So from analyzing strace output of two exact same commands, (in this case "strace make clean"), everything is about the same between 20060309 and 20060313 up until forking off make.exe: 20060309: ** Program name: C:\cygwin\bin\make.exe (pid 12812, ppid 7488) App version: 1005.20, api: 0.155 DLL version: 1005.20, api: 0.155 DLL build:20060309 10:35:06SNP OS version: Windows NT-5.2 Heap size:402653184 Date/Time:2006-05-14 15:57:54 ** 26 196 [main] make 12812 set_myself: myself->dwProcessId 12812 58 254 [main] make 12812 child_copy: dll data - hp 0x6D4 low 0x610FB000, high 0x610FFB00, res 1 697570 697824 [main] make 12812 child_copy: dll bss - hp 0x6D4 low 0x61138000, high 0x61141690, res 1 235 698059 [main] make 12812 child_copy: user heap - hp 0x6D4 low 0x44, high 0x47, res 1 25 698084 [main] make 12812 child_copy: done 34 698118 [main] make 12812 child_copy: data - hp 0x6D4 low 0x424000, high 0x4249F0, res 1 30 698148 [main] make 12812 child_copy: bss - hp 0x6D4 low 0x426000, high 0x426770, res 1 25 698173 [main] make 12812 child_copy: done 23 698196 [main] make 12812 fixup_mmaps_after_fork: succeeded 43 698239 [main] make 12812 events_init: windows_system_directory 'C:\WINDOWS\system32\', windows_system_directory_length 20 42 698281 [main] make 12812 dll_crt0_0: finished dll_crt0_0 initialization 136 698417 [main] make 12812 frok::child: child is running. pid 12812, ppid 7488, stack here 0x22DF28 25 698442 [main] make 12812 sync_with_parent: signalling parent: after longjmp 28 698470 [main] make 12812 child_info::ready: signalled 0x6E4 that I was ready 4964 698475 [main] make 7488 child_info::sync: process 12812 synchronized, WFMO returned 0 44 698519 [main] make 7488 frok::parent: child is alive (but stopped) 44 698563 [main] make 7488 child_copy: stack - hp 0x6C0 low 0x22DF30, high 0x23, res 1 27 698590 [main] make 7488 child_copy: done 23 698613 [main] make 7488 frok::parent: copying data/bss of a linked dll 40 698653 [main] make 7488 child_copy: linked dll data - hp 0x6C0 low 0x6B344000, high 0x6B344010, res 1 33 698686 [main] make 7488 child_copy: linked dll bss - hp 0x6C0 low 0x6B41E000, high 0x6B41E3B0, res 1 27 698713 [main] make 7488 child_copy: done 23 698736 [main] make 7488 frok::parent: copying data/bss of a linked dll 36 698772 [main] make 7488 child_copy: linked dll data - hp 0x6C0 low 0x6B2D9000, high 0x6B2D9070, res 1 34 698806 [main] make 7488 child_copy: linked dll bss - hp 0x6C0 low 0x6B2DB000, high 0x6B2DB4C0, res 1 25 698831 [main] make 7488 child_copy: done 24 698855 [main] make 7488 resume_child: signalled child 389 698859 [main] make 12812 sync_with_parent: awake 23 698878 [main] make 7488 child_info::sync: n 2, waiting for subproc_ready(0x6E4) and child process(0x6C0) 28 698887 [main] make 12812 sync_with_parent: no problems 23 698910 [main] make 12812 frok::child: hParent 0x6D4, child 1 first_dll 0x6B43, load_dlls 0 34 698944 [main] make 12812 set_privilege: 1 = set_privilege ((token 780) SeRestorePrivilege, 1) 26 698970 [main] make 12812 set_privilege: 1 = set_privilege ((token 780) SeBackupPrivilege, 1) 24 698994 [main] make 12812 set_privilege: 1 = set_privilege ((token 780) SeChangeNotifyPrivilege, 1) 33 699027 [main] make 12812 set_file_api_mode: File APIs set to ANSI 30 699057 [main] make 12812 dtable::fixup_after_fork: fd 3 () 24 699081 [main] make 12812 fhandler_base::fixup_after_fork: inheriting '' from parent 32 699113 [main] make 12812 sync_with_parent: signalling parent: performed fork fixup 24 699137 [main] make 12812 child_info::ready: signalled 0x6E4 that I was ready 265 699143 [main] make 7488 child_info::sync: process 12812 synchronized, WFMO returned 0 137 699274 [main] make 12812 sigproc_init: process/signal handling enabled, state 0x801 84 699358 [main] make 12812 pthread_mutex::_fixup_after_fork: mutex 441C48 in _fixup_after_fork 43 699401 [main] make 12812 pthread_mutex::_fixup_after_fork: mutex 440060 in _fixup_after_fork 27 699428 [main] make 12812 pthread_mutex::_fixup_after_fork: mutex 611411A8 in _fixup_after_fork 369 699512 [main] make 7488 sig_send: sendsig 0x704, pid 7488, signal -41, its_me 1 28 699540 [main] make 7488 sig_send: wakeup 0x6D0 31 699571 [main] make 7488 sig_send: Waiting for pack.wa
Re: Fwd: Got any 'fileno_unlocked'?
On Fri, May 12, 2006 at 12:49:36PM -0700, Brian Dessent wrote: > > It has nothing to do with file locking, but rather locking in the sense > of thread-safety. A programmer can call the _unlocked version of a > number of functions when he is sure that the application only has one > thread, and avoid a very slight penalty of having to set a mutex before > modifying the data structures. >[...] > Furthermore, these _unlocked functions are *not* standardized functions, > they are GNU extensions, and this means the programmer has made his code > unportable by assuming they exist without the aid of a configure test. > This is a bad thing to do. > > Brian Shouldn't the existance of .*_unlocked functions come into scope after defining _REENTRANT ? I know that even on Solaris, you will see malloc_unlocked() etc. calls, but mainly in threads programs. Even including a threaded header (pthreads.h, thread.h) should define _REENTRANT, so the specific definition isn't necessarily required but I just wonder why a developer would go out of their way to even call these backend functions. Bad mojo there for sure. -cl -- 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: need help with cygwin snapshot debugging
On Wed, May 10, 2006 at 02:01:35PM -0400, Christopher Faylor wrote: > There are a few reported problems with the current snapshots that > require some debugging: > > 1) http://cygwin.com/ml/cygwin/2006-04/msg00718.html > > I would appreciate knowing if anyone can duplicate 1) above and > I'd like to know if my debugging suggestion in 2) worked. If you > can duplicate 1) then any insight into why it is happening would > be welcome. While I would say I used to have more fork(): resource not available issues pre 0313, I also had made changes to my desktop heap settings in the registry - colluding any of my own efforts to tie in a specific snapshot as having "fixed" my fork() issues. I still see them *occasionally* but not nearly as often after having adjusted my desktop heap. However, the slowness issue in 20060313(+onwards) is extremely prevalent for me currently. -cl -- 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: need help with cygwin snapshot debugging
> Hmm. I don't see any reason for you to have included my message, > ignored it, and then used this thread to 1) reiterate observations you > made in another message and/or 2) discuss something unrelated to my > request. > > cgf I don't see any reason for your rude reply to me. Read your own message: "In general, I'd appreciate any *substantive* effort to track down snapshot problems. Since the previous "call for testing" thread seems to have gotten bogged down a little, please post any snapshot-related observations here." Which I did, so get off my ass. -cl -- 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: rvxt-20050409-1 console problem
BTW, isn't is possible to just make the console window created start without SW_VISIBLE? While it would still be created - it would be created invisbly. -cl On Mon, May 15, 2006 at 01:08:07PM -0400, Harig, Mark wrote: > The new console-hiding code causes the console window to be automatically > hidden. If the shortcut icon approach to starting rxvt is used, then > there is no need (that I know of) to have the console-hiding code > included in 'rxvt' because no console would be displayed (or if it is, > then it is already automatically hidden). This would then leave the > console displayed for those users who need it. -- 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: The $HOME variable; rxvt and .inputrc
On Mon, May 15, 2006 at 11:16:12AM -0700, George wrote: > Friendly is a girl with a nice smile holding my hand and pressing my > keys for me while serving me rum drinks with little umbrellas in them. See the real issue here is how we can configure rxvt to provide the above. > No? > > Ok, how about friendly is not having taking my hands off the keyboard's > home row to reach for PageUp/Down or, worse, the arrow keys? Shift-pageup/shift-pagedown are so incredibly embedded into a typical X/rxvt/xterm users' head at this point that it's pretty much a motor function. I think that you will find most people using X for the majority of their work are not sticking to the home keys and proper keyboard position as a strict order - but only when they need to. It also helps to develop that 'edge of thumb on top-left of shift + ring finger on page up/down' action. :) That being said, you *can* change them, but I believe it requires hacking at your .Xresources file or equivalent. -cl -- 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: console question
On Tue, May 16, 2006 at 11:03:01AM -0400, Jeff Lange wrote: > well I've given up on that, now I'm hacking away at puttycyg to make > it do what I need it to do, like send out the correct high F keys, and > adding an argument to make it full screen on startup. =) > > Thanks, > -Jeff Do you use a 640x480 screen? Full screen for a console sounds like a grand waste of field of vision. -- 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: simple test triggers fork errs for me in 4/27 snapshot
On Tue, May 16, 2006 at 09:08:28AM -0500, Tom Rodman wrote: > If I revert to the April 3 snapshot it works fine. For the 4/27 > snapshot, it's repeatable, the commands above resulted in fork errors > when I tried it just after after a reboot today, and again after all > cygwin processes had been killed. I see this under 20060309 as well. -cl -- 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: listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19
> From: Corinna Vinschen
> To: cygwin at cygwin dot com
> Subject: Re: listen/accept/fork behavior problem between cygwin1 1.5.18 and
> cygwin1.dll 1.5.19
> Message-ID: <[EMAIL PROTECTED]>
> Reply-To: cygwin at cygwin dot com
>
> On Mar 9 17:54, BRC wrote:
> > Hi,
> >
> > I have a perl based server that creates a TCP listen
> > socket in a parent process, then forks off an N-child
> > process pool that normally accepts connections
> > round-robin style alla apache 1.3. Everything worked
> > great when I was based on cygwin1.dll version 1.5.18.
> > I would see many requests being simulatenously
> > sometimes lasting up to a minute.
> >
> > Then I did a recent upgrade and suddenly all requests
> > became serialized. That is, an entire request would
> > need to be handled before a pending one a child began.
> > I immediately downgraded perl to 5.8.6-4 from
> > 5.8.7-5. Nothing changed. Then I did a complete
> > cygwin rollback and the concurrency went back to
> > normal. I was then able to advance just the version
> > of perl back to 5.8.7-5 and everything still works.
> > After lots of back and forth, I was able to isolate
> > the behavior difference to cygwin1.dll.
> >
> > [snip]
> >
> > I realize that Perl's fork under cygwin is technically
> > using threads so I left wondering if this is a
> > blocking
> > io problem (that changed with cygwin revs) since it
> > seems to transcend perl.
>
> I have no idea how that should happen at all and so I assume I don't
> understand exactly how your application works.
>
> Could you please create a simple testcase in plain C, stripped to the
> bare minimum of lines, building and working OOTB, which allows to
> reproduce the problem? That would be most helpful.
>
> Another test you could also make is this: Can you easily change your
> listen/accept/action code so that only the server accepts and then
> a child is forked for the associated action? Does that maintain
> concurrency in your server with 1.5.19?
>
> Corinna
>
> --
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader cygwin AT cygwin DOT com
> Red Hat
I'm not using perl, but I observed this behavior the other night when trying
to debug an accept() issue with pthreads.
Test case (my original network wrappers left in, since it would create more
space
not to leave them as functions; error checking stripped down for the test code
and printf()s added):
/* code */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define NE(x) (sizeof(x) / sizeof((x)[0]))
int llimit;
int pa;
int pc;
int n_nodelay(int s, socklen_t op)
{
if (setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (void *)&op, sizeof((op =
1))) == -1) {
perror("setsockopt");
return -1;
}
return 0;
}
int n_nonblock(int s)
{
if (fcntl(s, F_SETFL, (fcntl(s, F_GETFL, 0) | O_NONBLOCK)) == -1) {
perror("fcntl");
return -1;
}
return 0;
}
int n_accept(int s)
{
struct sockaddr_in sa_r;
socklen_t b;
int c;
b = sizeof(sa_r);
if ((c = accept(s, (struct sockaddr *)&sa_r, &b)) == -1) {
perror("accept");
return -1;
}
n_nonblock(c);
return c;
}
int n_listen(int s, int backlog)
{
if (listen(s, backlog) == -1) {
perror("listen");
return -1;
}
return 0;
}
int n_bind(int s, struct sockaddr_in *sa)
{
if (bind(s, (struct sockaddr *)sa, sizeof(struct sockaddr)) == -1) {
perror("bind");
return -1;
}
return 0;
}
int n_init(struct sockaddr_in *sa, const char *addr, unsigned short port)
{
struct hostent *hp;
memset(sa, 0, sizeof(struct sockaddr_in));
sa->sin_family = AF_INET;
if (port) sa->sin_port = htons(port);
if (isdigit(*addr)) {
if (memcmp(addr, "0.0.0.0", 8) == 0) {
sa->sin_addr.s_addr = INADDR_ANY;
} else if ((sa->sin_addr.s_addr = inet_addr(addr)) ==
INADDR_NONE) {
perror("inet_addr");
return -1;
}
} else {
if ((hp = gethostbyname(addr)) == NULL) {
if (h_errno == HOST_NOT_FOUND)
fprintf(stderr, "gethostbyname: unknown
host\n");
else
fprintf(stderr, "gethostbyname: error\n");
return -1;
}
sa->sin_family = hp->h_addrtype;
memcpy((char *)&sa->sin_addr, hp->h_addr, hp->h_length);
}
return 0;
}
int n_socket(void)
{
int s;
int ruse;
Re: Join my Earthscreen network
On Sat, May 20, 2006 at 06:42:07PM +0300, Jagan Mohan wrote: > I'm doing a little something for the earth, and I thought I'd invite > you to join me: > > http://friends.earthscreen.com/?r=cQGEWBETCSZWBmEOAiEE&i=gmail&[EMAIL > PROTECTED]&p=1&z=1&tc=11 "How does it work? It's simple! Sign up at friends.earthscreen.com, and register with earthscreen to Adopt Your Earth. Share friends.earthscreen.com with your friends by sending them a link so that they can help too. When 5 friends register and Adopt the Earth, we will send you your $25 Vivavi gift card voucher, as well as give you entries into the Eco Adventure Sweepstakes to Belize . You can find you free screensaver on the earthscreen website." -- how eco friendly of them to pump out gift cards, lame corporate crap. -cl -- 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: GDB and Cygwin SIGSEGV revisited
On Sun, May 21, 2006 at 07:14:52AM -0700, Brian Dessent wrote: > Richard Schmitt wrote: > > > - downloaded the latest gdb (6.4), built it and installed it. > > [...] > > doesn't suffer from this problem? The issue was fixed in CVS earlier > > this year. But do note that it requires functionality not present in > > 6.4 won't do, it's too old. The fix was committed in February 2006. > 6.4 was released in December 2005. 6.4 works, but I've found that no matter what, initializing the following: 1. mutex attribute type 2. thrad attribute type results in a SIGSEGV. mutex and condvars no longer result in a visible SIGSEGV with one of the newer snapshots and 6.4. Also, I've found a better method which is: handle SIGSEGV noprint nostop handle SIGTRAP noprint nostop Another method I've taken is to dynamically initialize all mutexes, attributes, and condvars. But really I should have to do *any* of the above to debug code, as they are mediocre solutions. -cl -- 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: GDB and Cygwin SIGSEGV revisited
On Sun, May 21, 2006 at 04:39:18PM -0400, Christopher Faylor wrote: > >6.4 works, but I've found that no matter what, initializing the > >following: > > There is no way that 6.4 is going to fix this problem since, as Brian > noted, its release predates the fix that I checked in to deal with the > problem. Then what changed which stopped me from seeing SIGSEGV signals with later snapshots while changing nothing in my code? It did not stop ALL of them, but it did stop the pthread_mutex_init() case ones. -cl -- 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: GDB and Cygwin SIGSEGV revisited
On Sun, May 21, 2006 at 06:40:45PM -0400, Christopher Faylor wrote: > Again, Brian answered the question correctly. Building a 6.4 version of > gdb is not going to solve this problem. > > cgf Okay, so what is the exact answer? Is it: CVS HEAD build of gdb will fix the issue? -cl -- 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: 20060521 snapshot, Ctrl-C, and Windows processes
On Sun, May 21, 2006 at 10:19:06PM -0400, Igor Peshansky wrote: > Noticed a problem today: if you start a Windows process in bash and press > Ctrl-C, the Ctrl-C will be delivered to the process, but then bash (or the > Cygwin wrapper that waits for the Windows process) will simply hang until > the Windows process terminates. If the process does not terminate (e.g., > "ping -t"), bash will hang until Ctrl-C is pressed 10 times (the delays > between the consecutive Ctrl-Cs don't seem to matter). > > Steps to reproduce: > > In bash, type "ping -t cygwin.com", then, after a couple of ping results, > press Ctrl-C. The process will hang (here's the screenshot): > > $ ping -t cygwin.com > > Pinging www.cygwin.com [209.132.176.174] with 32 bytes of data: > > Reply from 209.132.176.174: bytes=32 time=82ms TTL=46 > Reply from 209.132.176.174: bytes=32 time=83ms TTL=46 I know this may sound insane, but could you try the following in another shell when it is hanging: ping localhost or ping -cl -- 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: "Please don't discuss other, competing products here"
On Mon, May 22, 2006 at 06:50:38PM -0700, David Christensen wrote: > 3. Last but not least, the open-source software (OSS) movement used to > have at its core the concept of "Freedom", including "Freedom of > Speech". OSS projects were simply assumed by the OSS community to > allow freedom of speech (within reason); those that did not invited > protest and/or rejection. > > David I too, do not see the issue with discussing 'competing' products here. What's the issue? -cl -- 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: 1.5.19: changes have broken Qt3
On Wed, May 24, 2006 at 01:49:53AM -0700, Brian Dessent wrote: > Sigh. We've been through this ad nauseum in the archives. This is how > it's supposed to work, there's nothing wrong here. Gdb doesn't know any > better though, and reports it as a SIGSEGV, when it is not. Did you not > notice that when you run the program outside of the debugger it does not > fault? If you use a recent Cygwin snapshot and a gdb built from CVS you > see no such fault, because this defect in gdb has been fixed. > > Brian Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV signal, correct? GDB does what it's told, stops on SIGSEGV by default. -cl -- 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: 1.5.19: changes have broken Qt3
On Wed, May 24, 2006 at 11:40:58AM +0100, Dave Korn wrote: > > Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV > > signal, correct? GDB does what it's told, stops on SIGSEGV by default. > > > > -cl > > But it doesn't interact properly with cygwin's exception handling -> signal > mechanism, and the task dies, when it should just run on. > > Anyone who's doing any serious debugging on Cygwin very seriously wants to > build their own gdb and insight from current CVS. It's much improved of late. Right, or bless their sanity - as it won't last long. But I'm just trying to debate that it's no "lacking" of gdb that it's catching SIGSEGV signals which are being artificially generated by cygwin. What's the design mechanism for the entire 'check for non-initialized space and segfault if uninitialized' when it comes to statically initialized pthreads objects in the first place, btw? Why not just have pthread_mutex_t (for example actually be a pthread_mutex_t instead of it being a type'd pointer to the real pthread_mutex_t? Why dynamically initialize space for it at all via the check bunk memory->throw fault->alloc real memory for real pthread_mutex_t as opposed to "initialiize the mutex->if bunk space, segfault as usual" ? -cl -- 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: Cygwin, gdb and SEH [was RE: 1.5.19: changes have broken Qt3]
On Wed, May 24, 2006 at 07:06:32PM +0100, Dave Korn wrote: > YES, THERE IS A WAY! > > WHAT IS MORE YOU HAVE ALREADY HAD IT EXPLAINED TO YOU A DOZEN TIMES IN THIS > THREAD! > > THE WAY IS TO USE AN UP-TO-DATE GDB! BTW: Myself, I had just updated to CVS gdb. Currently it looks like SIGINT is busted (well atleast initiating via ctrl-c) and performance under gdb is crap (probably because I'm trying to debug something with millions of objects - each with their own mutexes). -cl -- 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: slow share = slow scripts?
On Thu, May 25, 2006 at 12:34:10PM -0500, mwoehlke wrote: > Here is what I am talking about: > ~$ mount h:/mwoehlke/src /usr/src > mount: defaulting to '--no-executable' flag for speed since native path >references a remote share. Use '-f' option to override. >^^^ > > ...neither 'mount --help' or 'man mount' makes *any* mention of this > additional functionality of the '-f' flag. See? I'm *not* imagining > things. :-) The guy was simply stating that he's human and headn't read it yet. He also pointed out that an implicit behavior was not explicitly documented as such, but more so infered by output when using the --no-executable flag. ' -f, --force force mount, don't warn about missing mount point directories ' To you guys saying 'get off the computer' I suggest you put the pedant pills back in the bathroom and go have a smoke or something - because you're being a dick about it. Cut people some slack for once - they're on the same side as you trying to achieve the same goals. -cl -- 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: slow share = slow scripts?
On Thu, May 25, 2006 at 02:11:09PM -0400, Christopher Faylor wrote: > Language, please. Warning #1. Feel the power. > >Cut people some slack for once - they're on the same side as you trying to > >achieve the same goals. > > What you apparently are failing to realize is that while people > certainly have human foibles, there is no need to go out of your way > expose them to a mailing list read by thousands of people. It isn't > necessary or interesting. Yet it is also harmless and not really a bother. He's simply sharing an occurence, which possibly othes might have had, as a means of identification and tribal knowledge. Had he posted every single occurence of realizing his own mistakes - it'd be another issue - which it hasn't been. > (especially when you hadn't previously exposed your misconception) and > you surely don't have to send *two* messages explaining your confusion > when there really is nothing to be confused about. Yet we have to tell the guy to get off the computer and imbue user-stupidity instead? What purpose does that have? If the purpose is in alienating a fellow cygwin user/hacker/future contributor/etc. - then good job. -cl -- 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: 1.5.19: changes have broken Qt3
On Sun, May 28, 2006 at 01:04:52PM +0200, Ralf Habacker wrote: > I just downloaded cywin snapshot 2005-06-27 and got running designer and > uic without any problem, so it looks like there is no need to deep > more into this stuff. I will follow the next time if this problems takes > places again. > > Regards > Ralf That's just a tad old there, Ralf. Tried any of the more recent snapshots at http://www.cygin.com/snapshots/ ? -cl -- 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: 1.5.19: changes have broken Qt3
> That's just a tad old there, Ralf. > Tried any of the more recent snapshots at http://www.cygin.com/snapshots/ ? Mistype. http://www.cygwin.com/snapshots/ -- 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: listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19
On Wed, Jun 14, 2006 at 10:40:25PM +0200, Corinna Vinschen wrote: > > Thanks very much for your testcase. I applied a patch to Cygwin, please > give the next developer snapshot from http://cygwin.com/snapshots/ a try. > > Corinna Thank you Corinna. This appears to work much better and expected. BTW: I think the same issue may also exist for both read() and write() and possibly any other read, write, send, recv variant when using multiple threads as opposed to single thread + select(). One thing I notice is that if a read() is in progress and one is currently sitting in select(), all other read()s in seperate select()s will then stall if the former read() times out or takes longer than expected. -cl -- 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: listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19
On Thu, Jun 15, 2006 at 09:58:40AM +0200, Corinna Vinschen wrote: > > thread + select(). One thing I notice is that if a read() is in progress > > and one > > is currently sitting in select(), all other read()s in seperate select()s > > will > > then stall if the former read() times out or takes longer than expected. > > Your observation is correct, the same issue exists for recv/send and, > FWIW, connect. I can fix the connect case, too, but there is no easy > patch for the recv/send case, unfortunately. This has to do with the > way WSAEventSelect is handled in WinSock. > > For now, if you want concurrency, either use non-blocking recv/send > exclusively, or never spread handling of the same blocking socket over > multiple threads. Hopefully I can come up with a solution for this > problem at one point. > > Corinna Actually the behaviour I'm noticing is within the same calling thread. For instance, in almost all of my network functions I'm passing an fd and using that fd with select to handle timeouts (connect/read/write all NB). So in each case the same calling thread is doing the typical sequence: socket -> connect -> write -> read -> close. The fd returned by socket() is never used outside of that thread. So instead of a single thread w/ a single select and iterating over multiple fds, post-select(), I have a thread pool with only one fd-used-at-once-per-thread but multiple threads executing concurrently. When a seperate fd entirely exhibits a read() timeout, it appears to affect read/write in all other threads using different fds. Basically, as long as data is flowing in all threads, there is no issue - but the second any one fd stalls in any given thread - they all stall until I close that fd after read() times out (where select() is indicating the timeout). You can see the implementation of these network functions in the original test case. I basically have a thread pool with each thread calling those functions in the same order socket, connect, write, read, close. -cl -- 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: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 01:20:40AM -0700, Kyle McKay wrote: > I'm almost never running gdb from a genuine DOS command prompt. > Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't > work in those. Same here. > Finally, it NEVER works no matter what if you are debugging a program > built with a different compiler such as m$ visual C++. And, of > course, you say I have no reason to do that since the debugging > symbols will not be compatible. However, the m$ visual C++ built > program is then loading a cygwin/mingw built DLL. CTRL-C doesn't > work in this case to interrupt the running program. Although if you > are careful you can get breakpoints set, but if you change your mind > after you start running the program again then you're out of luck. > That's where the debugbreak utility comes in very handy. > > Lacking the ability to interrupt a running program severely limits > gdb's usefulness. Fortunately there's a workaround available. I find it does it to me 100% of the time if I'm using putty+ssh or putty+cygputty hack. There's no way I'm using the native cmd shell or the default cygwin cmd shell. It's extremely frustrating when one realizes they've just done a "d b", "c" and realize they have no ability to now stop gdb or even stop anything without hitting up task manager and killing the process. BTW Kyle, you can extend your program greatly by using process enumeration coupled with strcmp on the image name to find the pid based on a string and automatically signal it. But honestly I don't think this program should be needed in the first place. -cl -- 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: sshd connection reset by peer problem
This doesn't look like a cygwin problem to me at all. Look at the first 20 lines of your debug output again. -cl On Thu, Jun 15, 2006 at 04:46:23AM -0700, marct wrote: > "Read from socket failed: Connection reset by peer" AKA "you sent bunk data, try again." > $ ssh -vvv localhost > OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 > debug1: Reading configuration data /etc/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to localhost [127.0.0.1] port 22. > debug1: Connection established. > debug1: identity file /cygdrive/c/Documents and > Settings/TordoffM/.ssh/identity > type 0 > debug3: Not a RSA1 key file /cygdrive/c/Documents and > Settings/TordoffM/.ssh/id_ > rsa. > debug2: key_type_from_name: unknown key type '-BEGIN' -- 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: g++ 4.1?
It should also be noted that some of the latest snapshot, or code that still exists in the latest snapshot, will fail under 4.1.1. Specifically: declaration of objects within a label statement. -cl On Mon, Jun 26, 2006 at 09:52:41PM +0100, Joe Schmoe wrote: > Thanks to all that encouragement, I now have not one but two working > installations of gcc-4.1.1. As Brian said, the cygwin compiler will > configure and make with no problems, except that -mno-cygwin doesn't > work. For a no-cygwin compiler, this is what I did -- I'm not saying -- 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: rsync thinking a local transfer is "remote"
On Mon, Jun 26, 2006 at 04:35:30PM -0700, Linda Walsh wrote: > I've got a weird situation with rsync. I'm trying to > transfer some files from a network share mounted as "B:\". Anything strange about the filenames in those directories? Colons or otherwise? -- 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: compile linux kernel in cygwin
Do you like pain? -cl On Wed, Jun 28, 2006 at 04:01:57PM +0530, hulge hulge wrote: > hi all > while compiling kernel i am getting following error > when i run command make bzImage -- 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: Which list should cygwin development be discussed on ?
On Sat, Jul 01, 2006 at 03:42:00PM -0400, Joe Smith wrote: > > "Christopher Faylor" <[EMAIL PROTECTED]> wrote in > > > >No. The mailing list descriptions really are accurate. If you don't > >have a patch, then you shouldn't be sending email to cygwin-patches. > > > > Most cygwin development discussion occurs on the main list or on > cygwin-apps. And of course the discussion and methodology behind the internal development of the cygwin libraries, issues, and future ideas is - in true opensource form (NOT) - on a completely closed list, invite-only, with no public access to any form of archives. What exactly is the positive purpose behind that? "cygwin-developers: a by-approval developers list for discussing the internals of the Cygwin DLL and all components of the "winsup" directory. Discussions of upcoming net releases are also appropriate. Subscription requests are handled on a case-by-case basis. Only subscribers may submit email to this list. Please do not attempt to join the cygwin-developers mailing list unless 1) you are thoroughly familiar with the cygwin DLL, 2) you have successfully built the DLL from source, 3) you contributed at least one patch to the Cygwin DLL or its utilities, and 4) you intend on being a long-term contributor. Please do not ask for "read-only" access to this mailing list. You either qualify or you don't. There is no middle ground." -cl -- 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/
change in 20060704 snap
-/* undocumented in wsock32.dll */ -extern "C" unsigned int WINAPI inet_network (const char *); - extern "C" unsigned int cygwin_inet_network (const char *cp) @@ -157,7 +152,5 @@ cygwin_inet_network (const char *cp) if (efault.faulted (EFAULT)) return INADDR_NONE; - unsigned int res = inet_network (cp); - - return res; + return ntohl (inet_addr (cp)); } Won't this be returning a full host address rather than a network address now? If need be, I could contribute by writing cygwin-native versions of inet_pton, inet_ntop, inet_aton, inet_ntoa, etc. rather than calling the windows variants. inet_addr on it's own is already pretty bitrotted at this point as well. -cl -- 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/
cygwin fork()
Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? While building projects using libtool (which using heavy sh, hence fork() calls) I regularly have to fire off 'make -j16's just to get around waiting ages when using a single make job. -cl -- 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: cygwin fork()
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: > > Is it just me or is cygwin fork(), or a support syscall underneath, > > terribly slow for some reason? > > Some reason == "lack of O/S support". Yes I can understand that. I'm assuming there is some CreateProcess() magic happening behind the scenes. However, what I've noticed is that it is WAY slower than one would think it to be. -cl -- 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: cygwin fork()
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: > On 01 September 2006 11:02, [EMAIL PROTECTED] wrote: > > > Is it just me or is cygwin fork(), or a support syscall underneath, > > terribly slow for some reason? > > Some reason == "lack of O/S support". Basically, this is what I'm talking about: Opteron 180, fast disks, ran make clean, make 4 times or so to keep the disk/mem/cpu caches hot; no extraneous system usage going on: $ ( make clean; time make -j1 ; make clean; time make -j8 ) >/dev/null real2m20.062s user0m13.252s sys 0m37.139s real0m45.654s user0m15.968s sys 0m49.201s That's a huge difference, and it's only like 6300 lines of code! I've narrowed it down to something between 20060309 and 20060313 snapshots. Every snapshot since 20060313 has had this incredible slowness issue with fork(). The dual-coreness isn't going to make a huge difference here as I can get the same factor of speed up just by using 20060309's dll and the exact same make jobs. Nor is it a case of minor differences in times. I've tried different versions of libtool, gcc, etc. Everything just goes back to 20060309 vs 20060313. -cl -- 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: cygwin fork()
On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote: > While Cygwin is an *emulation* layer, and emulation is inherently slower > than straight execution, there are other potential reasons for the > slowness. Check your anti-virus and firewall software settings. If > possible, exclude the Cygwin filesystem from checking by those tools... > Even little things (like making the tool aware of the often-used Cygwin > programs and telling it to not check "outbound email messages" (!) sent by > those programs) can help speed up Cygwin... It's definitely none of those as I don't run any firewall or antivirus software whatsoever on this box. Windows 2003 Server, minimal set of services. The machine literally sits at 0% CPU unless I'm using it. > A one-sentence rant: even with those changes, whenever I run a Cygwin > shell script, the stupid vsmon process takes up 100% of the CPU. No known > solution. Sigh... Don't know what vsmon is.. A likely solution sounds to get rid of vsmon ;). Also, not to break out the ole Linux vs Cygwin time comparisons type deal, because we all know hot it's apples and oranges, in this case it's a bit absurd a difference and I kinda have to. On a Celeron 2gz Linux box w/512M RAM (which is WAY slower than a dual core Opteron 180 w/ 4GB of RAM): real0m11.507s user0m9.100s sys 0m2.320s 11s! For the same "make -j1" vs the 2m20s I got with "make -j1" on my 20060718 Cygwin box. 11s is about 1/4th the time of the best I could get my opteron to do with 'make -j8'. This is with all the exact same code. Now we know libtool is intensive, but the libtool being used is the exact same script (the build script is running a local generated version e.g. "/bin/sh ../libtool "). All I did was copy the exact same build directory to my linux host, cleaned it out, and ran the tests. Yes apples to oranges for sure, but let's look at some figures here: Linux 2.6.17.11, Celeron 2ghz/512MB/IDE drive,11.507s (make -j1) Cygwin 20060718, Opteron [EMAIL PROTECTED]/4GB/U320SCSI, 2m20s (make -j1) Cygwin 20060718, Opteron [EMAIL PROTECTED]/4GB/U320SCSI, 45.654s (make -j8) This is what specifically makes me wonder what is up. Just one small segment of the build which I copied the commands from one to the other: Linux (Celeron): [EMAIL PROTECTED] lib]$ time if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib-march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF ".deps/network.Tpo" -c -o network.lo network.c; then mv -f ".deps/network.Tpo" ".deps/network.Plo"; else rm -f ".deps/network.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -fPIC -DPIC -o .libs/network.o gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m1.254s user0m1.140s sys 0m0.110s [EMAIL PROTECTED] lib]$ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -fPIC -DPIC -o .libs/network.o real0m0.549s user0m0.520s sys 0m0.030s [EMAIL PROTECTED] lib]$ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m0.522s user0m0.510s sys 0m0.010s Cygwin (Opteron): $ time if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib-march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF ".deps/network.Tpo" -c -o network.lo network.c; then mv -f ".deps/network.Tpo" ".deps/network.Plo"; else rm -f ".deps/network.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -DPIC -o .libs/network.o gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m8.032s user0m1.166s sys 0m2.216s $ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -DPIC -o .libs/network.o real0m0.506s user0m0.249s sys 0m0.061s $ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m0.506s user0m0.233s sys 0m0.062s Obviously it's not gcc, or the execution of binary code that is slow, Same libtool, different systems, 8 times slower. Just as a crude test, I dumped the output of
Re: cygwin fork()
On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote: > > 1157123322 + echo blah1 > 1157123322 blah1 > <3 seconds of doing absolutely nothing here> > 1157123325 + test -z '' > 1157123325 + echo blah2 > 1157123325 blah2 I just also copied the same libtool to 3 different hard drives, one even a slow usb drive. Same results everytime. Even recompiling bash and specifying that instead of /bin/sh. Same. -cl -- 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: cygwin fork()
On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote: > >It's definitely none of those as I don't run any firewall or antivirus > >software whatsoever on this box. Windows 2003 Server, minimal set of > >services. The machine literally sits at 0% CPU unless I'm using it. > > Try using binary mounts instead of text mounts. > > cgf Wish it were that easy. $ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /c type system (binmode,noumount) d: on /d type system (binmode,noumount) e: on /e type system (binmode,noumount) m: on /m type system (binmode,noumount) -cl -- 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: cygwin fork()
On Fri, Sep 01, 2006 at 09:09:11AM -0700, [EMAIL PROTECTED] wrote: > On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote: > > >It's definitely none of those as I don't run any firewall or antivirus > > >software whatsoever on this box. Windows 2003 Server, minimal set of > > >services. The machine literally sits at 0% CPU unless I'm using it. > > > > Try using binary mounts instead of text mounts. > > > > cgf BTW: I started up filemon to watch what was going on from it's standpoint, and it shows a huge number of READs on libtool, all SUCCESS, but the offset is always 1 higher than previous, with a length of 1. Like it's literally reading the file 1 byte at a time, then incrementing the offset - until it has fully been read. -cl -- 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: cygwin fork()
On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote:
> BTW:
> I started up filemon to watch what was going on from it's standpoint, and it
> shows a huge number of READs on libtool, all SUCCESS, but the offset is always
> 1 higher than previous, with a length of 1. Like it's literally reading the
> file
> 1 byte at a time, then incrementing the offset - until it has fully been read.
>
> -cl
So right smack dab in the middle of _evalfile() under bash-3.1:
#if defined (__CYGWIN__) && defined (O_TEXT)
setmode (fd, O_TEXT);
#endif
Also in read_comsub():
#ifdef __CYGWIN__
setmode (fd, O_TEXT); /* we don't want CR/LF, we want Unix-style */
#endif
And most importantly in open_shell_script():
/* Open the script. But try to move the file descriptor to a randomly
large one, in the hopes that any descriptors used by the script will
not match with ours. */
fd = move_to_high_fd (fd, 0, -1);
#if defined (__CYGWIN__) && defined (O_TEXT)
setmode (fd, O_TEXT);
#endif
The high fd part jives with the '255' seen in the readv() strace output as well.
This post from 2000 looks related:
http://ecos.sourceware.org/ml/cygwin/2000-10/msg00213.html
In regards to setting the fd to textmode as a way of stripping CRs. Only problem
is that it's making 213,110 syscalls for a 213k libtool script. That cannot be
an
efficient way to remove CRs from input.
Found the old references to that too:
#if 0
#if defined (__CYGWIN__)
if (c == '\n' && istring_index > 1 && istring[istring_index - 2] == '\r')
{
istring_index--;
istring[istring_index - 1] = '\n';
}
#endif
#endif
I've since removed the setmode() calls within a bash build and am testing now.
UPDATE:
SOLVED.
Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on
reading the rest of the bash script (which I evidenced earlier as well).
p.s. Seriously old stuff in there, for example:
#if defined (__CYGWIN__)
/* Under CygWin 1.1.0, the unlink will fail if the file is
open. This hack will allow the previous action of silently
ignoring the error, but will still leave the file there. This
needs some kind of magic. */
if (r == EACCES)
return (fd2);
#endif /* __CYGWIN__ */
--
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: cygwin fork()
On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote: > I've since removed the setmode() calls within a bash build and am testing now. > > UPDATE: > SOLVED. > > Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on > reading the rest of the bash script (which I evidenced earlier as well). I also changed the input buffer size to be 32768, as opposed to 8192, and additionally enabled mmap() (since bash source had a stone age define in there indicating cygwin did not support mmap()). New 'make -j8': real0m16.806s user0m6.458s sys 0m13.328s vs. 44 seconds previously. -- 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: cygwin fork()
On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote:
> >In regards to setting the fd to textmode as a way of stripping CRs.
> >Only problem is that it's making 213,110 syscalls for a 213k libtool
> >script. That cannot be an efficient way to remove CRs from input.
>
> Opening a file with O_TEXT should not, AFAIK, cause a bunch of one-byte
> reads.
>
> A simple test case (tm) seems to confirm that.
>
> cgf
You're right. I also verified this.
I found the real culprit, which I had also ifdef'd out because it looked
bogus and crufty:
/* Return 1 if a seek on FD will succeed. */
#ifndef __CYGWIN__
# define fd_is_seekable(fd) (lseek ((fd), 0L, SEEK_CUR) >= 0)
#else
# define fd_is_seekable(fd) 0
#endif /* __CYGWIN__ */
/* Take FD, a file descriptor, and create and return a buffered stream
corresponding to it. If something is wrong and the file descriptor
is invalid, return a NULL stream. */
BUFFERED_STREAM *
fd_to_buffered_stream (fd)
int fd;
{
char *buffer;
size_t size;
struct stat sb;
if (fstat (fd, &sb) < 0)
{
close (fd);
return ((BUFFERED_STREAM *)NULL);
}
size = (fd_is_seekable (fd)) ? min (sb.st_size, MAX_INPUT_BUFFER_SIZE) : 1;
if (size == 0)
size = 1;
buffer = (char *)xmalloc (size);
return (make_buffered_stream (fd, buffer, size));
}
--
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/
