Re: Fix performance on 10Gb networks
Maybe my analysis from some years ago can be relevant here? Another issue with delayed acks and winsock. I haven't been following cygwin for some time, so not sure exactly what the status is: https://cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html Lev -- Lev Bishop
Re: first cygwin 1.7 bash issue
On Sun, Oct 5, 2008 at 17:45, Cyrille Lefevre wrote: Your group is currently mkpasswd. This indicates that the /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group Note that the -d switch is necessary for domain users. the second one is ok ! any idea ? thanks in advance. Yes. The problem is that your group is currently mkpasswd. This indicates that the /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group In addition, please note that the -d switch is necessary for domain users. Lev -- 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.25(0.156/4/2): Problem compiling OpenLDAP 2.3.39 due to Win XP SP3 or Cygwin?
On Wed, Sep 10, 2008 at 14:51, Allan Schrum wrote: I created a small script to see if I could simplify the problem to something more easily debugged. Turns out the following script will cause problems that should not be caused which I believe lie at the heart of my problem compiling OpenLDAP. Run this in an empty directory somewhere: = begin script = #! /bin/bash let i=0 rm file* while [ $i -lt 2000 ] do touch file$i if [ ! -f file$i ] then echo missing file$i fi let i=i+1 done I strongly suspect BLODA. For example, Embassy Trusted Security has been known to cause this type of problem. I also see you have Sonic Solutions burning software installed... Lev -- 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: Bizarre Cygwin/Explorer/paths problem half-solved
On Fri, Aug 8, 2008 at 02:41, Luke Kendall wrote: Don't try this variant, though, since it doesn't work: explorer /e,$XPATH disown %- What happens if you try that innocuous-looking variant is that Cygwin (or bash?) normalises the path /e,... to a windows path first, producing \e,... Well, yes obviously. This is the difference between: On Mon, Aug 4, 2008 at 07:04, Lev Bishop wrote: On Mon, Aug 4, 2008 at 04:18, Luke Kendall wrote: $ explorer /e,\c:\temp\space dir\ $ # NBG^ $ explorer /e,C:\\temp\\space dir $ GOOD^ Lev -- 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: Bizarre Cygwin/Explorer/paths problem half-solved
On Fri, Aug 8, 2008 at 12:28, Christopher Faylor wrote: Is there any documentation on who rewrites arguments, under what conditions, and how they're altered? I missed this when it was first mentioned. Cygwin doesn't munge command line arguments. Why would it assume that /e,something was a windows path? That makes no sense. Nobody is munging anything. What's going on here is as simple as the difference: bash-3.2$ cmd /c echo a b c a b c bash-3.2$ cmd /c echo a b c a b c There's really no more to it than that. Lev -- 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: Bizarre Cygwin/Explorer/paths problem half-solved
On Fri, Aug 8, 2008 at 15:47, Tim McDaniel wrote:
On Fri, 8 Aug 2008, Christopher Faylor
[EMAIL PROTECTED] wrote:
On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote:
That's most unpleasant. I don't suppose there's any way to control
Cygwin's bash in re where to put double quotes around arguments
being passed to a Windows command (since getting Microsoft to make
explorer.exe be sane is hopeless)? Except by not using characters
that bash thinks need quoting.
I'd be very surprised if bash was doing anything different for
Windows than it does for linux. cygwin1.dll does do some quoting of
arguments to non-cygwin programs if it thinks it is required.
Well, *something* had to be adding the double-quotes. It's execve()
and such adding them, then?
Yes. Windows doesn't have an argv array. Windows programs just get a
single string for their command line from CreateProcess(). It's up to
them how they parse it. Cygwin execv() turns
argv[]={list,of,arguments with spaces or,not} into
lpCommandLine=list of \arguments with spaces or\ not.
Look in winf.cc linebuf::fromargv() . It's set up to work right for
the way cmd.exe parses command lines, with all it's stupid details.
But because each windows program gets to choose how to deal with
quoting and spaces, of course explorer.exe deals with them
differently.
Lev
--
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: Bizarre Cygwin/Explorer/paths problem half-solved
On Mon, Aug 4, 2008 at 04:18, Luke Kendall wrote: $ explorer /e,c:\\temp\\space\ dir $ # NBG^ $ explorer /e,c:\\temp $ # GOOD^ $ explorer c:\\temp\\space\ dir $ # GOOD^ (but no side pane) $ explorer /e,c:\temp\space dir $ # NBG^ $ explorer /e,\c:\temp\space dir\ $ # NBG^ $ explorer /e,C:\\temp\\space dir $ GOOD^ Lev -- 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
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:
quote
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.
/quote
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
around more
Re: VM and non-blocking writes
On Dec 14, 2007 8:52 AM, Corinna Vinschen wrote: On Dec 14 14:41, Corinna Vinschen wrote: On the other hand, as soon as I call send (or WSASendTo) multiple times with smaller sizes (I tried with 10k), select starts to block at one point. But even then strange things happen. After some time (after 5 seconds, then after 14 seconds, then about every 60 seconds) select() just signals the socket ready for write and the next send adds another 10K to the internal buffer. A tcpdump on the interface shows that no package goes over the line... which would be a surprise anyway, given that the peer does not even once call read(). Hmm, a few minutes ago select() mysteriously blocked fully after send has written 19 blocks of 10K each Good luck with figuring this stuff out. The way winsock deals with all of this stuff is rather mysterious and quite hackish, basically because it's all implemented in an emulation layer afd.sys and msafd.dll which tries to give bsd socket syntax (or something sorta close anyway) on top of the native overlapped io. The afd layer does some mighty weird things. See, for example, my reverse engineering of one aspect of it's send buffer management here: http://www.cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html There's a whole bunch of tuning parameters that deal with when afd should make a copy of an application-supplied buffer (incurring the copy costs) or just lock the application buffer in ram (incurring VM manipulation costs) and so on. Look at registry configuration parameters: DefaultReceiveWindow, DefaultSendWindow, FastCopyReceiveThreshold, FastSendDatagramThreshold, LargeBufferSize, LargeBufferListDepth, MaxFastTransmit, MaxFastCopyTransmit, MediumBufferSize, MediumBufferListDepth, OverheadChargeGranularity, PriorityBoost, SmallBufferListDepth, SmallBufferSize, TransmitIoLength, FFPControlFlags, FFPFastForwardingCacheSize, GlobalMaxTcpWindowSize and probably others. You can probably do something about this particular issue by tweaking those parameters, or making sure you make the sends fall on the right side of some boundary defined by those parameters. But in general I'm not confident. Lev Lev -- 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.25-5 is missing newlib math updates
On Dec 11, 2007 8:06 AM, Corinna Vinschen wrote: Thanks for the patches. I applied them to the 1.5.x branch. Barring any further catastrophies in 1.5.25, I will release a new 1.5.25 within a couple of days. While you're at it... http://sourceware.org/ml/newlib/2007/msg00912.html http://cygwin.com/ml/cygwin/2007-10/msg00252.html 2007-09-04 Kazunori Asayama [EMAIL PROTECTED] * libm/math/wf_tgamma.c: Add missing include. === RCS file: /cvs/src/src/newlib/libm/math/wf_tgamma.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- src/newlib/libm/math/wf_tgamma.c2002/06/07 21:59:56 1.1 +++ src/newlib/libm/math/wf_tgamma.c2007/09/04 17:33:10 1.2 @@ -14,6 +14,7 @@ */ #include math.h +#include fdlibm.h #ifdef __STDC__ float tgammaf(float x) -- 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: kill -STOP mencoder_pid does not stop process execution
On Dec 11, 2007 10:18 AM, TAJTHY Tamás wrote: Dear List, sometimes I have to pause the execution of the mencoder process on my cygwin hosted by an XP SP2. If I press Ctrl+S the mencoder is stopped nicely. I wanted to pause it from a script. I tried the normal UNIX way sending a SIGSTOP signal to the process (kill -STOP mencoder_PID) from an other bash window. Running ps I could see it had S status, but mencoder was still writing to stdout and the CPU usage was still nearly 100%. I even tried kill -TSTP mencoder_PID, but the same result. I think this is because of this longstanding cygwin issue: http://cygwin.com/ml/cygwin-patches/2003-q4/msg00055.html Which I think may also be the reason why it usually makes my console unusable if I try to use ^Z to suspend, eg, $ yes | less (Although I haven't looked at this stuff in ages, so maybe I don't know what I'm talking about -- I'm sure CGF will pipe up if I'm completely wrong). Lev -- 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 stable and cvs snapshot - fork() bug
On 11/5/07, Corinna Vinschen wrote:
On Nov 1 10:58, Corinna Vinschen wrote:
On Oct 31 14:26, Lev Bishop wrote:
$ cat lev.c gcc -o lev lev.c -Wall -Wextra CYGWIN=server ./lev
#include stdio.h
#include unistd.h
#include sys/shm.h
int main(void)
{
int shmid;
if ((shmid = shmget(IPC_PRIVATE, 100,IPC_CREAT | 0600 )) 0 ||
!shmat(shmid, NULL, 0) ||
shmctl(shmid, IPC_RMID, NULL) 0)
puts(problems with shm!);
fork();
}
lev.c: In function `main':
lev.c:13: warning: control reaches end of non-void function
3 [main] lev 1924 c:\Documents and
Settings\Lev\Desktop\mpd-0.13.0\lev.exe: *** fatal error -
MapViewOfFileEx (0x3E), Win32 error 6. Terminating.
124 [main] lev 5076 fork: child 1924 - died waiting for dll
loading, errno 11
Thanks for the testcase. I'm surprised that nobody experienced this
problem before. Sorta holiday here, so I'll look into it next week.
Ouch, ouch, ouch. shmctl(IPC_RMID) closed the handle to the shared
memory, but neglected to remove the actual mappings as well as the
bookkeeping structure. The result is that after a fork the child thinks
there are still mappings which have to be duplicated into its own
memory. But the handle has already been closed in the parent, so the
MapViewOfFile call fails with invalid handle.
Unfortunately not many applications use shmctl(IPC_RMID) before creating
a child process since usually the shared memory is meant to be... well,
shared. That's why this didn't crop up more often, obviously.
Are you sure that you're interpreting IPC_RMID correctly? My
understanding is that you can still share the memory until you
actually remove the mapping. (Sort of like how you can unlink() a temp
file immediately after you open it, and continue to use it). I assumed
this was the reason for the create-map-remove pattern used by mpd.
From the linux man page:
IPC_RMIDMark the segment to be destroyed. The segment will only
actually be destroyed after the last process detaches it
(i.e., when the shm_nattch member of the associated strucâ
ture shmid_ds is zero). The caller must be the owner or
creator, or be privileged. If a segment has been marked
for destruction, then the (non-standard) SHM_DEST flag of
the shm_perm.mode field in the associated data structure
retrieved by IPC_STAT will be set.
Lev
--
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 stable and cvs snapshot - fork() bug
On 11/5/07, Lev Bishop wrote:
On 11/5/07, Corinna Vinschen wrote:
On Nov 1 10:58, Corinna Vinschen wrote:
On Oct 31 14:26, Lev Bishop wrote:
$ cat lev.c gcc -o lev lev.c -Wall -Wextra CYGWIN=server ./lev
#include stdio.h
#include unistd.h
#include sys/shm.h
int main(void)
{
int shmid;
if ((shmid = shmget(IPC_PRIVATE, 100,IPC_CREAT | 0600 )) 0 ||
!shmat(shmid, NULL, 0) ||
shmctl(shmid, IPC_RMID, NULL) 0)
puts(problems with shm!);
fork();
}
lev.c: In function `main':
lev.c:13: warning: control reaches end of non-void function
3 [main] lev 1924 c:\Documents and
Settings\Lev\Desktop\mpd-0.13.0\lev.exe: *** fatal error -
MapViewOfFileEx (0x3E), Win32 error 6. Terminating.
124 [main] lev 5076 fork: child 1924 - died waiting for dll
loading, errno 11
Thanks for the testcase. I'm surprised that nobody experienced this
problem before. Sorta holiday here, so I'll look into it next week.
Ouch, ouch, ouch. shmctl(IPC_RMID) closed the handle to the shared
memory, but neglected to remove the actual mappings as well as the
bookkeeping structure. The result is that after a fork the child thinks
there are still mappings which have to be duplicated into its own
memory. But the handle has already been closed in the parent, so the
MapViewOfFile call fails with invalid handle.
Unfortunately not many applications use shmctl(IPC_RMID) before creating
a child process since usually the shared memory is meant to be... well,
shared. That's why this didn't crop up more often, obviously.
Are you sure that you're interpreting IPC_RMID correctly? My
understanding is that you can still share the memory until you
actually remove the mapping. (Sort of like how you can unlink() a temp
file immediately after you open it, and continue to use it). I assumed
this was the reason for the create-map-remove pattern used by mpd.
From the linux man page:
IPC_RMIDMark the segment to be destroyed. The segment will only
actually be destroyed after the last process detaches it
(i.e., when the shm_nattch member of the associated strucâ
ture shmid_ds is zero). The caller must be the owner or
creator, or be privileged. If a segment has been marked
for destruction, then the (non-standard) SHM_DEST flag of
the shm_perm.mode field in the associated data structure
retrieved by IPC_STAT will be set.
It indeed seems this is behaviour not described in SuSv3. But several
unices support (some variant of) this behaviour. At least linux,
freebsd, hp-ux, solaris 10 mention it in their man pages, and openbsd
and netbsd seem to implement it that way even though they don't
describe it in the man pages.
FreeBSD:
IPC_RMID Removes the segment from the system. The removal will not
take effect until all processes having attached the segment
have exited; however, once the IPC_RMID operation has taken
place, no further processes will be allowed to attach the
segment. For the operation to succeed, the calling
process's effective uid must match shm_perm.uid or
shm_perm.cuid, or the process must have superuser privi-
leges.
HP-UX:
IPC_RMID
Remove the shared memory identifier specified by shmid from the system
and destroy the shared memory segment and data structure associated
with it. If the segment is attached to one or more processes, then the
segment key is changed to IPC_PRIVATE and the segment is marked
removed. The segment disappears when the last attached process
detaches it. This cmd can only be executed by a process that has an
effective user ID equal to either that of a user with appropriate
privileges or to the value of either shm_perm.uid or shm_perm.cuid in
the data structure associated with shmid.
Solaris 10:
IPC_RMID
Remove the shared memory identifier specified by shmid from the
system. The segment referenced by the identifier will be destroyed
when all processes with the segment attached have either detached the
segment or exited. If the segment is not attached to any process when
IPC_RMID is invoked, it will be destroyed immediately. This command
can be executed only by a process that has appropriate privileges or
an effective user ID equal to the value of shm_perm.cuid or
shm_perm.uid in the data structure associated with shmid.
A further linux extension: In addition to all the above, Linux goes
even further and still allows you to attach the segment even after
marking it for deletion. Linux man page:
Linux permits a process to attach (shmat()) a shared memory segment
that has already been marked
Re: cygwin stable and cvs snapshot - fork() bug
On 11/1/07, Corinna Vinschen wrote: ... Thanks for the testcase. I'm surprised that nobody experienced this problem before. Sorta holiday here, so I'll look into it next week. Well, there was: http://sourceware.org/ml/cygwin/2006-02/msg00824.html which I am pretty sure was this same issue :-) There were also some others eg gnome programs such as mahjongg http://cygwin.com/ml/cygwin/2004-06/msg00041.html which could have been the same issue. I didn't investigate deep enough to determine. Have a nice sorta holiday. Lev -- 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 stable and cvs snapshot - fork() bug
On 10/31/07, michael.vogt wrote:
1 [main] mpd 1736 C:\cygwin\home\mpx\mpd-test\mpd.exe:
*** fatal error - MapViewOfFileEx (0x1903),
Win3 2 error 6. Terminating.
68 [main] mpd 676 fork: child 1736 - died
waiting for dll loading, errno 11 problems fork'ing for
daemon!
[...]
any news regarding this issue?
If you want anything like this to be looked at faster, the best thing
you can do is http://www.cygwin.com/acronyms/#PPAST. Apparently the
cygwin developers have not so far been interested to download mpd,
make unspecified changes to the mpd sources to get them to compile
(the changes you listed on the bug report were not sufficient), and
then setup the configuration files for mpd, figure out what mpd is
supposed to do, and THEN debug the problem.
Here is the STC you neglected to supply:
$ cat lev.c gcc -o lev lev.c -Wall -Wextra CYGWIN=server ./lev
#include stdio.h
#include unistd.h
#include sys/shm.h
int main(void)
{
int shmid;
if ((shmid = shmget(IPC_PRIVATE, 100,IPC_CREAT | 0600 )) 0 ||
!shmat(shmid, NULL, 0) ||
shmctl(shmid, IPC_RMID, NULL) 0)
puts(problems with shm!);
fork();
}
lev.c: In function `main':
lev.c:13: warning: control reaches end of non-void function
3 [main] lev 1924 c:\Documents and
Settings\Lev\Desktop\mpd-0.13.0\lev.exe: *** fatal error -
MapViewOfFileEx (0x3E), Win32 error 6. Terminating.
124 [main] lev 5076 fork: child 1924 - died waiting for dll
loading, errno 11
Lev
--
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: A problem with tgamma function
On 10/12/07, Angelo Graziosi wrote: Lev Bishop wrote: I'm sure glibc and newlib would both appreciate a good algorithm for tgamma(), if you felt like submitting one... It seems that a good algorithm has yet been coded in the GAMMA implementation of CERNLIB (http://wwwasdoc.web.cern.ch/wwwasdoc/shortwrupsdir/c302/top.html, http://cernlib.web.cern.ch/cernlib/download/2006_source/src/mathlib/gen/c/gamma64.F), because with that implementation the test I posted passes... One immediately obvious problem with that implementation is that it doesn't handle negative parameter. Lev -- 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: A problem with tgamma function
On 10/11/07, Angelo Graziosi wrote: That is a bug report against glibc. You cannot draw any inferences between that and newlib/Cygwin because they are totally separate and unrelated code bases. Technically, when it comes to maths, both lean very heavily on fdlibm, so they really aren't unrelated codebases. That would be expected given Lev's indication of a fix in newlib What I wished to stress was that the 'tgamma' function of newlib gives the same results of the glibc-tgamma, for which a bug report has been sent. And this regardless the Lev's indication of a fix in newlib. There are two completely different problems. The newlib segfault problem was due to a missing include file, causing a missing prototype for __iee754_gammaf_r(), causing C's default type rules to infer a type of double for the first parameter to __ieee754_gammaf_r() instead of float, in turn causing the write intended for signgam to instead hit a random location and segfault/coredump. This problem is fixed in CVS. As a second issue, the glibc implementation of tgammaf() is accurate to worse than 10^-6 although the glibc documentation claims it should be 1ulp (about 10^-7). This is because __ieee754_gammaf_r(x) is implemented as __ieee754_expf (__ieee754_lgammaf_r (x)) (with an XXX FIXME comment). Newlib does exactly the same thing (minus the coment). The trouble with this is that you lose some accuracy. The error can be as large as log(tgamma(x)) ulps, which in the worst case (log(FLT_MAX)) is about 89 ulps. Actually, in practice the error doesn't seem to be quite as bad -- the worst I've seen is about 64 ulps -- but it's still not as accurate as you'd like. I'm sure glibc and newlib would both appreciate a good algorithm for tgamma(), if you felt like submitting one... Lev -- 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: A problem wit tgamma function
On 10/10/07, Angelo Graziosi wrote to the cygwin mailing list:
For the sake of completeness I want to flag this.
A recent failure of GFortran tests, regarding the usage of GAMMA
functions, results in the following problem with 'tgamma' on Cygwin
(gcc-3.4.4-3):
SNIP simple testcase
Even simpler testcase:
$ cat t.c gcc t.c -o t ./t
#include math.h
int main() {tgammaf(1.);}
Segmentation fault (core dumped)
I believe this is fixed in newlib CVS.
See: http://sourceware.org/ml/newlib/2007/msg00912.html
Lev
--
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.24: sin() bug
On 8/29/07, Dmitry Karasik wrote: I'd like to submit a bug in cygwin implementation of sin(). snip the difference is in 7th digit, and is significant for double precision. This is not a bug in newlib. The problem is in glibc and msvc and newlib is (more) correct in this case. Or, to put it another way, the problem is that the 8087 was designed a few years before the proper theory for doing argument reduction for trig functions was discovered, and most subsequent x86 compatible processors (except for the AMD K5) have decided to be bug-compatible with the original 8087. If you would do your experiment on another architecture (PowerPC, IA64, x86-64 (assuming glibc built using the default -msse -mfpmath=sse compiler options) etc) you would get the same result as from newlib. The C specifications don't require exact argument reduction, and so many implementations just return whatever the underlying hardware implements. This is in opposition to, say, Java, where the FP rules are more precise. See: http://blogs.sun.com/jag/entry/transcendental_meditation Analysis of your testcase: Closest IEEE-754 double to 3.1415926535897900074 is indeed 0x1.921fb54442d11p+1 (as correctly given by gcc on both cygwin and linux). Sin(0x1.921fb54442d11) is according to Mathematica: 0x1.d1a62633145c06e0e690...p-49 the closest IEEE-754 double to this (round-to-even) is 0x1.d1a62633145c0p-49 as given by newlib. So, in this case, newlib is getting it right to less than 0.5ulp (better than 1ulp is all that is usually possible, due to the table-maker's dilemma). The info file for glibc (errors in math functions node) claims that on ix86 sincos() should be accurate to 1 ulp (it doesn't give an error for sin() alone, but I reworked your test program to use sincos() and it didn't change the answer). But in this case, glibc is off by 0x2633145c0 ulps (about 10^10 ulps). Lev -- 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: [ANNOUNCEMENT] New package: brltty 3.8
On 7/3/07, Samuel Thibault wrote: Corinna Vinschen, le Tue 03 Jul 2007 09:54:24 +0200, a écrit : For using local named pipes you don't need winsock anyway, and for remote connections you should use Cygwin sockets. And mixing both is quite difficult. Anyhow, I'll only enable cygwin sockets and hope the latency is sufficient for users. I still feel that if you had latency problems using TCP it was either a bug in your program, or a bug in your protocol (you are the author of the protocol, right?), or a bug in cygwin. Is there a way I can investigate this without needing special braille hardware (like, is there some kind of dummy driver that sends the braille to the console or something). Or, do you have a simplified testcase that exhibits this latency you are concerned about? Lev -- 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: Socket inheritance with fork/dup2/exec
On 6/22/07, Corinna Vinschen wrote: However, the next version of Cygwin will use standard DuplicateHandle calls as for normal file handles. Consequentially your your test application appears to work with a Cygwin built from CVS: But MSDN says: You should not use DuplicateHandle to duplicate handles to the following objects: * I/O completion ports. No error is returned, but the duplicate handle cannot be used. * Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function. -- 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: Socket inheritance with fork/dup2/exec
On 6/21/07, Brian Dessent wrote: Jim Powers wrote: I am redirecting the stdout of a child process to a socket via the standard fork/dup2/exec paradigm and then reading and displaying the output. This works fine if the exec'd child process is compiled using gcc under cygwin. However, it fails with an Invalid file handle error when compiled using VC8 under windows. I've included both the parent and child code below. I'm fairly sure this isn't supposed to work. Unix domain sockets (AF_UNIX/AF_LOCAL) don't actually exist in any Windows API so Cygwin emulates them with an underlying AF_INET socket. So when your MSVCRT program tries to WriteFile to a socket it fails, because you have to use the Winsock API for that. In short, Windows is not unix, and handles aren't fds. Actually, in windows API you can WriteFile() to a socket (as an optional feature, but the default socket provider supports it). The problem here is that cygwin opens the underlying socket in overlapped mode, and the windows API requires treating overlapped handles differently than non-overlapped. If you'll always be using the same child, that you have full control over, then you can write the child to use overlapped semantics. But if you want to be able to pass the socket to an arbitrary child process then you're out of luck, because the windows API provides no way for the child to discover that it needs to use overlapped semantics, forcing the child to attempt non-overlapped semantics and fail. I once wrote a patch to cygwin in an attempt to get around this. It mostly worked, but windows API calls that were not documented to be able to block (eg setsockopt()) started blocking on non-overlapped sockets. Don't you just love the windows API? See: http://cygwin.com/ml/cygwin-patches/2006-q2/msg00039.html You can probably make this work if you use pipe() instead of a socketpair() as that maps directly onto a Windows anonymous pipe, which is a file handle that can be written to. You could also use a named pipe, which is the closest Windows has to a unix domain socket, but there is no corresponding POSIX api for that and so you'd be breaking abstraction as you'd have to deal with raw Win32 APIs in your POSIX parent app, which is ugly (and not how Cygwin was designed to work either.) Actually, pipe() is implemented in cygwin using win32 named pipes, not anonymous pipes, as I recall. But, you are right that using pipe() should solve this particular problem. Lev -- 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: [ANNOUNCEMENT] New package: brltty 3.8
On 6/7/07, Christopher Faylor wrote:
On Thu, Jun 07, 2007 at 07:49:50PM +0800, Samuel Thibault wrote:
snip
But when talking about communicating with other applications, we need to
use windows interfaces when the linux API doesn't permit it, shouldn't
we?
Only if you can clearly communicate why the linux API doesn't work. I'm
not convinced that this is not just a misconception on your part.
Or to put it another way -- cygwin is rather careful when it comes to
pipes to make sure that all of these uses work correctly and
interoperate with with windows:
C:\dir | less
C:\ls | less
C:\dir | \windows\system32\more.com
C:\ls | \windows\system32\more.com
$ cmd /c dir | les
$ ls | less
$ cmd /c dir | /cygdrive/c/windows/system32/more.com
$ cmd /c dir | /cygdrive/c/windows/system32/more.com
(ie all 8 combinations of pipe-created-by:{win,cygwin},
source:{win,cygwin}, sink:{win,cygwin} )
So, the big question is: what does brltty do with pipes that is
different to the above?
I know there are certain potential problems with non-blocking I/O on
pipes on cygwin, but they are limited to quite specific cases (rsync
is the main one that trips over this).
Lev
--
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: [ANNOUNCEMENT] New package: brltty 3.8
On 6/7/07, Samuel Thibault wrote: Christopher Faylor, le Thu 07 Jun 2007 12:37:44 -0400, a écrit : On Fri, Jun 08, 2007 at 12:08:59AM +0800, Samuel Thibault wrote: To the best of my knowledge, there is no unixish way in cygwin to access these pipes, so we just used CreateNamedPipe(). So don't use named pipes. What instead? Just TCP/IP? (it's quite sluggish). Maybe TCP/IP is not the most efficient way to send data to the local machine, but nevertheless, we're talking about sending (braille) text here aren't we? A cygwin loopback ttcp connexion on my laptop gets... bash-3.2$ ttcp -fM -sr ttcp -fM -n8 -st 127.0.0.1 [1] 3000 ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket ttcp-t: buflen=8192, nbuf=8, align=16384/0, port=5001 tcp - 127.0.0.1 ttcp-t: socket ttcp-r: accept from 127.0.0.1 ttcp-t: connect ttcp-t: 65536 bytes in 8.00 real seconds = 78.12 MB/sec +++ ttcp-t: 8 I/O calls, msec/call = 0.10, calls/sec = 1.00 ttcp-t: 0.6user 5.6sys 0:08real 78% ttcp-r: 65536 bytes in 8.00 real seconds = 78.12 MB/sec +++ ttcp-r: 86662 I/O calls, msec/call = 0.09, calls/sec = 10832.75 ttcp-r: 0.8user 3.1sys 0:08real 49% bash-3.2$ [1]+ Donettcp -fM -sr ...around 80MByte/sec, which maybe isn't as fast as it could be using native functionality, but surely brltty doesn't need *that* much bandwidth for transferring text? Lev -- 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: [ANNOUNCEMENT] New package: brltty 3.8
On 6/7/07, Samuel Thibault wrote: Lev Bishop, le Thu 07 Jun 2007 13:41:44 -0400, a écrit : ...around 80MByte/sec, which maybe isn't as fast as it could be using native functionality, but surely brltty doesn't need *that* much bandwidth for transferring text? It doesn't need bandwidth, it needs latency. Latency is... bash-3.2$ ./socat TCP-LISTEN:5001 PIPE exec 99/dev/tcp/127.0.0.1/5001 ; time for (( a=0; a1000; a++ )); do echo $a 99; read 99; done; exec 99- [1] 4492 real0m1.959s user0m0.062s sys 0m0.172s bash-3.2$ [1]+ Done./socat TCP-LISTEN:5001 PIPE ...about 2ms round-trip. How is this a problem? Lev -- 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: [ANNOUNCEMENT] New package: brltty 3.8
On 6/7/07, Samuel Thibault wrote: Lev Bishop, le Thu 07 Jun 2007 14:39:17 -0400, a écrit : ...about 2ms round-trip. How is this a problem? This adds up to the screen reader latency, etc. Really, we tried both, and while tcp/ip was a bit painful, local sockets were smooth. Sorry, but I don't believe that anybody, blind or not, can perceive a 2ms lag. If it seemed painful using tcp/ip then it must have been due to some other reason than latency. Lev -- 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.24: shell commands randomly skipped
On 6/1/07, Nicolas Joyard [EMAIL PROTECTED] wrote: Hello I'm having a really weird issue with the last versions of Cygwin, I started seeing it with 1.5.21 (I didn't use every previous version, though, but it was not happening with 1.5.10) and it is still there with 1.5.24. ... I don't know where to look to find more information about this problem. Has anyone already seen it, or is there something else I could do to find out more ? This is the part where we ask you to uninstall all the invasive hooking type software you might have on your machine, such as firewalls, on-access virus scanners, content indexers, etc. Basically anything that might have to hook into the network stack or that might want to get involved every time a file is accessed. Also logitech webcam software for some bizarre reason, and all the other stuff on DaveK's list of nasty software. I seem to remember problems just like yours being caused by certain versions of Embassy Trusted Security or whatever it's called. You have to uninstall these programs - merely disabling them isn't enough to remove their hooks. Lev -- 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: How to uniformly point to the root of a drive?
On 5/23/07, Corinna Vinschen [EMAIL PROTECTED] wrote: On May 21 18:45, Corinna Vinschen wrote: On May 21 11:55, Lev Bishop wrote: On 5/21/07, Corinna Vinschen [EMAIL PROTECTED] wrote: Actually it seems to be better to disallow only combinations which explicitely don't make sense, but to allow any combination which make *some* sort of sense. The rules would be, afaics - Don't allow -d with -l. - Allow any other mix of -d, -l, -m and -w. - Don't allow -u with any of the above flags. Did I miss one? What about -s? http://cygwin.com/ml/cygwin/2007-05/msg00525.html As i hinted in my previous message, the flags handling in cygpath is inconsistent. [...] Right, I noticed most of your observations when looking into the source code. I'm going to rewrite the option handling to be consistent. Sorta. Most of the time at least. Stay tuned. Done. The rules have changed slightly, but should be consistent now. The option handling when reading from files (-o -f ...) is now identical to the option handling from the the command line, except that the -o and -f options are invalid when reading from a file. Now, one can't do, eg, cygpath -w -S to get the system directory in windows format (or even cygpath -u -S to explicitly ask for it in unix form. Previously these worked. Is that intentional? cygpath -f seems to ignore commandline options, eg to convert to windows format: $ cygpath -w -f - /usr/bin/bash /usr/bin/bash cygpath -of seems to default to windows format rather than unix format, except for system directory options: $ /bin/echo -e /usr/bin/bash\n-P | cygpath -of - C:\cygwin\bin\bash /cygdrive/c/Documents and Settings/Lev/Start Menu/Programs Lev -- 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: How to uniformly point to the root of a drive?
On 5/23/07, Lev Bishop [EMAIL PROTECTED] wrote: On 5/23/07, Corinna Vinschen [EMAIL PROTECTED] wrote: Done. The rules have changed slightly, but should be consistent now. The option handling when reading from files (-o -f ...) is now identical to the option handling from the the command line, except that the -o and -f options are invalid when reading from a file. Now, one can't do, eg, cygpath -w -S to get the system directory in windows format (or even cygpath -u -S to explicitly ask for it in unix form. Previously these worked. Is that intentional? cygpath -f seems to ignore commandline options, eg to convert to windows format: $ cygpath -w -f - /usr/bin/bash /usr/bin/bash cygpath -of seems to default to windows format rather than unix format, except for system directory options: $ /bin/echo -e /usr/bin/bash\n-P | cygpath -of - C:\cygwin\bin\bash /cygdrive/c/Documents and Settings/Lev/Start Menu/Programs Also, why do you have it so that -s is not just a synonym for -d, and why doesn't -l force -w? There seems to be no advantage to forcing the user to specify an additional flag. Lev -- 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: How to uniformly point to the root of a drive?
On 5/23/07, Matthew Woehlke [EMAIL PROTECTED] wrote: Lev Bishop wrote: Also, why do you have it so that -s is not just a synonym for -d, and why doesn't -l force -w? There seems to be no advantage to forcing the user to specify an additional flag. ...as I previously noted, '-us' is a reasonable combination of flags, thus '-ul' is also reasonable. I did suggest that '-l' should /imply/ '-w' unless '-u' is used. Well, currently it treats -us or -ul or plain -l or plain -s all as errors and gives the usage message. -- 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: How to uniformly point to the root of a drive?
On 5/21/07, Corinna Vinschen [EMAIL PROTECTED] wrote: On May 21 15:46, Dave Korn wrote: On 21 May 2007 15:30, Corinna Vinschen wrote: so we can change cygcheck to handle this unambiguously. cygpath. Right. Unfortunately I just found that -m is sometimes used as a modifier (-dm makes sense) and sometimes standalone (-m instead of -w). Actually it seems to be better to disallow only combinations which explicitely don't make sense, but to allow any combination which make *some* sort of sense. The rules would be, afaics - Don't allow -d with -l. - Allow any other mix of -d, -l, -m and -w. - Don't allow -u with any of the above flags. Did I miss one? What about -s? As i hinted in my previous message, the flags handling in cygpath is inconsistent. For example: *) -t mixed and -m are treated differently wrt the system options. *) You can have -l and -s in effect at the same time (which literally means convert to a short path and then convert back to a long path -- maybe this is useful, eg it does filename case normalization, and checks to see if the file exists, but it seems odd) *) Options read from a file with -o are processed differently to options on the commandline (for example, in that case the most recent of -s and -l takes precedence, rather than both in effect at once.) Also, in case you missed it some other bug causes -l with a nonexistent file to five a corrupted output Lev -- 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: How to uniformly point to the root of a drive?
On 5/20/07, Karl M wrote: Hi All... From: Christopher Faylor Subject: Re: How to uniformly point to the root of a drive? Date: Sun, 20 May 2007 13:36:16 -0400 On Sun, May 20, 2007 at 01:27:05PM -0400, Christopher Faylor wrote: So it sounds like Brian's method would work then wouldn't it? Does this give you what you want, too? driveroot=$(cygpath $(cygpath -wm /)/..) What is the difference between cygpath -m ... and cygpath -wm ... That's easy: they're exactly the same. Now for some tricky ones: 1)what does: cygpath -lpw '/bin/nonexistant:/usr/bin' do? 2)what's the difference between cygpath -m ... and cygpath -t mixed ...? 3)what's the difference between: cygpath - -t mixed -t mixed -t unix -t mixed -mmm ... and cygpath -m ... Answers follow: Answers 1) $ cygpath -lpw '/bin/nonexistant:/usr/bin' ÷;C:\cygwin\bin ^ That's a divided-by symbol there. Some lack of error checking somewhere, I suppose. 2) $ cygpath -t mixed .. cygpath -t mixed -D C:/cygwin/home/ /cygdrive/c/Documents and Settings/Lev/Desktop $ cygpath -m .. cygpath -m -D C:/cygwin/home/ C:/Documents and Settings/Lev/Desktop Ie, they're the same for usual paths, but '-t mixed' gives a unix path for the system information options 3) none -- 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: newlib?: pow function can produce incorrect results.
On 5/2/07, Cary R. wrote:
Other potentially controversial special cases (may or may not be
handled correctly by newlib -- I didn't check) are:
atan2(+-0,-0)=+-pi
atan2(+-0,+0)=+-0
newlib and my version of glibc return +0 for all these cases.
Hmm *my* version of glibc gets all 4 cases right:
[EMAIL PROTECTED]:~ cat atan2.c
#include stdio.h
#include math.h
int main()
{
double zero, mzero;
zero = 0.0;
mzero= -1.0*0;
printf(Using +0=%f -0=%f\n,zero,mzero);
printf(atan2(+0,+0)=%f\n,atan2(zero,zero));
printf(atan2(-0,+0)=%f\n,atan2(mzero,zero));
printf(atan2(+0,-0)=%f\n,atan2(zero,mzero));
printf(atan2(-0,-0)=%f\n,atan2(mzero,mzero));
return 0;
}
[EMAIL PROTECTED]:~ gcc -Wall -fno-builtin atan2.c -lm ./a.out
Using +0=0.00 -0=-0.00
atan2(+0,+0)=0.00
atan2(-0,+0)=-0.00
atan2(+0,-0)=3.141593
atan2(-0,-0)=-3.141593
[EMAIL PROTECTED]:~ /lib/libc.so.6
GNU C Library development release version 2.4 (20060526), by Roland
McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 4.1.0 (SUSE Linux).
Compiled on a Linux 2.6.16 system on 2006-05-26.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
GNU libio by Per Bothner
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
NoVersion patch for broken glibc 2.0 binaries
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.
[EMAIL PROTECTED]:~ uname -a
Linux cmt 2.6.16.21-0.25-smp #1 SMP Tue Sep 19 07:26:15 UTC 2006 i686
i686 i386 GNU/Linux
Newlib gets it wrong and puts out +0 in all cases, as you said, but
interestingly gcc -mno-cygwin gets all cases correct (although you
have to work a bit harder to prove that because mingw's printf()
doesn't distinguish +0 and -0 in it's output).
Lev
--
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: newlib?: pow function can produce incorrect results.
On 5/1/07, Cary R. wrote: Patch generated and applied to newlib CVS. As an added bonus I fixed a few other inconsistencies in acos(), asin(), log() and log10(). Just for the benefit of anyone else investigating this kind of thing in the future, because I got confused by it and had to do some searching, the pow(x,0)=1, even for x=NaN and pow(-1,+-inf)=1 rules are cases where the (freely available) earlier public drafts of C99 differ from the final version of the standard (which you have to purchase). This has confused other projects also, see eg: http://lists.debian.org/debian-glibc/2003/03/msg00223.html Other potentially controversial special cases (may or may not be handled correctly by newlib -- I didn't check) are: atan2(+-0,-0)=+-pi atan2(+-0,+0)=+-0 hypot(+-inf,y)=+inf, even for y=NaN fmax(x,NaN)=fmax(NaN,x)=fmin(x,NaN)=fmin(NaN,x)=x -- 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: [Ping Python maintainer]: enhancement request
On 5/1/07, Christopher Faylor wrote: On Tue, May 01, 2007 at 08:06:23AM -0400, Jason Tishler wrote: OK. Should I copy or make a hard link? Before you do this, I have a question. Why is this important now when you've apparently been doing this for many years? This isn't the only package which makes symlinks to executables. And, since, AFAIK, setup.exe doesn't understand hard links it means that you really do have to make a copy. If you make a copy you stand the chance of having python.exe out of sync with the thing that it is supposed to be pointing to. You could avoid that particular problem by making a hardlink in a postinstall script, right? Lev -- 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: newlib?: pow function can produce incorrect results.
On 4/23/07, Cary R. wrote: I had some more time to look into this and when the simple C program I mentioned earlier uses variables like the other program, incorrect results are produced. I have attached this C/C++ program. I certainly don't understand what is going on. I would have expected pow to be pass-by value which should make the two calls identical from a system standpoint, but the results imply something different. Any suggestions would be greatly appreciated. $ gcc -fno-builtin ./pow-error.c -- 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: newlib?: pow function can produce incorrect results.
On 4/23/07, Dave Korn wrote: On 24 April 2007 00:53, Cary R. wrote: I had some more time to look into this and when the simple C program I mentioned earlier uses variables like the other program, incorrect results are produced. I have attached this C/C++ program. I certainly don't understand what is going on. I would have expected pow to be pass-by value which should make the two calls identical from a system standpoint, but the results imply something different. Any suggestions would be greatly appreciated. The notorious PR323. Nah, in this case it's just that gcc's __builtin_pow() is more standards-compliant than newlib's pow(). L -- 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 performance following upgrade
On 3/23/07, Zak Johnson wrote: Lev Bishop wrote: On 3/23/07, Zak Johnson wrote: I first blamed XFT, as it manifested itself most obviously when starting XFT applications; fc-cache helps? fc-cache fails: $ fc-cache /usr/X11R6/lib/X11/fonts: failed to write cache /usr/X11R6/lib/X11/fonts/75dpi: failed to write cache /usr/X11R6/lib/X11/fonts/TTF: failed to write cache /usr/X11R6/lib/X11/fonts/Type1: failed to write cache /usr/X11R6/lib/X11/fonts/encodings: failed to write cache /usr/X11R6/lib/X11/fonts/encodings/large: failed to write cache /usr/X11R6/lib/X11/fonts/misc: failed to write cache /usr/X11R6/lib/X11/fonts/util: failed to write cache The user running fc-cache owns and has write permission on all those directories. strace available at http://nox.cx/cygwin . With the default fontconfig install, fc-cache tries to put the caches in /var/cache/fontconfig and ~/.fontconfig. Check you can write and create files in those directories. If fontconfig is in use at the time of running font-cache, it has to do some locking of the cache files. It may be more successful if you run fc-cache while nothing using fontconfig is running (eg, shut down X and run from a command window). The --really-force and --verbose options to fc-cache might give more clues. Or maybe you should look for stale lockfiles or something in those directories, or you could just try blowing those directories away completely (rm -rf) and starting over. Some problem with the fonts cache would certainly explain slow startup of xft apps. Lev -- 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 performance following upgrade
On 3/24/07, Zak Johnson wrote: Lev Bishop wrote: With the default fontconfig install, fc-cache tries to put the caches in /var/cache/fontconfig and ~/.fontconfig. Check you can write and create files in those directories. Thanks for the suggestions. ~/.fontconfig did not exist; /var/cache/fontconfig was owned and writeable by me. Just to be sure, I copied files into that directory successfully. I rebooted to safe mode and ran rm -rf /var/cache/fontconfig (successfully, with no errors). Still at the command window with nothing else running, I ran fc-cache --really-force --verbose (sorry for the long lines): /usr/share/fonts: skipping, no such directory /usr/X11R6/lib/X11/fonts: /usr/X11R6/lib/X11/fonts: failed to write cache caching, 0 fonts, 6 dirs /usr/X11R6/lib/X11/fonts/75dpi: /usr/X11R6/lib/X11/fonts/75dpi: failed to write cache caching, 398 fonts, 0 dirs /usr/X11R6/lib/X11/fonts/TTF: /usr/X11R6/lib/X11/fonts/TTF: failed to write cache caching, 47 fonts, 0 dirs /usr/X11R6/lib/X11/fonts/Type1: /usr/X11R6/lib/X11/fonts/Type1: failed to write cache caching, 29 fonts, 0 dirs /usr/X11R6/lib/X11/fonts/encodings: /usr/X11R6/lib/X11/fonts/encodings: failed to write cache caching, 0 fonts, 1 dirs /usr/X11R6/lib/X11/fonts/encodings/large: /usr/X11R6/lib/X11/fonts/encodings/large: failed to write cache caching, 0 fonts, 0 dirs /usr/X11R6/lib/X11/fonts/misc: /usr/X11R6/lib/X11/fonts/misc: failed to write cache caching, 55 fonts, 0 dirs /usr/X11R6/lib/X11/fonts/util: /usr/X11R6/lib/X11/fonts/util: failed to write cache caching, 0 fonts, 0 dirs /home/zjohnson/.fonts: skipping, no such directory /var/cache/fontconfig: cleaning cache directory /home/zjohnson/.fontconfig: not cleaning unwritable cache directory fc-cache: failed fc-cache had created /var/cache/fontconfig, owned and writeable (0755) by me (again verified by copying files into the directory successfully). It sure seems like slow XFT is a symptom of some other underlying problem; what else can I do to diagnose? -Zak -- 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: Slow performance following upgrade
On 3/24/07, Zak Johnson wrote: Lev Bishop wrote: With the default fontconfig install, fc-cache tries to put the caches in /var/cache/fontconfig and ~/.fontconfig. Check you can write and create files in those directories. Thanks for the suggestions. ~/.fontconfig did not exist; /var/cache/fontconfig was owned and writeable by me. Just to be sure, I copied files into that directory successfully. I rebooted to safe mode and ran rm -rf /var/cache/fontconfig (successfully, with no errors). Still at the command window with nothing else running, I ran fc-cache --really-force --verbose (sorry for the long lines): snip fc-cache had created /var/cache/fontconfig, owned and writeable (0755) by me (again verified by copying files into the directory successfully). It sure seems like slow XFT is a symptom of some other underlying problem; what else can I do to diagnose? I'm grasping at straws now, but... maybe a postinstall script failed to run. You could try running font-update. You should be able to see the names of the cache files that fontconfig is creating if you do $ FC_DEBUG=16 fc-cache -r -v Maybe that will give a clue to the problem. Other FC_DEBUG values are: MATCH1Brief information about font matching MATCHV 2Extensive font matching information EDIT 4Monitor match/test/edit execution FONTSET 8Track loading of font information at startup CACHE 16Watch cache files being written CACHEV 32Extensive cache file writing information PARSE 64(no longer in use) SCAN 128Watch font files being scanned to build caches SCANV 256Verbose font file scanning information MEMORY 512Monitor fontconfig memory usage CONFIG1024Monitor which config files are loaded LANGSET 2048Dump char sets used to construct lang values OBJTYPES 4096Display message when value typechecks fail Add the value of the desired debug levels together and assign that (in base 10) to the FC_DEBUG environment variable before running the application. Output from these statements is sent to stdout. Fontconfig will distrust its cache files if the timestamps don't make proper sense (it uses the timestamps to keep track of whether the caches are up-to-date). Is there anything fishy there (like somehow /var/cache has a modification time way in the future)? Otherwise, you should use setup to download the source package for fontconfig and build a debug version of fc-cache and try to figure out where things are going wrong. Lev -- 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 performance following upgrade
On 3/23/07, Zak Johnson wrote: I first blamed XFT, as it manifested itself most obviously when starting XFT applications; fc-cache helps? -- 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: script problem
On 3/2/07, Gary R. Van Sickle wrote: The only downside to the switch that I've experienced is that my interactive shells take quite a bit longer to come up, but I think that may have something to do with my setup rather than something intrinsic to the rxvt-unicode+Xserver setup. My usage pattern is such (start one or two interactive shells and leave them up all day) that it's not an issue for me. Does running fc-cache speed up your startup? Lev -- 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: script problem
On 3/3/07, Gary R. Van Sickle wrote: Does running fc-cache speed up your startup? Lev It hasn't bothered me enough to even look in to it frankly. My Cygwin interactive shell startup times have been a bit slower than normal for years because I have a bit of Perl/Cygpath magic in my bash_profile to despacify PATH, which for whatever reason has always seemed to take quite a bit longer than it should. I may look into it when I get enough of them round tuits, but like I said it's still in the tolerable range for me. Fair enough, but it probably took you longer to write this email, than it would have for you to just type 'fc-cache' into your shell :-) Lev -- 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: does usleep() sleep more than it's supposed to?
On 2/26/07, Carlo Florendo wrote: I'm writing an application that requires time precisions up to the microsecond level. However, I put a hard-coded adjustment of 9000 microseconds since usleep() seems to sleep on the average of 9000 microseconds more than it's supposed to, at least on my system. I could work with up to 2000 microseconds for function overhead but 9000 microseconds seems to be too long. I've attached a simple test case that let's usleep() sleep at 10 microseconds at each call. I've also included the output of cygcheck -svr. The output of the attached code on my system is the following: FWIW, I don't see this: Print elapsed time at every call to usleep() Elapsed time (sec:microsec) 0:101000 Elapsed time (sec:microsec) 0:10 Elapsed time (sec:microsec) 0:101000 Elapsed time (sec:microsec) 0:101000 Elapsed time (sec:microsec) 0:10 Elapsed time (sec:microsec) 0:101000 Elapsed time (sec:microsec) 0:10 Elapsed time (sec:microsec) 0:101000 Elapsed time (sec:microsec) 0:101000 Elapsed time (sec:microsec) 0:10 Print elapsed after the loop() Elapsed time (sec:microsec) 0:10 -- 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 stops responding via SSH
On 2/21/07, Larry Hall (Cygwin) wrote: Roald Hendriks wrote: snip Is it possible that I'm suffering from this known issue? Is there a patch available? I'm using OpenSSH 4.5p1-1 and rsync 2.6.6. I have even compiled rsync 2.6.9, but this has not resolved the issue. In order to rule out a server issue, I was able to reproduce the problem on another server as well (using a fresh install of CygWin). Yes, this is a known and long-standing issue with rsync on Cygwin. There has been much talk about it and some attempts to fix it but, to my knowledge, no one is currently working on it. So, for now, it is a limitation of rsync on Cygwin. There has been code in cygwin for some years now, that attempts to fix this, but it is not activated by default, due to it having the potential to cause more problems than it solves (shifting the problem from one of deadlocking on a full pipe, to deadlocking on an empty pipe). It wouldn't be a good idea to use cygwin with this code activated, for general purposes, but if all you wanted was to run some automated rsync scripts and nothing else, maybe it would do the trick for you. Look at the #if 0 in peek_pipe() in select.cc. -- 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: Why binary mode?
On 2/22/07, Sven Severus wrote: But in a textmode mounted directory, 'echo peng p.txt' creates a 6 byte long file containing 'p' 'e' 'n' 'g' '\r' '\n'. OK, exactly as expected. Now I thought, 'cat p.txt' would open this file for reading in textmode, according to the default rule. This is, what I expect, after reading the Cygwin FAQ: When processing in text mode, [...] written to the file [...] you in fact get Hello\r\n. Upon reading this combination, the \r is removed [...]. Why is it in fact not removed when reading with cat? Because cat is required by posix to read in binmode. Try, for example: $ echo peng p.txt read CO p.txt od -c $CO 000 p e n g \n 005 -- 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: Why binary mode?
On 2/22/07, Norton Allen wrote: Lev Bishop wrote: On 2/22/07, Sven Severus wrote: But in a textmode mounted directory, 'echo peng p.txt' creates a 6 byte long file containing 'p' 'e' 'n' 'g' '\r' '\n'. OK, exactly as expected. Now I thought, 'cat p.txt' would open this file for reading in textmode, according to the default rule. This is, what I expect, after reading the Cygwin FAQ: When processing in text mode, [...] written to the file [...] you in fact get Hello\r\n. Upon reading this combination, the \r is removed [...]. Why is it in fact not removed when reading with cat? Because cat is required by posix to read in binmode. Try, for example: $ echo peng p.txt read CO p.txt od -c $CO 000 p e n g \n 005 Which apparently means that the original doc he referred to (Cygwin User's Guide, chapter Text and Binary modes ) should be updated. I think the fact that cat reads in binmode is surprising (though it makes sense if you think about it) so the behavior should be prominently noted. Certainly the shell idiom of using cat to read text files is widespread. Makes you wonder whether cat shouldn't have an option added to read in text mode (that'd be an upstream question). It has been discussed to add a cygwin-local cat --text option, but rejected on the basis that since it would be cygwin-only and nonstandard, one might as well use the equally nonstandard d2u instead of cat. I believe there was at one point some attempt to get such an option upstream, but upstream resisted this. I'm sure this is mentionned in the archives somewhere. Lev -- 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: strange bug in gettimeofday function
On 2/16/07, Andrew Makhorin wrote:
Nevertheless, you agree that if t0 t1 then t0 - t1 cannot be exact
zero in *any* floating-point model, don't you? Even if optimization is
used, the compiler must not arbitrarily change the precision of the
same floating-point variable.
The -ffloat-store compiler option is available for those programs who
are concerned with such details. This is your code compiled -O2 and
-f{no-,}float-store. The difference is one extra load instruction.
$ diff -u f-floatstore.s f-nofloatstore.s
--- f-floatstore.s 2007-02-16 04:26:19.117875000 -0500
+++ f-nofloatstore.s2007-02-16 04:26:03.399125000 -0500
@@ -321,11 +321,10 @@
fxch%st(1)
.stabn 68,0,12,LM12-_main
LM12:
- fstpl -16(%ebp)
+ fstl-16(%ebp)
+ fxch%st(1)
.stabn 68,0,13,LM13-_main
LM13:
- fldl-16(%ebp)
- fxch%st(1)
fucompp
fnstsw %ax
sahf
--
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: strange bug in gettimeofday function
On 2/11/07, Christopher Faylor wrote: On Sun, Feb 11, 2007 at 07:20:14PM +0300, Andrew Makhorin wrote: Hi, I detected a strange bug in the standard function gettimeofday. It *sometimes* reports the time which being expressed as the integer number of milliseconds is *less* than the time obtained *earlier* with the same function. The expression 100 * tv.tv_sec + tv.tv_usec is calculated in 64-bit arithmetic, so overflow cannot happen. The negative difference in the time values on two successive calls is about 100 milliseconds. cygcheck.out is attached. In cases like this a simple test case is really required. If this is really true then calling gettimeofday in a loop should be enough to demonstrate the problem. I have a hunch that it will be a good idea to have a look at what the result of GetSystemTimeAdjustment() is on the machine exhibiting this behaviour, at the time it exhibits this behaviour. -- 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: pasting into an ssh connection painfully slow... sometimes
On 2/8/07, Lev Bishop wrote: When I get some time I'll redo those patches against the latest cygwin version. In the meantime, if netscreen provides a sysctl net.inet.tcp.ackonpush or some way to disable delayed acks, then that might help you. Or you could try changing on your cygwin box the registry entry HKLM\SYSTEM\CurrentControlSet\Services\Afd\Parameters\DefaultSendWindow (DWORD) to at least 0x1 Lev -- 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: pasting into an ssh connection painfully slow... sometimes
On 2/7/07, DePriest, Jason R. wrote: My department manages some Netscreen NS208 firewalls. If I ssh into them with the cygwin ssh client (either with rxvt or with cygwin from a cmd.exe prompt), pasting into the session runs like a 2400 baud modem. If I ssh into them with something else such as PuTTY, then the paste function works just like it does on other systems: fast. I don't have this problem with cygwin ssh on systems other than the Netscreens. PuTTY doesn't have any special configuration done to it so that it works. I just connect and its okay. Has anyone else experienced this sort of slowness and if so, how did you fix it? Windows has some deficiencies when it comes to sending data in certain configurations. They particularly show up due to the way cygwin makes use of winsock. I looked into this a while ago: http://www.cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html When I get some time I'll redo those patches against the latest cygwin version. In the meantime, if netscreen provides a sysctl net.inet.tcp.ackonpush or some way to disable delayed acks, then that might help you. Lev -- 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: less doesn't recognize capabilities of remote terminal
On 2/5/07, Gary Johnson wrote: On 2007-02-05, Gary Johnson wrote: I recently got Cygwin's sshd running on my Windows XP machine. It seems to basically work fine, allowing me to login from any of several machines running various flavors of Unix. Cygwin's less command, however, doesn't seem to recognize the capabilities of my remote terminal. For example, I often use ssh to login to my Windows machine from another machine running SunOS 5.8, using an xterm version XFree86 4.1.0(165). When I use less to read a file, I get a warning message: $ less /usr/share/doc/Cygwin/terminfo-5.5_20061104.README WARNING: terminal is not fully functional /usr/share/doc/Cygwin/terminfo-5.5_20061104.README (press RETURN) Update: If I simply set TERM=xterm (instead of xterm-16color), less works fine: TERM=xterm less /usr/share/doc/Cygwin/terminfo-5.5_20061104.README The difference between the two terminfo entries is: snip That xterm-16color terminfo is from Cygwin's /usr/lib/terminfo. The xterm-16color terminfo from the xterm-165 release that I have on the Sun machine is different, but its setb and setf strings also lack the leading \E's. The same is true for the xterm-16color terminfo from a Red Hat Linux 9 machine with xterm-174. This is just a guess, but I wonder if the setb and setf entries are long-standing errors in the xterm terminfo data that haven't been detected because applications use setab and setaf instead. But then why does only Cygwin's less complain? The cygwin-distributed less doesn't use terminfo. It was built with -ltermcap. The cygwin-distributed /etc/termcap doesn't have an entry for xterm-16color. Thus, less complains. Possible solutions inlclude adding an xterm-16color line to /etc/termcap (could just be an additional alias to xterm), or installing libncurses-devel, downloading the less source package and building it yourself (the build process will automatically use ncurses if it's available). Lev -- 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: Eliminating -mno-cygwin from gcc?
On 2/1/07, Corinna Vinschen wrote:
On Feb 1 07:15, Christopher Faylor wrote:
We were going to replace text mounts with automatic file conversion using
d2u:
cygwin: CRLF line endings detected. Converting.
I think this is too complicated. What about
cygwin: CRLF line endings detected. Deleting offending file.
It's already been shown that file deletion is too slow in cygwin. We
don't want more performance complaints. Better do it this way:
$ cat /etc/postinstall/cygwin.sh.done
#!/bin/sh
find / -execdir d2u {} +
--
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: Newly-installed bash 3.2.9-10 (cygwin 1.5.24-1) exits when I try to execute a program
On 1/30/07, Glenn Serre wrote: I have no working patch, I was going to use this problem as an opportunity for my first attempt to build and debug the cygwin DLL (while maybe even charging a client for it) but it looked to me as if it may already be being addressed. Looking again, I see that this might not be that case, so I'll see what I can do (no promises, as I'm a newbie at cygwin development). In cases like this, a generally useful thing you can do is to go try snapshots from http://cygwin.com/snapshots/ and try to figure out between which 2 versions the problem first appeared. If you post the reult of this to the list, then someone can often fix it easily, but if you wanted to have a go yourself, you can look at the changelogs for that snapshot and frequently it will be obvious which change was to blame. -- 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: isnan() causes segfault
On 11/30/06, Eric Lilja wrote: If compiled with: $ g++ -Wall -Wextra -std=c++98 -pedantic -g isnantest.cpp -o run (those are the flags we have been using in this course). But it doesn't stackdump if compiled simply with: $ make isnantest g++ isnantest.cpp -o isnantest I was able to reproduce this behaviour. There seems to be a difference in the generated assembler. The -std=c++98 seems to be the only switch that matters. Here is a diff. File isnantest2.s is the stackdumping one (ie the one with -std=c++98) --- isnantest.s 2006-11-30 13:14:12.71875 -0500 +++ isnantest2.s2006-11-30 13:26:55.984375000 -0500 @@ -1,4 +1,4 @@ - .file isnantest.cpp + .file isnantest2.cpp .def___main;.scl2; .type 32; .endef .text .align 2 @@ -47,12 +47,9 @@ movl%esp, %ebp subl$8, %esp movl8(%ebp), %eax - movl%eax, -4(%ebp) - fildl -4(%ebp) - fstps (%esp) - call___isnanf + movl%eax, (%esp) + call__ZN9__gnu_cxx5isnanIiEEiT_ leave ret - .def___isnanf; .scl3; .type 32; .endef .def__ZN9__gnu_cxx15__capture_isnanIiEEiT_; .scl3; .type 32; .endef .def__ZN9__gnu_cxx5isnanIiEEiT_;.scl3; .type 32; .endef Lev -- 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: isnan() causes segfault
On 11/30/06, Lev Bishop wrote:
On 11/30/06, Eric Lilja wrote:
If compiled with:
$ g++ -Wall -Wextra -std=c++98 -pedantic -g isnantest.cpp -o run
(those are the flags we have been using in this course).
But it doesn't stackdump if compiled simply with:
$ make isnantest
g++ isnantest.cpp -o isnantest
I was able to reproduce this behaviour.
There seems to be a difference in the generated assembler.
The -std=c++98 seems to be the only switch that matters.
Here is a diff. File isnantest2.s is the stackdumping one (ie the one
with -std=c++98)
snip
And the cause of the failure seems to be mutual recursion in
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cmath
where at line 458:
templatetypename _Tp
int
__capture_isnan(_Tp __f) { return isnan(__f); }
which calls at line 532:
templatetypename _Tp
int
isnan(_Tp __f) { return __capture_isnan(__f); }
which calls back to __capture_isnan().
Incidentally, the stackdump file produced here is empty, so addr2line
can't help...
Lev
--
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: isnan() causes segfault
On 11/30/06, Lev Bishop wrote:
On 11/30/06, Lev Bishop wrote:
On 11/30/06, Eric Lilja wrote:
If compiled with:
$ g++ -Wall -Wextra -std=c++98 -pedantic -g isnantest.cpp -o run
(those are the flags we have been using in this course).
But it doesn't stackdump if compiled simply with:
$ make isnantest
g++ isnantest.cpp -o isnantest
I was able to reproduce this behaviour.
There seems to be a difference in the generated assembler.
The -std=c++98 seems to be the only switch that matters.
Here is a diff. File isnantest2.s is the stackdumping one (ie the one
with -std=c++98)
snip
And the cause of the failure seems to be mutual recursion in
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cmath
where at line 458:
templatetypename _Tp
int
__capture_isnan(_Tp __f) { return isnan(__f); }
which calls at line 532:
templatetypename _Tp
int
isnan(_Tp __f) { return __capture_isnan(__f); }
which calls back to __capture_isnan().
So, the deal is that /usr/include/math.h has a macro definition for
isnan(). This is at line 138, starting with a perhaps relevant
comment:
/* Note: isinf and isnan were once functions in newlib that took double
* arguments. C99 specifies that these names are reserved for macros
* supporting multiple floating point types. Thus, they are
* now defined as macros. Implementations of the old functions
* taking double arguments still exist for compatibility purposes. */
#define isinf(x) \
(__extension__ ({__typeof__(x) __x = (x); \
(sizeof (__x) == sizeof (float)) ?
__isinff(__x) : __isinfd(__x);}))
#define isnan(x) \
(__extension__ ({__typeof__(x) __x = (x); \
(sizeof (__x) == sizeof (float)) ?
__isnanf(__x) : __isnand(__x);}))
So, because /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cmath
captures this definition in it's __capture_isnan() normally things
work. However, -std=c++98 causes __STRICT_ANSI__ to be defined, and
/usr/include/math.h protects the macro definitions within a #ifndef
__STRICT_ANSI__ , things break in this situation.
It would appear that fpclassify(), isfinite(), isinf(), isgreater(),
and others will also be affected. I'm not really clear about the
implications of this, nor what the relevant standards have to say, but
perhaps the correct thing is to change the guard at line 105 of
/usr/include/math.h to
#if !defined(__STRICT_ANSI__) || defined (__cplusplus)
as is done in the same file for atanf(), cosf(), et al.
Something for the newlib folks to deal with, I suppose.
Lev
--
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: isnan() causes segfault
On 11/30/06, Lev Bishop wrote: snip Something for the newlib folks to deal with, I suppose. And they took my suggestion: http://sources.redhat.com/ml/newlib/2006/msg00938.html Lev -- 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: Problem passing Windows path names from batch file to bash script
On 10/28/06, Gary Johnson wrote: On 2006-10-28, Buchbinder, Barry (NIH/NIAID) [E] wrote: From: Gary Johnson; Sent: Friday, October 27, 2006 11:44 PM I am trying to pass Windows path names from a Windows batch file to a Cygwin bash script. I have found a solution using Windows environment variable substitution to replace \s with /s before passing the name to bash, but I cannot figure out how to pass the name without that replacement. The problem is with names of the form \\host\user\file with spaces Note the difference between these two: Exhibit A: C:\set CYGWIN=noglob C:\\cygwin\bin\echo \\host\share\file with spaces \\host\share\file with spaces Exhibit B: C:\set CYGWIN=glob C:\\cygwin\bin\echo \\host\share\file with spaces \host\share\file with spaces HTH, Lev -- 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: igncr vs text mode mounts, performance vs compatibility
One additional thing I'd like to say, if people are considering possibly making a decision based off the line ending of the first line of the file: it's worth bearing in mind that it's quite possible for a file to end up with mixed line endings. Most editors are at least smart enough to convert the whole file to their preffered format, but not all, and there's always the possibility of nastiness like: C:\TEMP echo extra line file_with_unix_line_endings It's yet another special case to think of: Why my scrpt not wrok? Because it is on a binary mount you didn't set igncr you have CRLF line endings on some lines the first line doesn't have a CRLF It'll be one of those things that works 99% of the time for 99% of people, and by the time it bites someone they'll have forgotton all about this issue and will be very confused. -- 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.21-1 - Crash on anything using cygwin1.dll
On 9/28/06, OverlordQ wrote: Yes, still same problem. And the other copies were from programs that had been compiled under cygwin like Winboard, jtr, and a few Chess engines. bash.exe and id.exe both use other cygwin dlls, including cygintl-3.dll and cygiconv.dll (also for bash cygreadline6.dll cygncurses.dll). Maybe one of these 3PPs that dropped versions of cygwin1.dll onto your system also dropped their own versions of these libraries? -- 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.20(0.156/4/2) pipe hangs, dos files
On 8/2/06, Darryl Mile: Okay you seem to have some understanding as to how and why it failed for the unison group of users. Do you think the commented out code is fixable in any so that all cases work correctly ? Iff you can come up with a way to distinguish the two situations: 1) blocking read is in progress. 2) no blocking read is in progress. I can't come up with a way of doing that which is reliable in all cases of multiple readers on the same pipe, multiple writers on the same pipe, non-cygwin windows native processes involved, etc. Worse, I can't even come up with a way that helps the more common cases (single reader, single writer, both cygwin processes) and falls back to the current behaviour for the other cases. Instead, everything I've tried would deadlock in those less common cases. There probably is a way to do it, but enough people have spent enough time pondering this at this point, that you can be assured it isn't something immediately obvious. Anyway, at this point, if you can code something up and show that it works, then that's more likely to impress the maintainers than further talking. (And even if the maintainers don't accept the patch, if it fixes the problem for you, then there's nothing stopping you from using your own patch for your own purposes, and even distributing it to anyone else who finds it useful. That's the nice thing about the GPL). Lev -- 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.20(0.156/4/2) pipe hangs, dos files
On 8/1/06, Darryl Miles wrote: I am still interested in tackling the whole situation but I do need to be furnished with a testcase to work with. I believe the original comeback by the group of users running unison should have insisted a testcase was produced by them to demonstrate the new breakage. As I recall, the group of users running unison was the exact same group as the group who developed the currently-commented-out code in select.cc, so there wasn't any particular need for them to provide themselves a test case I'm sure it's all explained in the mailing list archives. Basically, the NtQueryInformationFile() gives back the amount of non-paged pool used by the pipe, which is only the same thing as the amount of data available to read in the case that there are no outstanding read()s on the pipe. Otherwise, the commented-out code can cause a write()r to deadlock any time the process at the other end of the pipe issues a read() for more than a pipe buffer's worth of data. This is much worse than the current situation, where a non-blocking write can occasionally block, which in turn may cause (serious) performance issues but rarely a total deadlock. (After all, cygwin is not an rtos and there is allowed to have arbitrary delays at any point in the code, without violating the posix semantics, so long as eventually the write() *eventually* returns.) L -- 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: Cgywin filename with 255 character
On 7/11/06, Larry Hall (Cygwin) wrote: Windows places a limit on the number of ASCII characters in a file/path name. It's approximately 260 characters. Cygwin path conversion may cut that down a bit. More precisely, both the windows version of the path, and the posix version of the path, must each be less than 260 characters, including the 3 chars of 'C:\' for the windows version and the full path from root for the cygwin version. If you want to access long filenames via a cygwin path, make sure you mount the directory such that the cygwin mountpoint is at least as short as the windows path of the mountpoint. Lev -- 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: Cgywin filename with 255 character
On 7/11/06, Jörg Schaible wrote: Is there any pointer at MS, where this is described exaclty? I was only able to find some entries in the knowledge base that describe applications that are affected by this limit, but nowhere an explanation under what circumstances a process/application is hit by this limit. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp -- 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: Using du.exe to calculate disk usage on a Microsoft cluster server
On 7/7/06, Dave Korn wrote: I *still* don't understand how it is possible for your users to create files with names that are longer than the maximum filename length that windows permits - this is a limitation of the windows OS and filing system, not one that cygwin imposes. Dave: Probably the problem that will is experiencing (hard to say for sure since he won't give any of the relevant information) is due to the fact that cygwin enforces the MAX_PATH/CYG_MAX_PATH on both the windows path and on the posix form of that path. So there can be paths which are valid to windows, but if the posix prefix is longer than the windows prefix, they can be considered too long by cygwin. Your suggestion to use a mountpoint: You might try using a mountpoint to shorten some of the prefix of the overly long filenames. Will work, so long as the posix path of the mountpoint is shorter than the windows path of the mountpoint In this case, '/cygdrive/s/' is longer than 's:\' . 's:\' is 3 chars long, the posix mountpoint must start and end with '/', so we have one spare character. Therefore, my shot-in-the-dark prediction is that $ mount -s -b -f S: /s $ du -sh /s/* Will work. Barring problems with quoting, etc. Lev -- 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: Using du.exe to calculate disk usage on a Microsoft cluster server
On 7/7/06, Linda Walsh wrote: It is quite trivial. He's prepending either S:/ or /cygdrive/s to an existing pathname. The existing pathname can be at the limit (~256 bytes). Adding either prefix, above, the pathlen becomes 259 ...which is why MAX_PATH on windows is 260, to allow for these extra 3 chars... Another easy way: cd to directory /averylongdirnamethathas200chars you can create a file in that directory of maxchars, No, you can't. At least, you shouldn't be able to. The attempt to create this file is supposed to fail because the limit is for the path length as a whole. -- 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 over ssh hang issue understood
On 7/7/06, Darryl Miles wrote: Dave Korn wrote: On 07 July 2006 01:31, Darryl Miles wrote: Maybe you are in a better position to share more insight into the situation (specifically about the use of NtQueryInformationFile in addressing the writability semantics of the POSIX select/poll/write event system). I think you should just use it and it should just work. Okay the immediate red flag I can see with it: else if (fpli.WriteQuotaAvailable = PIPE_BUF) gotone += s-write_ready = true; The underlying socket is still being used in blocking mode. Socket?? What is this socket? Which means when we write write 1024 bytes of data but only one PIPE buffer is free (ulimit -p) a POSIX kernel would allow: What is one PIPE buffer (ulimit -p)? Non-blocking: write(fd, buffer, 1024) = 512 write(fd, buffer[512], 512) = -1 (EAGAIN) Blocking: write(fd, buffer, 1024) = 512 write(fd, buffer[512], 512) = [blocking occurs until] 512 SUSv3 does not permit this behaviour. It is quite clear on this point: If the O_NONBLOCK flag is clear, a write request may cause the thread to block, but on normal completion it shall return nbyte. I would guess under WIN32 we end up with fhandler.cc:raw_write() doing: WriteFile(hPipe, buffer, 1024, writtenLen, 0) = [blocking occurs until] TRUE (writtenLen=1024) This gives the SUSv3-mandated behaviour for blocking pipes (modulo signal-interruptibility). Maybe PIPE_NOWAIT would be good for us (to setup when the fd has O_NONBLOCK set). If PIPE_NOWAIT isn't good for us. We can get around this by using Overlapping I/O and controlling the outstanding pipe buffers. This makes cygwin simulate 'ulimit -p' to some degree. Which is back towards my proposal. What does simulate 'ulimit -p' mean? ulimit -p works just fine on cygwin: $ ulimit -p 8 Lev -- 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: Using du.exe to calculate disk usage on a Microsoft cluster server
On 7/4/06, Will Beldman wrote: I will try to run the script against /cygdrive/s/* instead of S:/* and let you all know if it fails. You still haven't posted the actual command line you are using, but why not use /cygdrive/s instead of /cygdrive/s/* , which should avoid the need for quoting? -- 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: mv: permission denied - bug
I failed to reproduce your problem. However, maybe you can test out a couple of things: You are doing the move accross volumes (from /tmp which you have mounted from d:\programme\cygwin\ to /cygdrive/x/test , which is x:\test\ ). Do you still see the problem if you do the move within the same volume? (Ie, make a directory /cygdrive/x/tmp/ and use it instead of /tmp/ ). This would be a good idea even if it doesn't fix this problem, since it should also be faster, because mv within the same volume is just a rename, whereas mv between volumes has to do a copy then delete. Do you still see the problem if you use a mount instead of /cygdrive/x/ (ie something like $ mount -s -b x:/test /xtest and then use /xtest in place of /cygdrive/x in all your scripts)? (I wouldn't expect this to make a difference, but you never know). Are you running anything that wants to examine every file on your system (realtime virus scanner, personal firewall, content indexer, google desktop search, etc)? Try uninstalling (not just disabling) all such software, as it has been known to cause similar problems in the past. cygcheck indicated that both d: and x: are local ntfs hard disks. Is this correct? HTH, L -- 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: Using du.exe to calculate disk usage on a Microsoft cluster server
On 7/3/06, Larry Hall (Cygwin) wrote: Use POSIX paths (i.e. /cygdrive/s). Here I think you've found an application for 'find'. How about something like: find /cygdrive/s -maxdepth 1 -print0 | xargs -0 du How is that better than: du /cygdrive/s ? L -- 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 over ssh hang issue understood
On 6/28/06, Darryl Miles wrote: How do I pull down ssh/rsync/cygwin.dll and build in a way that I can see the problem ? For ssh and rsync sources, use cygwin setup.exe. For cygwin.dll see http://cygwin.com/contrib.html Especially note the requirement to sign a copyright release, if you want your patch to make it into the mainline cygwin. What debugging tools can I use ? See how-to-debug-cygwin.txt http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-to-debug-cygwin.txt?rev=1.12content-type=text/x-cvsweb-markupcvsroot=src Can I printf() the cygwin.dll ? debug_printf() with strace I read further up the thread the issue maybe to do with winsup/cygwin/select.cc trying to provide emulation of select(2) to applications and that it doesn't know how to ask Win32 kernel if a NamedPipe is writable (without blocking). I presume the problem is the application code blocking when it did not expect it. Is it allowed for the cygwin.dll to create extra threads that are self managing ? Allowing for the IO to be offloaded to a worker thread, and while a thread of active for the emulated pipe fd then you revoke writability indications from select(2) interface. But if no worker thread is busy working on that fd then you get writability back ? Yes, but it is very hard to get the precise unix semantics. For example, the application issues a write() which spawns off a thread that then blocks. Then the application exit()s, causing the thread to also terminate before completing its write, and the write never completes. You could get around this by using fork() instead of a thread (very slow), or spawn() (somewhat more efficient) or implementing all this in the cygserver (see winsup/cygserver/ ) which will be much more efficient than fork()ing each write but will still be slow due to the need to send everything first (via another pipe or socket) to the cygserver and then to the pipe, and all the context-switching this entails. There is also the issue of what return value to give the application doing the write() on the pipe. You'll have to be careful to deal with error conditions, SIGPIPE, etc, etc. This allow part of CYGWIN.DLL to be offload the blocked WriteFileEx() call to a named pipe, so the function can return control to the application. It's WriteFile() not WriteFileEx() AFAICT Would that be theoretically possible ? You dont need to create a new thread from every IO to a writable named pipe, you can keep a small number of threads around that will create themselves as necessary. Once a thread has completed the IO it can hang around for a short time, staying alive and going back onto an idle queue, blocking itself until more I/O was needed or a timeout occurs (5 seconds). If a timeout occurs it removes itself from the idle list and destroys itself. So you dont take the thread creation hit for every I/O. There is already this type of capability. See cygthread.cc Also take a look at fhandler_pipe::read() which does something similar, to allow blocking read() on a pipe to be interrupted Good luck, Lev -- 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 over ssh hang issue understood
On 6/29/06, Darryl Miles wrote: I also think from reading through the WIN32 API that I either get blocking IO or overlapped IO, where overlapped is non-blocking with async I/O completion signaling. This mode isn't directly compatible with non-blocking of Unix the way I see it as the data is still queued into the kernel for IO. Not next left with the application in the case of errno=EAGAIN of unix. Actually, the data is left with the application, but the application is not allowed to touch it until the write has completed. It's very similar to UNIX asynchronous IO (aio_read() aio_write() et al). However for pipes (and only for pipes) the windows API offers something a lot like UNIX nonblocking semantics. It's only supported to provide Lan Manager 2.0 compatibility and MSDN says should never be used. Look at SetNamedPipeHandleState() with the PIPE_NOWAIT flag. Unlike Overlapped IO (see below) the PIPE_NOWAIT flag can be switched on and off at will, it seems, so maybe there's a way to use it to do what you want. I don't know enough about real life use of the WIN32 API to know if an overlapped IO can block as well. If that is the case then maybe all pipe IO has to be done through a writer thread and we use the busyiness state of a writer thread to drive set/reset write_ready state for select. We then serialize all write(2) calls on pipes in FIFO order so there is a clear defined order, even if the application happens to have multiple threads writing. Maybe someone with more WIN32 knowledge than me would care to comment. Bear in mind, you can only set overlapped vs non-overlapped IO at file-handle creation time and subsequently the mode cannot be changed (or even determined, in any convenient way). Cygwin uses windows pipes so we can interoperate with native windows processes, which use non-overlapped syscalls on inherited handles (and which fail on overlapped handles). If you go with overlapped handles, then you're removing the compatibility with native processes, which thereby removes the main justification for using native pipes, and instead it would almost certainly be better (less work and more efficient) to implement pipes from scratch using shared memory and semaphores or similar primitives. Lev -- 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 over ssh hang issue understood
On 6/29/06, Christopher Faylor wrote: For the record, I'm not wild about scrapping the existing (but currently turned off) code in cygwin that is supposed to fix this. Using the NT api was supposed to allow us to do what we wanted with no half-measures. I'd rather see someone finish that, or at least prove that it doesn't work, before scrapping it and move on to something else. I have a cunning idea (probably too cunning) to make the current code work and I will hopefully be able to submit a short patch in a day or two. The idea of using threads for pipe writing has been bounced around for a long time. It doesn't solve the select problem if there are multiple processes writing to one pipe. That is not a completely unusual event, unfortunately. Could you be more specific on how it doesn't solve the select problem in when there are multiple processes writing on the pipe? As far as I can tell, if (and its a big if) we can build something with threads that works for a single process, it should work just as well for multiple processes. Can you give an example sequence of writes and selects that illustrates the problem? (Not that I think the thread approach is without problems, I just can't see this one). Lev -- 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: lockfile link on Core Duo laptop
On 6/25/06, Benjamin D wrote: Works fine, so I try seeing what happens with strace: $ ls -il foo bar; touch foo strace link foo bar strace.out 21 ls -il foo bar ls: foo: No such file or directory ls: bar: No such file or directory ls: bar: No such file or directory 2814749767163063 -rw--- 1 bdodge mkgroup-l-d 0 Jun 24 20:58 foo Some WAG things to try: a) Put in a pause: $ ls -il foo bar; touch foo sleep 2 strace link foo bar strace.out 21 ls -il foo bar b) Completely uninstall the Embassy Trusted Security thing (or whatever it's called). c) Suspect (and, to test, uninstall (not just disable)) any realtime virus scanners, personal firewalls, file indexers (google desktop search) and anything else that hooks into file syscalls stuff. (Especially do this if step (a) made any difference). L -- 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: Unable to delete directory in Cygwin
On 6/19/06, mwoehlke wrote: Larry Hall (Cygwin) wrote: mwoehlke wrote: Eric Blake wrote: That said, cygwin does try to emulate linux, and if someone were to contribute a patch that would allow cygwin to emulate directory deletion if it knows that all open handles have also been scheduled for unlinking at process end, then http://cygwin.com/acronyms/#PTC. Not a patch, but for the record, it looks like Interix solves this problem (http://www.interopsystems.com/tools/tm.aspx?m=9403). Maybe Cygwin could do something similar? (And in case that link dies; apparently Interix has a special 'temp' directory where unlinked files are sent until their handles are all closed.) If you take a look at the cygwin sources, you'll see that Cygwin does something similar already. This does not solve the problem for those that want to unlink and immediately recreate the unlinked entry though... I'm confused. As I read the post, if I create a file 'bar' in '/foo', open the file, and then 'rm -rf /foo', I can't do that. If Cygwin magically redirects 'bar' to some special place, wouldn't that a: allow me to unlink '/foo' b: allow me to then create a new (and different) '/foo/bar'? Yes, in both cases. However, cygwin doesn't do this magic redirection. What it does do, as far as I understand it, is that it adds files that have deletion syscalls called on them to a pending-deletion list, returns success to the deleter, and then deletes the file at the first chance it gets. I had a go at making a magic redirection patch a while ago, but never got it into submittable form. I also do not see anywhere that the OP is even trying to do [b]. With the current cygwin, you don't get that far, since the file bar still exists until it's no longer in use, and the pending-delete stuff doesn't happen for directories. Take a look at winsup/cygwin/delqueue.cc , especially the initial FIXME comment L -- 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: Open sockets non-overlapped?
On 6/15/06, Corinna Vinschen wrote: On Jun 15 12:07, Lev Bishop wrote: Just to spell it out: the problem shown in my testcase, is only exibited with overlapped sockets. Non-overlapped don't have any problem. Which is strange to me, since MSDN makes no mention of situations where setsockopt() can block. Erm... I tested your testcase and I can reproduce the hang only when using NON-overlapped sockets created with WSASocket(..., 0). It works fine with overlapped sockets created with select or WSASocket(..., WSA_FLAG_OVERLAPPED). I assume the above is just a typo? Yes, a typo, sorry about that. L
Re: Open sockets non-overlapped?
On 6/12/06, Corinna Vinschen wrote: I found that using WSASocket(!OVERLAPPED) instead of socket results in sshd misbehaviour (scp takes a long time to start copying files, an interactive logon doesn't print the prompt until the user presses the return key). I didn't try to debug this, lazy as I am. Strange. I don't run sshd, but I've been using this patch for a while now and not noticed any problems. Maybe I'll try installing sshd one of these days and see if I see those issues you describe. Additionally, I'm really curious *why* opening the socket without the overlapped attribute should create a socket being more useful to native Windows processes than standard, overlapped attributed sockets. After all the only visible difference is that a socket with the overlapped attribute set can use overlapped operations, which the non-overlapped socket can't. It does not mean that overlapping I/O is forced on the socket. It's just adding a capability. It doesn't make it any less useful to native processes _as a socket handle_ but it does make a difference when the native processes use it _as a file handle_. As you know, the semantics of WriteFile() et al change completely depending on whether they get an overlapped handle or not (eg the LPOVERLAPPED parameter either _must_ be null or _must not_ be null, on 95/98/Me) . And there seems to be no way to tell whether a handle you've inherited was opened overlapped or not (short of using the NT API: NtQueryInformationFile FILE_MODE_INFORMATION) and no way to reset the mode once the file has been opened. So applications are effectively forced to assume their GetStdHandle()s' are non-overlapped. Actually, with a matching server listening on port 5001 (nc -l -p 5001), I don't see any difference between using socket or WSASocket in the `cmd /c dir /dev/tcp/localhost/5001' example. In both cases cmd refuses to send anything useful to the server, printing There is not enough space on the disk. Hmph. It works for me. Must be some difference in our configurations, windows versions, etc. I note that msdn warns that using socket handles as file handles is an optional feature and not all providers support it. I guess the provider must be both a Winsock provider and also a file-system driver in order to make this work. Maybe you have some LSPs on your machine or something? Lev
Re: bash: /dev/null: No such file or directory. Why is /dev/null implemented using the windows NUL device?
On 6/1/06, Robert McKay wrote: Does anyone know what can go wrong with the windows NUL device? :-) Do you need any kind of special permissions to use NUL? You could download winobj from sysinternals.com. Check that \GLOBAL??\NUL is a symbolic link to \Device\Null Check that \Device\Null exists. Check the permissions for both (properties, security tab). HTH Lev -- 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/
fhandler_base::readv
2006-05-23 Lev Bishop [EMAIL PROTECTED] * fhandler.cc (readv): Deal with tot not precalculated. Index: fhandler.cc === RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v retrieving revision 1.251 diff -u -p -r1.251 fhandler.cc --- fhandler.cc 22 Mar 2006 16:42:44 - 1.251 +++ fhandler.cc 24 May 2006 00:24:46 - @@ -964,6 +964,7 @@ fhandler_base::readv (const struct iovec len += iovptr-iov_len; } while (iovptr != iov); + tot = len; } assert (tot = 0);
Re: fhandler_base::readv
On 5/23/06, Christopher Faylor wrote:
At this point in the code, tot is only used in the subsequent assert.
If that is the rationale for this change wouldn't it make more sense to
just check len in the assert?
It does make sense. Try this version.
2006-05-23 Lev Bishop [EMAIL PROTECTED]
* fhandler.cc (readv): Deal with tot not precalculated.
Index: fhandler.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v
retrieving revision 1.251
diff -u -p -r1.251 fhandler.cc
--- fhandler.cc 22 Mar 2006 16:42:44 - 1.251
+++ fhandler.cc 24 May 2006 02:09:09 -
@@ -941,12 +941,11 @@ fhandler_base::write (const void *ptr, s
ssize_t
fhandler_base::readv (const struct iovec *const iov, const int iovcnt,
- ssize_t tot)
+ ssize_t len)
{
assert (iov);
assert (iovcnt = 1);
- size_t len = tot;
if (iovcnt == 1)
{
len = iov-iov_len;
@@ -954,7 +953,7 @@ fhandler_base::readv (const struct iovec
return len;
}
- if (tot == -1) // i.e. if not pre-calculated by the caller.
+ if (len == -1) // i.e. if not pre-calculated by the caller.
{
len = 0;
const struct iovec *iovptr = iov + iovcnt;
@@ -966,7 +965,7 @@ fhandler_base::readv (const struct iovec
while (iovptr != iov);
}
- assert (tot = 0);
+ assert (len = 0);
if (!len)
return 0;
Re: fhandler_base::readv
On 5/23/06, Lev Bishop wrote: It does make sense. Try this version. Sorry, no. I'm stupid - ignore that version. There's not much point in doing assert(len=0) given that len is unsigned, it's pretty much a given :-) How about just removing the assert()? So here's the 3rd attempt. 2006-05-23 Lev Bishop [EMAIL PROTECTED] * fhandler.cc (readv): Deal with tot not precalculated. Index: fhandler.cc === RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v retrieving revision 1.251 diff -u -p -r1.251 fhandler.cc --- fhandler.cc 22 Mar 2006 16:42:44 - 1.251 +++ fhandler.cc 24 May 2006 02:22:10 - @@ -966,8 +966,6 @@ fhandler_base::readv (const struct iovec while (iovptr != iov); } - assert (tot = 0); - if (!len) return 0;
Re: Getting the pipe guard
On 5/21/06, Christopher Faylor wrote: I've checked in a variation of the above plus some modifications to pipe.cc which prevent some handle stomping and may make things work better. I see that your patch makes writepipe_exists non-inheritable. This means that if you pass a pipe to a windows process, which in turn passes it to another process, the writepipe_exists will be gone, and cygwin will think the pipe is closed, AFAICT. So something like: bash$ ls | cmd /c more will not work any more. I think... I can't check this, because I don't have access to old versions of windows where writepipe_exists is actually used. Lev
Re: Getting the pipe guard
On 5/21/06, Christopher Faylor wrote: I've checked in a variation of the above plus some modifications to pipe.cc which prevent some handle stomping and may make things work better. Did you actually check in a change to select.cc? I'm not seeing it. (But I'm not all that good with cvs so maybe it's my fault) L
Getting the pipe guard
I was trying to make nonblocking pipe reads actually not block. Here's
an example of the problem:
bash-3.1$ exec 8 (while :; do sleep 1 ; echo -n \* ; done )
bash-3.1$ cat 8 /dev/null
[2] 308
bash-3.1$ dd iflag=nonblock bs=1 8
dd: reading `standard input': Resource temporarily unavailable
0+0 records in
0+0 records out
0 bytes (0 B) copied, 3.2 seconds, 0.0 kB/s
I tracked down the problem and made the attached patch to get the
guard mutex, which I believe was cgf's intention when he put get_guard
(I'm guessing from the changelogs, here), since the previous code was
a no-op.
2006-05-15 Lev Bishop [EMAIL PROTECTED]
* select.cc (fhandler_pipe::ready_for_read): Actually get the
guard mutex.
However, although this improves things, the nonblocking read can
still block for the duration of one read in the other process. I
deduce that, despite the msdn article on PeekNamedPipe:
The function always returns immediately, even if there is no data in the
pipe. The wait mode of a named pipe handle (blocking or nonblocking) has
no effect on the function.
...actually it can block for the duration of another process's
blocking read. Presumably, windows has an internal guard mutex of it's
own.
There are 2 questions I have related to this:
1) Why does cygwin go to all the trouble of having guard mutexes and
so on for it's pipes, to simulate nonblocking operations (imperfectly
for pipe reads, not at all for pipe writes) when there's the
PIPE_NOWAIT flag available which appears to do it in a built-in
fashion? Has this been considered and rejected for some reason I can't
think of?
2) In my example above I had 2 descriptors to the same pipe, one set
blocking and one nonblocking. Unix behaviour doesn't allow this
because O_NONBLOCK applies to the file description, not to a
particular file descriptor. The same goes for O_APPEND, O_ASYNC, etc.
For full unix compatibility these flags (and I would guess various
parts of the fhandler_xxx structures, like my fhandler_socket::chunk)
would have to be put in shared regions or similar. Has something like
this been contemplated?
Consider this patch untested at present.
L
Index: select.cc
===
RCS file: /cvs/src/src/winsup/cygwin/select.cc,v
retrieving revision 1.123
diff -u -p -d -r1.123 select.cc
--- select.cc 24 Apr 2006 15:16:45 - 1.123
+++ select.cc 21 May 2006 00:56:04 -
@@ -689,14 +689,18 @@ pipe_cleanup (select_record *, select_st
int
fhandler_pipe::ready_for_read (int fd, DWORD howlong)
{
- int res;
+ int res = true;
+ const HANDLE w4[2] = {signal_arrived, get_guard ()};
if (howlong)
-res = true;
+{
+ if (w4[2] WAIT_OBJECT_0 == WaitForMultipleObjects (2, w4, 0,
INFINITE))
+ {
+ set_sig_errno (EINTR);
+ return 0;
+ }
+}
else
res = fhandler_base::ready_for_read (fd, howlong);
-
- if (res)
-get_guard ();
return res;
}
Re: service interact with desktop broken between: 1.5.5 1.5.19
On 3/26/06, Corinna Vinschen wrote: Thanks Lev, I've integrated this into the new 1.13-1 version of cygrunsrv which I just uploaded to cygwin.com. Thanks, Corinna. I can almost get it working now. Maybe you can explain why this works: $ cygrunsrv -I cygtest -jid 'cygrunsrv test' -p '/cygdrive/c/i386/cmd.exe' \ -0/dev/console -1/dev/console -2/dev/console Giving me a console running cmd.exe that I can, for example run bash in. Whereas it fails if I put -p '/bin/bash' directly for the command. I experimented, and found that if I do the following: $ cygrunsrv -I cygtest -jid 'cygrunsrv test' -p '/bin/bash' -a $'-c \ echo this is on STDOUT;\ echo this is on STDERR 2;\ ls -l /proc/self/fd;\ read -p \'Give me something on STDIN: \' input;\ echo input was $input ' \ -0/dev/console -1/dev/console -2/dev/console Then I get a console window showing the messages to stdout and stderr, the /proc/self/fd listing confirms that fd0 is open on /dev/console, but the 'read' builtin hangs and doesn't read anything. So it looks like standard input isn't getting properly mapped in this case, even though stdout and stderr are. cygcheck.out attached in case it's relevant. Lev cygcheck.out Description: Binary data -- 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: service interact with desktop broken between: 1.5.5 1.5.19
Can't tell you why this isn't working for you (I wasn't able to make it work either). But looking at the cygrunsrv sources I noticed something else that doesn't look quite right: In cygrunsrv.cc:print_service(): if (interact) strcat (tmp, --nohide ); I assume what is intended is: if (interact showc) strcat (tmp, --nohide ); This isn't what's stopping you from doing what you want to do, though, since it's just the display routine. Lev -- 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: Why only 1 cygwin1.dll?
FAQ candidate? Either of Eric's explanations seem spot on, to me. And this question does come up fairly regularly. Lev -- 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: Why only 1 cygwin1.dll?
On 3/25/06, Christopher Faylor wrote: It is not 100% complete but I guess something like that should be in the FAQ under a heading of: Q) I see the way you're doing things and I don't agree. Certainly I know more about this then you do. Please prove me wrong, although I doubt that you can. Go ahead, I dare you? Then we can include descriptions of why there should be only one version of cygwin1.dll. Why /dev isn't the perfect replacement for /cygdrive. Why we don't default to c:\ as the root directory for cygwin. Why setup.exe doesn't install everything by default. Why setup.exe installs so much by default. and why -mno-cygwin really does produce binaries that have nothing to do with cygwin and, so, therefore, discussion of said binaries doesn't belong here. We do already have FAQs for Why not install in C:\? and Why the weird directory structure?. There is a FAQ for How do I compile a Win32 executable that doesn't use Cygwin? but it doesn't specifically mention that discussion of the binaries doesn't belong here (and in fact specifically says that -mno-cygwin should not be confused with mingw -- whereas when someone asks about -mno-cygwin on this ML everyone always directs them to talk to the mingw lists). There already is How do I just get everything? which sort of explains why setup downloads as much/little as it does. I couldn't see any FAQ for why /dev doesn't replace /cygdrive though. If you're saying that you this kind of question shouldn't be humoured, then maybe just: Q) I see the way you're doing things and I don't agree. Certainly I know more about this then you do. Please prove me wrong, although I doubt that you can. Go ahead, I dare you? A) See: http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5content-type=text/plaincvsroot=src http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygtls-works.txt?rev=1.1content-type=text/plaincvsroot=src See also: http://cygwin.com/acronyms/#WCTYBTWHTKY Lev -- 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: service interact with desktop broken between: 1.5.5 1.5.19
Another bug in cygrunsrv.cc:main() (again not the reason for this problem) --- cygrunsrv.cc.old2006-03-25 13:49:08.238075200 -0500 +++ cygrunsrv.cc2006-03-25 13:50:35.473513600 -0500 @@ -1930,14 +1930,14 @@ case '1': if (action != Install) return error (IONotAllowed); - if (in_stdin) + if (in_stdout) return error (OnlyOneIO); in_stdout = optarg; break; case '2': if (action != Install) return error (IONotAllowed); - if (in_stdin) + if (in_stderr) return error (OnlyOneIO); in_stderr = optarg; break; On 3/25/06, Lev Bishop wrote: Can't tell you why this isn't working for you (I wasn't able to make it work either). But looking at the cygrunsrv sources I noticed something else that doesn't look quite right: In cygrunsrv.cc:print_service(): if (interact) strcat (tmp, --nohide ); I assume what is intended is: if (interact showc) strcat (tmp, --nohide ); -- 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: Redirect stdin stdout to serial port
On 3/20/06, D.Pageau wrote: no permission denied but output is still stdout This is expected, because operator says to open for read/write on descriptor 0. It doesn't say anything about stdout. /dev/ttyS0 0 no permission denied but output is not redirected to /dev/ttyS0, not stdout either. This is also expected, since ttyS0 was opened for reading, so you can't write on it, even if you do attach it to stdout. I think the solution might be a combination of both of Igor's suggestions cmnd /dev/ttyS0 0 Ie, open the port read/write on stdin and then dup it to stdout. Let me know if that works. Lev -- 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: Problems with ash-20040127-3 (Attn: bash maintainer)
On 08/07/05, Eric Blake wrote:
Meanwhile, you will have to wait patiently until the upstream
maintainer releases a patch (because I haven't the faintest clue
where in the lexer to look for fixing his parse error). Repeated
pinging on the cygwin list will not help speed up the situation.
In bash 2.05b, file parse.y, line 2179ish:
else if MBTEST(was_dollar (ch == '(' || ch == '{' || ch ==
'[')) /* ) } ] */
/* check for $(), $[], or ${} inside quoted string. */
Maybe something like:
else if MBTEST(open=='' was_dollar (ch == '(' || ch == '{'
|| ch == '[')) /* ) } ] */
/* check for $(), $[], or ${} inside quoted string. */
Might do the trick?
I haven't tried it. Would need testing from someone who understands
POSIX quoting in detail, to ensure it doesn't break other convoluted
quoting rules...
--
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: Broken parse on `'${'`
On 07/07/05, Eric Blake wrote:
zsh$ bash
bash$ echo `echo '${'`
# Hmm - I was just incorrectly presented PS2, asking to try to continue
what bash thought was an incomplete ${ variable substitution
Actually, this is a bad example, because even if bash did parse
correctly, there would be still an incomplete ${ substitution for the
outer echo
--
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: SV: Bug in printf ?
I don't think there is any bug here. This is what I've seen from a
little digging:
1) cygwin strtod rounds to even, with about DECIMAL_DIG (==21) digits
precision, as recommended by 7.20.1.3 of WG14/N843. (It acts strange
when the rounding mode is not round to nearest, but since newlib
doesn't provide fesetround(), that's your own problem if you insist on
changing rounding mode by hand, as I understand it).
2) cygwin gcc rounds with *lots* more precision than DECIMAL_DIG,
about 50 digits. It rounds towards zero. These behaviours are a little
different than the recommendation in 6.4.4.2 Ibid., which says
constants should be converted as if by strtod() at runtime, but its
not a big difference.
3) cygwin printf correctly rounds to even, even out to about 41 digits.
4) I have no idea what mingw is doing, but it's different to the
above. Gcc constructs the same double precision constants as on cygwin
but strtod() is different and seems to have less precision, and
printf() seems to work with about 16 digits precision. At a glance I'd
say it rounds to zero, with exactly the precision of
On 05/07/05, Dave Korn wrote:
Stepping through the code at the weekend, I followed the 0.105 case as far
down as ldtoa_r, where I observed that although there was code that would
round 0.105 up to 0.11 if asked for only two sig.figs, the loop that
generates successive digits was coming up with the sequence
'0.104.', and because the rounding only looks at one digit
beyond the requested s.f., it 'correctly' rounds 0.104 down to 0.10.
The closest double to 0.105 is actually
0.10499611421941381195210851728916168212890625, and this
is what printf() is (correctly) handed, and what it (correctly) rounds
to 0.10.
I say 'correctly' in quotes, because it's the correct way to round 0.104,
but it's not in general correct to round a number by truncating it and then
rounding the truncated version.
But I don't think that truncating it and then rounding the truncated
version is what printf() does. If we give it 0.125 and 0.375, which
are both representible exactly, then it rounds to 0.12 and 0.38, ie
one goes up and one goes down, to round to even. You can see it's not
simply truncating if you give it 0.1251, which gets
rounded to 0.13 not 0.12 as it would for truncation.
To summarize: cygwin does the right thing
#include stdio.h
#include stdlib.h
#include math.h
#include float.h
#ifdef __MINGW32__
#include fenv.h
#endif
// show the hex and decimal interpretations of the double
union U{double d;unsigned char c[8];};
void display(union U x)
{
for(int b=7;b=0;b--)printf(%02x,x.c[b]);
printf( %.21f,x.d);
}
int main(int argc, const char**argv)
{
#ifdef __MINGW32__
if (argc = 2)
{
int nrm, n;
n = sscanf (argv[1], %i, nrm);
if (n == 1) switch (nrm)
{
case 0:
case 0x400:
case 0x800:
case 0xc00:
fesetround (nrm);
}
}
printf (Rmode $%08x\n, fegetround ());
#endif
printf(DECIMAL_DIG=%d\n,DECIMAL_DIG);
#define PASTE(x) {.s=#x,.d1=strtod(#x,0),.d2=x}
struct S {const char*s;union U d1,d2;}q[]=
{
// test the rounding with the last digits...
// first right on the boundary, to test round-to-even
PASTE(1.000), // 1
PASTE(1.0001110223024625156540423631668090820312500), // 1 +
2^-53
PASTE(1.0002220446049250313080847263336181640625000), // 1 +
2^-52
PASTE(1.0003330669073875469621270895004272460937500), // 1 +
2^-52 +2^-53
{0},
// now just above the boundary
PASTE(1.0001),
PASTE(1.00011103),
PASTE(1.00022205),
PASTE(1.00033307),
{0},
// now just below the boundary
PASTE(0.),
PASTE(1.00011101),
PASTE(1.00022204),
PASTE(1.00033301),
{0},
PASTE(0.105),
};
printf( 1.23456789012345678901234567890\n); // for counting
sig figs
for(int a=0;asizeof(q)/sizeof(struct S);a++)
{
if(!q[a].s){printf(\n);continue;}
display(q[a].d1);
printf( );
display(q[a].d2);
printf(\n);
}
printf(\n);
union U w[]={0.105,0.115,0.125,0.135,0.145,0.155,0.375};
for(int a=0;asizeof(w)/sizeof(union U);a++)
{
display(w[a]);
printf(\n);
}
printf(%.40f\n,0.105);
// here's some numbers with an exact representation in double
printf(%.20f %.2f\n,.125,.125);
printf(%.20f %.2f\n,.375,.375);
printf(%.20f %.13f\n,0.9536743164062500,0.9536743164062500);
printf(%.20f %.17f\n,3.5096855163574218750,3.5096855163574218750); // 1 +
657899/2^18
printf(%.20f %.15f\n,-1.5035324096679687500,-1.5035324096679687500);
// how many digits precision does gcc use when making double constants?
Re: SV: Bug in printf ?
On 06/07/05, Lev Bishop wrote: 4) I have no idea what mingw is doing, but it's different to the above. Gcc constructs the same double precision constants as on cygwin but strtod() is different and seems to have less precision, and printf() seems to work with about 16 digits precision. At a glance I'd say it rounds to zero, with exactly the precision of ... the precision of a raw double. Ie, it looks like the cygwin build works slightly nicer than mingw with plenty of extra precision for conversions to and from decimal, and round-to-even for runtime conversions, which is a good thing. -- 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: chmod suddenly ceased to work on old files - AFTER CYGWIN UPDATE
On 05/07/05, FischRon wrote: Actually I wasn't able to use -d with mkpasswd, because this command hung, so I did a mkpasswd -l /etc/passwd instead. Maybe I should rerun mkgroup -l (without -d option)? Really hung, or just taking a very very long time (it will, if it is a large domain)? If the latter, you could try using the -c and/or -u options to mkpasswd to only get the information for a subset of the users (ie just the ones who use your machine). Or construct the /etc/passwd file by hand if you know what you're doing But in any case, recreating the /etc/group file did nothing to remedy my problem. What kind of server are these files on? If it is a SAMBA share (on eg linux, as opposed to a SMB share from WinNT), then maybe this message is helpful: http://www.cygwin.com/ml/cygwin/2000-12/msg00567.html Otherwise if it is an SMB share, maybe you need to give your accounts (both locally and on the server) the restore files and directories (SeRestorePrivilege) privilege, which may not be practical as its a security hole. Though from reading the mailing list archives it seems that so long as the machines are part of a domain and your user account is a domain account, then this is supposed to be unnecessary. Finally, you could always set the CYGWIN environment variable to include 'nosmbntsec' to switch off all use of ntsec on shares. Lev -- 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: launch windows program from shell according to its extension
On 08/06/05, zzapper wrote: Slightly improved to ignore directories (and assuming that Windows files always have an extension) cygstart $(/bin/ls -t *.* | head -1) why not cygstart $(/bin/ls -t . | head -1) ? -- 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: Wildcards in the path name parameter
On 26/05/05, Coetzee, Evert wrote: But I'm running it from the cmd.exe command prompt. I'm not in a shell. cp: cannot stat `/cygdrive/c/*.*': No such file or directory That is the error I get now. Do you have noglob in your CYGWIN environment variable? http://cygwin.com/problems.html Lev -- 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: [ANNOUNCEMENT] Updated: binutils-20050520-1
I don't have much clue what I'm doing with binutils, but I've managed
to cause a SEGV in objdump. Here's how:
$ cat a.c
int main (void)
{
int i=1;
i++;
return i;
}
$ gcc a.c
$ objcopy -O elf32-i386 a.exe
$ objcopy -O pei-i386 a.exe
$ objdump -x a.exe
a.exe: file format pei-i386
a.exe
architecture: i386, flags 0x0132:
EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x00401000
Characteristics 0x307
relocations stripped
executable
line numbers stripped
32 bit words
debugging information removed
Time/Date Wed May 25 06:43:15 2005
ImageBase
SectionAlignment
FileAlignment
MajorOSystemVersion 0
MinorOSystemVersion 0
MajorImageVersion 0
MinorImageVersion 0
MajorSubsystemVersion 0
MinorSubsystemVersion 0
Win32Version
SizeOfImage
SizeOfHeaders 0400
CheckSum00010ed7
Subsystem (unspecified)
DllCharacteristics
SizeOfStackReserve
SizeOfStackCommit
SizeOfHeapReserve
SizeOfHeapCommit
LoaderFlags
NumberOfRvaAndSizes 0010
The Data Directory
Entry 0 Export Directory [.edata (or where ever we found it)]
Entry 1 00405000 01f0 Import Directory [parts of .idata]
Entry 2 Resource Directory [.rsrc]
Entry 3 Exception Directory [.pdata]
Entry 4 Security Directory
Entry 5 Base Relocation Directory [.reloc]
Entry 6 Debug Directory
Entry 7 Description Directory
Entry 8 Special Directory
Entry 9 Thread Storage Directory [.tls]
Entry a Load Configuration Directory
Entry b Bound Import Directory
Entry c Import Address Table Directory
Entry d Delay Import Directory
Entry e Reserved
Entry f Reserved
There is an import table in .idata at 0x405000
The Import Tables (interpreted .idata section contents)
vma:HintTime Forward DLL First
Table Stamp ChainName Thunk
00405000 5040 51c4 5088
Segmentation fault (core dumped)
This happens with the new binutils and also the previous version.
(What I was actually hoping to do above was to remove/normalize the
time/date header in pei-i386, so that my executables are repeatable
functions of their sources, so I can checksum/fingerprint them in my
build system. Clearly my above attempts failed, so does anybody know
of a way to acheive this?)
Lev
--
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: [ANNOUNCEMENT] Updated: binutils-20050520-1
On 25/05/05, Dave Korn wrote: Original Message From: Lev Bishop Sent: 25 May 2005 11:54 Yow. So you copy it from a PE to an ELF, and then back to PE? You very much need to read the section on canonicalisation in the bfd section of the ld manual. info ld then search for BFD information loss. Yeah, I saw that. I wasn't really expecting the exe to still run after this or anything, just that it would be something I could get a reliable fingerprint from. In fact the reason I was doing this is that I *wanted* to lose information (the date/time field in particular). Segmentation fault (core dumped) This happens with the new binutils and also the previous version. Yup, so something vital didn't get carried over to the ELF format, or didn't get converted back. To be expected really. Well, I wasn't really expecting it to work, just stabbing in the dark. However, from the binutils info file Bug Criteria section: ] If you are not sure whether you have found a bug, here are some ] guidelines: ] ] * If a binary utility gets a fatal signal, for any input whatever, ] that is a bug. Reliable utilities never crash. And from the Bug Reporting section: ] A number of companies and individuals offer support for GNU ] products. If you obtained the binary utilities from a support ] organization, we recommend you contact that organization first. I assumed support organization==Cygwin, and thought I'd better be a good citizen and mention the crash. Anyway, thanks DaveK for the hint to look at the gcc bootstrap files. Lev -- 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/
