Re: Intermittent perl crash

[Larry Hall (Cygwin)]

Michael Kairys wrote:


"Reini Urban" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Known problem and easy to fix.
Download the rebase package, read the readme, stop all cygwin services 
and

run rebaseall in ash.


Thank you for the timely reply! However I am stuck on what should be a 
simple step: rebaseall tells me /tmp is not writable. I have tried a 
variety of directories (all of which are actually writable of course) 
and a variety of ways of geting there, including mount point, env. var, 
etc.


Further experimentation leads me to believe the shell will return false 
for -w of any directory. This is consistent with the apparent mode of 
555 I see on all of them. And of course they don't respond to chmod.  (I 
believe this is a windows thing that I have even read about somewhere in 
the cygwin docs...)


So I am left with the question: how would this ever work?





--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Intermittent perl crash

[Michael Kairys]

"Reini Urban" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Known problem and easy to fix.
Download the rebase package, read the readme, stop all cygwin services and
run rebaseall in ash.


Thank you for the timely reply! However I am stuck on what should be a 
simple step: rebaseall tells me /tmp is not writable. I have tried a variety 
of directories (all of which are actually writable of course) and a variety 
of ways of geting there, including mount point, env. var, etc.


Further experimentation leads me to believe the shell will return false 
for -w of any directory. This is consistent with the apparent mode of 555 I 
see on all of them. And of course they don't respond to chmod.  (I believe 
this is a windows thing that I have even read about somewhere in the cygwin 
docs...)


So I am left with the question: how would this ever work? 




--
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: Starting native windows GUI app via ssh.

[Clayton Holloway]

Sweet, it worked.
and to think it was something as simple as a check box in a windows 
dialog box.


thanks

Brian Keener wrote:

Clayton Holloway wrote:

Sounds good to me.
I doubt this is a standard ssh option so I wouldn't know what to add in 
the config.


Would you mind pasting the config that enables this or, if you don't 
remember which config option it is, the whole sshd_config.


I believe they are referring to Start -> Settings -> Control Panel -> 
Administrative Tools ->  Services:


Depending on windows version there might not be a need for administrative 
functions above but once in services - look at the sshd services options 
and on tab 2 (log in) there will be a check box for interact for desktop.


bk







--
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: Starting native windows GUI app via ssh.

[Brian Keener]

Clayton Holloway wrote:
> Sounds good to me.
> I doubt this is a standard ssh option so I wouldn't know what to add in 
> the config.
> 
> Would you mind pasting the config that enables this or, if you don't 
> remember which config option it is, the whole sshd_config.

I believe they are referring to Start -> Settings -> Control Panel -> 
Administrative Tools ->  Services:

Depending on windows version there might not be a need for administrative 
functions above but once in services - look at the sshd services options 
and on tab 2 (log in) there will be a check box for interact for desktop.

bk




--
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: Running dovecot under Cygwin

[René Berber]

Ronny wrote:

> i am trying to get imap server "dovecot" running under cygwin.
> 
> Compiling the server finished without any errors.
> But running the server does not work.
> 
> As far as i can see, dovecot runs a master process, that uses execv to
> launch a child (auth) process. The child process is killed immedeatly.
> This causes the whole server to shutdown.
> 
> Does anybody have experience with running dovecot under cygwin?

Why not go to the Dovecot site: http://wiki.dovecot.org/OSCompatibility

It clearly states that "Cygwin works after a few code changes, but
doesn't support SCM_RIGHTS" so you have to use inetd to start the imap
server...

> uw-imap, that is distributed with cygwin does not match with my needs. I
>  am looking for an imap server taht supports virtual user using a user
> database.

Untested: there are uw-imap options to use PAM (not supported in Cygwin)
and LDAP, this might work.

Probably making Dovecot work is easier.
-- 
René Berber


--
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: Starting native windows GUI app via ssh.

[Clayton Holloway]

Sounds good to me.
I doubt this is a standard ssh option so I wouldn't know what to add in 
the config.


Would you mind pasting the config that enables this or, if you don't 
remember which config option it is, the whole sshd_config.


Thanks.  :)



Roger Wells wrote:
A few weeks I asked for help with the same problem.  The advice that 
worked (I think)  was to be sure that the installation of sshd was such 
that it is allowed to interact with the desktop.
In any case I have it working in my situation so let me know if you need 
more help.

HTH

Brian Mathis wrote:
On Dec 17, 2007 3:20 PM, Clayton Holloway <[EMAIL PROTECTED]> 
wrote:
 

Is it at all possible to start a native windows application(GUI) via ssh
and have it actually appear on the windows box?

No matter what app I run via ssh (firefox, notepad, etc) the process is
listed in the task manager, but is nowhere to be found on the screen. If
X were in use here, I'd just set the DISPLAY variable, but afaik windows
won't use a DISPLAY.

Any information on this would be greatly appreciated.



You need to install the cygwin ssh service with the "Interact with
desktop" option enabled.

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

  





--
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: Starting native windows GUI app via ssh.

[Roger Wells]

A few weeks I asked for help with the same problem.  The advice that 
worked (I think)  was to be sure that the installation of sshd was such 
that it is allowed to interact with the desktop.
In any case I have it working in my situation so let me know if you need 
more help.

HTH

Brian Mathis wrote:

On Dec 17, 2007 3:20 PM, Clayton Holloway <[EMAIL PROTECTED]> wrote:
  

Is it at all possible to start a native windows application(GUI) via ssh
and have it actually appear on the windows box?

No matter what app I run via ssh (firefox, notepad, etc) the process is
listed in the task manager, but is nowhere to be found on the screen. If
X were in use here, I'd just set the DISPLAY variable, but afaik windows
won't use a DISPLAY.

Any information on this would be greatly appreciated.



You need to install the cygwin ssh service with the "Interact with
desktop" option enabled.

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

  


--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
[EMAIL PROTECTED]


--
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: Intermittent perl crash

[Reini Urban]

2007/12/17, Michael Kairys <[EMAIL PROTECTED]>:
> I apologize in advance for the scanty information here; I'm hoping someone
> can suggest how to narrow this down.
>
> I've begun using Cygwin Perl regularly in the past few days (previously used
> only AS) and I'm finding fairly simple scripts crashing intermittently with
> this message:
>
> 3 [main] perl 4348 D:\Local\Cygwin\bin\perl.exe: *** fatal error - unable to
> remap
> D:\Local\Cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Process\Process.dll
> to same address as parent(0x26) != 0x37

Known problem and easy to fix.
Download the rebase package, read the readme, stop all cygwin services and
run rebaseall in ash.

> The shell which launched the script will hang for several minutes, and then
> I will see:
>
> 9 [main] perl 2092 child_info::sync: wait failed, pid 4348, Win32
> error 183
> 265 [main] perl 2092 fork: child 4348 - died waiting for dll loading,
> errno 11
>
> By "fairly simple" I mean ones I'm working on that at this point are only
> reading arguments and doing string operations. (Oh, and globbing an argument
> and doing "-f" tests on the results). I've tried trimming them down, etc.,
> but the problem is intermittent and I can't get anything reproduceable.
>
> Any hints welcome, and TIA.
>
>
>
> --
> 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/
>
>


-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

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

[ANNOUNCEMENT] Updated: nano-2.0.6-1

[Lapo Luchini]

Version 2.0.6-1 of nano has been uploaded.

nano is a text editor designed as a clone of pico, but rewritten
from scratch to be faster and smaller while having greater functionality.

You can find information about new features here:
http://www.nano-editor.org/dist/v2.0/NEWS


If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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: Starting native windows GUI app via ssh.

[Brian Mathis]

On Dec 17, 2007 3:20 PM, Clayton Holloway <[EMAIL PROTECTED]> wrote:
> Is it at all possible to start a native windows application(GUI) via ssh
> and have it actually appear on the windows box?
>
> No matter what app I run via ssh (firefox, notepad, etc) the process is
> listed in the task manager, but is nowhere to be found on the screen. If
> X were in use here, I'd just set the DISPLAY variable, but afaik windows
> won't use a DISPLAY.
>
> Any information on this would be greatly appreciated.

You need to install the cygwin ssh service with the "Interact with
desktop" option enabled.

--
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: Intermittent perl crash

[Brian Mathis]

On Dec 17, 2007 3:22 PM, Michael Kairys <[EMAIL PROTECTED]> wrote:
>
> "Michael Kairys" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > By "fairly simple" I mean ones I'm working on that at this point are only
> > reading arguments and doing string operations.
>
> Sorry, one more thing, and probably "the" thing: system("notepad &");
> So this is clearly fork-related, but I can't get it to fail consistently
> (or, right now, at all.)
>

How are you starting the script?  From a cygwin bash shell, command
prompt, or clicking on the .pl file?  The references to
"D:\Local\Cygwin\bin\perl.exe" make me think the script is being
called through a windows mechanism instead of a cygwin one.

Maybe the .dll messages mean something to someone else?

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

Starting native windows GUI app via ssh.

[Clayton Holloway]

Is it at all possible to start a native windows application(GUI) via ssh 
and have it actually appear on the windows box?


No matter what app I run via ssh (firefox, notepad, etc) the process is 
listed in the task manager, but is nowhere to be found on the screen. If 
X were in use here, I'd just set the DISPLAY variable, but afaik windows 
won't use a DISPLAY.


Any information on this would be greatly appreciated.


--
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: Intermittent perl crash

[Michael Kairys]

"Michael Kairys" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


By "fairly simple" I mean ones I'm working on that at this point are only 
reading arguments and doing string operations.


Sorry, one more thing, and probably "the" thing: system("notepad &");
So this is clearly fork-related, but I can't get it to fail consistently
(or, right now, at all.) 




--
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: VM and non-blocking writes

[Corinna Vinschen]

On Dec 17 19:24, Corinna Vinschen wrote:
> On Dec 17 12:28, Lev Bishop wrote:
> >  If we keep having to work
> > around more issues like this, perhaps we'd be better off bypassing the
> > afd layer entirely, by setting SO_SNDBUF to 0, using overlapped IO,
> > and managing buffers ourselves. I'm sure this would bring it's own set
> > of complications, [...]
> 
> Sorry, I'm unfamiliar with the native NT socket interface :} Is there
> somewhere a (good) tutorial for the native NT socket stuff?  Even
> without using the native API, we could also just set the Winsock
> SO_RCVBUF/SO_SNDBUF settings to 0 and intercept the setsockopt/getsockopt
> calls to maintain our own buffers, right?

On re-reading, my reply seems a bit off-track.  You're suggesting to use
SO_SNDBUF==0 with overlapped I/O.  I'm asking to keep the standard
nonblocking semantics when maintaining our own per-socket buffer.

At one point the socket stuff was implemented using overlapped I/O, but
I had serious trouble with that.  What happened was that the overlapped
code waited for the socket operation to complete in a WaitForMultipleEvents
call.  When a signal arrived, I canceled the I/O operation using
CancelIO.  The problem was that the send operation is not atomic, and
there is no way to find out how much bytes from the current send buffer
have been actually sent.  So it was not possible to return the correct
number of sent bytes to the application.  Instead the code always
returned with EINTR.  This in turn could result in data corruption or
lost connections.

If there is some way to accomplish that, for instance in the native API,
then we could revert to overlapped I/O.  If not, well...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: VM and non-blocking writes

[Corinna Vinschen]

On Dec 17 12:28, Lev Bishop wrote:
> On Dec 16, 2007 9:07 AM, Corinna Vinschen wrote:
> > On Dec 16 14:42, Corinna Vinschen wrote:
> > >   Lev, are you interested in reworking your patch (minus the pipe stuff)
> > >   to match current CVS?  Is there any gain in raising SO_SNDBUF/SO_RCVBUF
> > >   to a value > 8K, especially in the light of my experiences commented
> > >   on in net.cc, function fdsock()?
> >
> > Lev, do you have a copyright assignment in place?  I don't find you on
> > my list of signers.
> 
> No I don't have a copyright assignment in place yet. I will see what I
> can do about that -- don't think it will be a problem. I'd be
> interested in reworking the patch against current CVS (though I
> haven't looked to see how far current CVS has moved so I don't know
> how much that will involve). But I have to warn you in advance that I
> haven't had much time to work on this stuff, and I don't see that
> situation changing any time soon, so it may take multiple weeks before
> I get a chance [...]

It's not time critical.  The next major release will take some more
time anyway.  If you just could send the copyright assignment, it wou;d
be a good start.

> Having said all that, the winsock default 8kb really is far too small
> for many situations. I find that in my tests (this may be network
> hardware/driver dependent) I need 32kb for the stack to start
> coalescing packets reliably. Based on this, and on the problems
> described in your comments of net.cc fdsock() where the issue was with
> 64kb buffer size, it seems that 32kb would be a good size to use
> (again, it's possibly better to recommend the user to alter his
> registry setting to 32kb, rather than have cygwin force it through
> setsockopt()).

We could just check if the parameter is still set to 8K and only change
it to 32K if so.  Since that already happens at socket creation time,
it doesn't affect later settings in the application anyway, isn't it?

> Before getting too set on the plan of having cygwin break
> applications' send()s into chunks, maybe it's worth reconsidering the
> overall strategy. We're basically at this point implementing our best
> attempt at BSD semantics on top of microsoft's half-assed attempt at
> BSD semantics on top of the native not-BSD-like-at-all but powerful
> and quite self-consistent NT semantics. If we keep having to work
> around more issues like this, perhaps we'd be better off bypassing the
> afd layer entirely, by setting SO_SNDBUF to 0, using overlapped IO,
> and managing buffers ourselves. I'm sure this would bring it's own set
> of complications, but at least we'd be in a better position to deal
> with them, not having to go through the afd layer. What do you think?

Sorry, I'm unfamiliar with the native NT socket interface :} Is there
somewhere a (good) tutorial for the native NT socket stuff?  Even
without using the native API, we could also just set the Winsock
SO_RCVBUF/SO_SNDBUF settings to 0 and intercept the setsockopt/getsockopt
calls to maintain our own buffers, right?

Having said that, for a start I would prefer a simple "upgrade" along
the lines of your previous patch.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: mmap failing

[Wayne Christopher]

My test program is attached.  This example works but in my real program 
the same write+close+mmap sequence did not.


It appears that calling fsync before the close sometimes avoids the 
error but not always.


This is Cygwin 1.5.24(0.156/4/2).

Any thoughts?  Thanks,

   Wayne

Corinna Vinschen wrote:

On Dec 14 13:59, Wayne Christopher wrote:
  

I have a 268MB file open for writing.  I close it and then
immediately try to mmap() it, and a get ENOMEM.  However I do have the
VM space available and can malloc() the size of the file right after the 
failure.  Also, I have mmap()'ed other similar files in the same program 
before this, but these had not just been closed.


My initial guess was that it was timing related, but if I wait for 5
seconds and try again I still get the failure.

I wasn't able to duplicate it in a small example since my app has a bunch 
of threads and is doing other stuff at the same time.


Any suggestions for solutions or workarounds?



Not without testcase and version information.  Is that under 1.5.24-2
or 1.5.25-x?  Could you test if the result differs between these two
versions?  If so, how?


Corinna

  


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define SIZE 26800

main()
{
char* fname = "test_file";
char* data;
int fd, i;
struct stat sb;
caddr_t base;

data = malloc(SIZE);
fd = open(fname, O_RDWR|O_CREAT, 0666);
assert(fd >= 0);

i = write(fd, data, SIZE);
assert(i == SIZE);
close(fd);

i = stat(fname, &sb);
assert(i >= 0);

assert(SIZE == sb.st_size);

fd = open(fname, O_RDONLY, 0);
assert(fd >= 0);

base = (caddr_t) mmap(NULL, SIZE, PROT_READ, MAP_SHARED, fd, 0);
printf("base = %ld\n", (long) base);
if (MAP_FAILED == base)
	perror("mmap");

exit(0);
}

--
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: VM and non-blocking writes

[Lev Bishop]

On Dec 16, 2007 9:07 AM, Corinna Vinschen wrote:
> On Dec 16 14:42, Corinna Vinschen wrote:
> >   I'm contemplating the idea to workaround this problem in Cygwin (not
> >   for 1.5.25, but in the main trunk) by caping the number of bytes in a
> >   single send call, according to the patch Lev sent in
> >   http://www.cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html.
> >
> >   Lev, are you interested in reworking your patch (minus the pipe stuff)
> >   to match current CVS?  Is there any gain in raising SO_SNDBUF/SO_RCVBUF
> >   to a value > 8K, especially in the light of my experiences commented
> >   on in net.cc, function fdsock()?
>
> Lev, do you have a copyright assignment in place?  I don't find you on
> my list of signers.

No I don't have a copyright assignment in place yet. I will see what I
can do about that -- don't think it will be a problem. I'd be
interested in reworking the patch against current CVS (though I
haven't looked to see how far current CVS has moved so I don't know
how much that will involve). But I have to warn you in advance that I
haven't had much time to work on this stuff, and I don't see that
situation changing any time soon, so it may take multiple weeks before
I get a chance. (I'll have some time over christmas, but I'll be away
from all my network hardware and the openbsd box I originally used at
the other end of the wire for testing the patches, so testing would be
a problem). If you were hoping to get something into CVS on a more
rigorous timescale, better to push on without me -- I'll still try to
get a copyright assignment submitted, in case you wish to derive from
my original patches.

As far as changing SO_SNDBUF/SO_RCVBUF a few comments, which I
originally wrote in response to your patch in fdsock() but you had
already #ifdef'd out the patch by the time I wrote this, so I never
bothered to send it:

Your intention with the patch was to make cygwin's default buffer
sizes be more like on linux, but
1) On windows/cygwin (without my patch), the interpretation of
so_sndbuf is very different from linux. The afd layer will accept
*any* size of send, so long as the current buffer position is less
than so_sndbuf. Whereas on linux, so_sndbuf limits the total size of
the send buffer. This works nicely for transaction-oriented apps. For
an app which does it's side of a transaction in one large writev() and
then waits for the next request from the client (which will piggyback
the ack the server needs in order to empty it's send buffer), the send
buffer on windows is effectively infinite, for all values of so_sndbuf
except 0. So so_sndbuf cannot really be compared between windows and
linux, because the interpretation is totally different.
2) Linux includes all the overheads of it's skb structures, the part
of the buffer that's given to the application, etc, etc when it
accounts for the memory used by the send buffer, the result of which
is that you can only put about half as much data into the buffer as
there is memory allocated (linux internally doubles the number from
setsockopt(SO_SNDBUF) to hide this from applications expecting BSD
semantics, but it doesn't halve the number from getsockopt() a
longstanding point of controversy). The upshot of this is that the
cygwin default sendbuffer should better be *half* of the linux
tcp_wmem default, if you are going to go that way.
3) Linux does dynamic autotuning on the buffers, so the middle value
in tcp_wmem is more like a hint on what's a convenient chunk of memory
to allocate in one go, rather than a hint on what's actually the best
size for the buffer.
4) Your implementation ignored that some users may have actually
calculated optimal values for their situation and put them in the
relevant registry parameters. It seems it would be best either to:
only set so_{snd,rcv}buf in the case that the registry parameters are
absent; or don't touch so_{snd,rcv}buf at all and just advise users
experiencing problems that the registry parameters have the desired
effect. I'm inclined to go with the latter.


Having said all that, the winsock default 8kb really is far too small
for many situations. I find that in my tests (this may be network
hardware/driver dependent) I need 32kb for the stack to start
coalescing packets reliably. Based on this, and on the problems
described in your comments of net.cc fdsock() where the issue was with
64kb buffer size, it seems that 32kb would be a good size to use
(again, it's possibly better to recommend the user to alter his
registry setting to 32kb, rather than have cygwin force it through
setsockopt()).

Before getting too set on the plan of having cygwin break
applications' send()s into chunks, maybe it's worth reconsidering the
overall strategy. We're basically at this point implementing our best
attempt at BSD semantics on top of microsoft's half-assed attempt at
BSD semantics on top of the native not-BSD-like-at-all but powerful
and quite self-consistent NT semantics. If we keep having to work
aro

Re: [ANNOUNCEMENT] Updated: joe 3.5-2 -- Fast and simple editor which

[Jeff]

On Sun, 16 Dec 2007 01:17:12 +0200,
Jari Aalto  wrote:

>CHANGES SINCE LAST RELEASE
>==
>
>Removed termidx.exe. According to debian 2.8-16 changelog entry:
>"Since joe doesn't use termcap (but terminfo), termidx can be removed".

Uhm... From joe-3.5.tar.gz/joe-3.5/INSTALL:

=-=-=-=-=-=-=-=-=-=-=-
Installation procedure
=-=-=-=-=-=-=-=-=-=-=-

  To create a Cygwin binary distribution, use the 'cygbuild' script.

  JOE uses the GNU Automake and Autoconf suites to build itself.

  Run configure script, type one of these:

[...]

  For Cygwin, I've found that you need to add
  "--disable-curses --disable-termcap" to the above commands.

[...]

=-=-=-=-=-=-=-=-=-=-=-=-=-
Common ./configure options
=-=-=-=-=-=-=-=-=-=-=-=-=-

  To force JOE to use /etc/termcap file using its built-in termcap file parser
  (which is useful if you want to compile JOE so that it doesn't depend on any
  libraries other than libc and libm):

./configure --disable-curses --disable-termcap

  (--disable-termcap prevents JOE from using the termcap emulation functions
   in the -ltermcap library.  --disable-curses prevents JOE from using the
   termcap emulation functions in the -lcurses library).

  Otherwise, JOE tries to use the terminfo database via termcap
  emulation routines: see man tgetent, tgetstr, tgoto, etc.  (JOE has its
  own implementation of "curses", so curses is not required except to get
  access to the terminfo database).

   

In other words, when joe is built with the default options under Linux
(and most other POSIX-flavored OS's and environments), it uses
terminfo; when built for Cygwin, it is necessary to use options that
make it use termcap. So, while the comment in the Debian changelog
entry may be true for their distro of joe, it isn't true when joe is
built for Cygwin.

For other joe users who may not be familiar with it, termidx.exe is a
small utility that creates an index file for the termcap database. It
is not essential for joe to have this index in order to run. However,
joe uses it, if it is present, to help it parse the termcap database--
this translates into a quicker startup for joe. From the same INSTALL
file:

Termcap/Terminfo
=-=-=-=-=-=-=-=-

JOE prefers to use the termcap terminal capability database.  It
attempts to find this file in:

$HOME/.termcap  Personal .termcap in your home directory
/etc/joe/termcapJoe's termcap file
/etc/termcapNormal system termcap file

Joe copies its own termcap file to /usr/local/lib/termcap (or
wherever the system-wide joerc file is going to go) when 'make install' is
run.

Termcap is better than terminfo because it is a more open standard.
Programs can directly access the termcap database and future versions of
terminfo may require programs to use curses.  The only argument in
terminfo's favor is that it is faster than termcap.  To fix this problem,
JOE will use a termcap index file if it exists and if it is up to date.

This is the procedure to make the termcap index file:

make termidx
./termidx /etc/termcap.idx

   

termidx.exe is a small but helpful utility for joe. Joe users who are
familiar with joe, who have read the docs, make use of it. If you
remove it from the Cygwin joe distro, I will need to get and build the
sources just to have it (that, or I'll save my current copy so that it
is not removed). Please put it back in. Thanks,

Jeff

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

Intermittent perl crash

[Michael Kairys]

I apologize in advance for the scanty information here; I'm hoping someone 
can suggest how to narrow this down.


I've begun using Cygwin Perl regularly in the past few days (previously used 
only AS) and I'm finding fairly simple scripts crashing intermittently with 
this message:


3 [main] perl 4348 D:\Local\Cygwin\bin\perl.exe: *** fatal error - unable to 
remap

D:\Local\Cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Process\Process.dll
to same address as parent(0x26) != 0x37

The shell which launched the script will hang for several minutes, and then 
I will see:


   9 [main] perl 2092 child_info::sync: wait failed, pid 4348, Win32 
error 183
   265 [main] perl 2092 fork: child 4348 - died waiting for dll loading, 
errno 11


By "fairly simple" I mean ones I'm working on that at this point are only 
reading arguments and doing string operations. (Oh, and globbing an argument 
and doing "-f" tests on the results). I've tried trimming them down, etc., 
but the problem is intermittent and I can't get anything reproduceable.


Any hints welcome, and TIA.



--
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: Running dovecot under Cygwin

[Dave Korn]

On 17 December 2007 15:28, Ronny wrote:

>> I don't but you might be able to get some clues from looking at strace
>> output.
> 
> Well, i never used strace, so i do not know what it says me.
> I just give you the output.
> Could you have a look on it? Thanks a lot.


  What is /home/Administrator/test/new.exe ?

  I noticed a lot of exceptions during the parent-and-child post-spawn
synchronisation phase:

--- Process 1760, exception C135 at 7C974ED1

--- Process 568, exception C135 at 7C974ED1

--- Process 420, exception C135 at 7C974ED1

--- Process 280, exception C135 at 7C974ED1

--- Process 2036, exception C135 at 7C974ED1

--- Process 1760, exception C135 at 7C974ED1

--- Process 504, exception C135 at 7C974ED1


  That code stands for STATUS_DLL_NOT_FOUND.  Does 'new.exe', whatever it is,
require a dll to be in the PATH setting?  (Tip: use "cygcheck "
to see the list of dlls required by any .exe, along with a warning if any are
missing).

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: Running dovecot under Cygwin

[Christopher Faylor]

On Mon, Dec 17, 2007 at 03:08:47PM +0100, Ronny wrote:
> Hi,
>
> i am trying to get imap server "dovecot" running under cygwin.
>
> Compiling the server finished without any errors.
> But running the server does not work.
>
> As far as i can see, dovecot runs a master process, that uses execv to 
> launch a child (auth) process. The child process is killed immedeatly.
> This causes the whole server to shutdown.
>
> Does anybody have experience with running dovecot under cygwin?

I don't but you might be able to get some clues from looking at strace
output.  I'd be surprised if there wasn't some sort of verbose logging
available for dovecot as well.

cgf

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

Running dovecot under Cygwin

[Ronny]

Hi,

i am trying to get imap server "dovecot" running under cygwin.

Compiling the server finished without any errors.
But running the server does not work.

As far as i can see, dovecot runs a master process, that uses execv to 
launch a child (auth) process. The child process is killed immedeatly.

This causes the whole server to shutdown.

Does anybody have experience with running dovecot under cygwin?

uw-imap, that is distributed with cygwin does not match with my needs. I 
 am looking for an imap server taht supports virtual user using a user 
database.


Cheers
Ronny


--
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: making executable independent of cygwin with gcc

[Greg Chicares]

On 2007-12-17 10:23Z, Marko Loparic wrote:
> 
> Is there a way to create an executable from a C source that will run
> on windows without cygwin?

See the answer to
  "How do I compile a Win32 executable that doesn't use Cygwin?"
in the FAQ.

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

making executable independent of cygwin with gcc

[Marko Loparic]

Hi,

Is there a way to create an executable from a C source that will run
on windows without cygwin?

The gcc command I use is simply:

  gcc -I. -lm -g -o unit_comm $(objects)

The error I get when running the program in a windows system without cygwin is:

"This application has failed to start because cygwin1.dll was not
found. Re-installing the application may fix the problem."

Thanks a lot in advance!
Marko

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

[ANNOUNCEMENT] Updated: cygwin-1.5.25-7

[Corinna Vinschen]

I've put Cygwin 1.5.25-7 out of test.  This is now the new release
version.

Changes since version 1.5.25-5:

- Fix return value of poll().

- Fix file position in append mode for non-Cygwin processes.

- Fix missing definition of struct iovec when including sys/socket.h.

- tzset is now thread safe.

- Fix a problem with spurious memory allocation failure.

- Fix permission settings for directories on non-NTFS file systems.

- Fix NaN and +-inf handling in various math functions.

- Fix a problem with potentially wrong results in tgammaf().


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Save it and run setup, answer the questions, then look for
'cygwin' in the 'Base' category (it should already be selected).

If you have questions or comments, please send them to the Cygwin
mailing list.  See http://cygwin.com/lists.html for details.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Corinna Vinschen
Red Hat

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