Re: rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
On 2/14/2012 5:39 PM, Christopher Faylor wrote: On Tue, Feb 14, 2012 at 06:02:51PM -0500, Charles Wilson wrote: On 2/14/2012 6:00 PM, Charles Wilson wrote: On 2/14/2012 1:05 PM, Hans Horn wrote: something in the recent post-1.7.10(0.259/5/3) cygwin snapshots (20120207..20120214) broke rxvt. I'll need a few more details than "it broke rxvt". vis. cgf's reply, never mind... If the breakage wasn't so obvious, I would have had the same response. But, really, there is no reason to assume that something is so obvious as to not provide details. *Please* when reporting a problem explain what the problem actually is. cgf I typically do. In this case: rxvt starts (I see window opening) and then disappears quickly, in other words, it is broken. H. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH *** fatal error - unable to load C:\WINDOWS\system32\user32.dll, Win32 error 1114
> On Feb 14 17:54, Charles Stepp wrote: > > > > Jim Garrison troux.com> writes: > > > > > > > > I'm consistently getting a stack trace when attempting to run a command > > > via > > ssh, using a dsa key, on a remote > > > Windows Server 2003 SP2 x64 that has Cygwin sshd installed and configured. > > The error is occurring at the > > > remote sshd process: > > > > > > $ ssh qaautotest1 ls > > > 2 [main] sshd 3156 D:\cygwin\usr\sbin\sshd.exe: *** fatal error > > > - > > unable to load > > > C:\WINDOWS\system32\user32.dll, Win32 error 1114 > > > Stack trace: > > > Frame Function Args > > > 002298B4 6102796B (002298B4, , , 0040) > > > ... > > > > I'm, also getting this error. See bottom of my comments...perhaps a cygwin > > vs > > Windows path problem. > > Does the FAQ help? > > http://cygwin.com/faq-nochunks.html#faq.using.sshd-in-domain > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat Yes it did! Essentially, it needs to be a domain user. I had to use my own domain ID. I added permissions through some hairy Windoze as recommended in the following link. http://ist.uwaterloo.ca/~kscully/CygwinSSHD_W2K3.html Thanks SO much! It must be a real PIA trying to emulate setuid stuff/ID switching stuff for these "Server" class Windoze versions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
Corinna Vinschen writes: > > > Does anybody know a system call which allows to fetch the network drive > > > state (connected/not connected) without a billion microsecond timeout? > > > > I just looked into this and I really don't see a way. While there's a > > NetUseGetInfo call, which is pretty fast even for unavailable drives, > > it's not reliable. Even if the drive is available again, it can take > > minutes in which it still returns a status of "Session lost". I'm not > > sure this is what we want. > > ...and the call doesn't work for NFS drives. Too bad. Does WNetGetConnection() do any better? It's referenced on the NetUseGetInfo() page in MSDN. Claims to support other providers besides SMB. Apart from that, is "net use" the mount table Ryan was referring to? Can we tell what it's doing to identify connected and disconnected drives? ..mark -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with tkinter after python upgrade on cygwin
Hans Peter, On Mon, Feb 13, 2012 at 05:23:37PM +0100, Hans Peter Jepsen wrote: > Dear Jason > > I hope you can help me. In the future, please heed the following: http://cygwin.com/acronyms/#PPIOSPE > I googled for an answer, but did not find any. What about the following Google search on "TclError: no display name and no $DISPLAY environment variable"? http://www.google.com/search?q=TclError%3A+no+display+name+and+no+%24DISPLAY+environment+variable The first item from the above search yields: http://www.linuxquestions.org/questions/programming-9/tcl-error-no-display-name-and-no-display-environment-variable-340184/ > My problem is, that after upgrading Cygwin and with that python and > tcl, and now get this error-message with a program, that worked > before: > > Traceback (most recent call last): > > File "ParamdbTool.py", line 445, in > > tkroot = tk.Tk() > > File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1643, in __init__ > > self.tk = _tkinter.create(screenName, baseName, className, interactive, > wantobjects, useTk, sync, use) > > _tkinter.TclError: no display name and no $DISPLAY environment variable > > > Do you have any ideas on how to get around this. You need to install X, define the DISPLAY environment variable, and start X. After these steps, your Tkinter program should work again. Jason -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
On Tue, Feb 14, 2012 at 06:02:51PM -0500, Charles Wilson wrote: >On 2/14/2012 6:00 PM, Charles Wilson wrote: >> On 2/14/2012 1:05 PM, Hans Horn wrote: >>> something in the recent post-1.7.10(0.259/5/3) cygwin snapshots >>> (20120207..20120214) broke rxvt. >> >> I'll need a few more details than "it broke rxvt". > >vis. cgf's reply, never mind... If the breakage wasn't so obvious, I would have had the same response. But, really, there is no reason to assume that something is so obvious as to not provide details. *Please* when reporting a problem explain what the problem actually is. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
On 2/14/2012 6:00 PM, Charles Wilson wrote: > On 2/14/2012 1:05 PM, Hans Horn wrote: >> something in the recent post-1.7.10(0.259/5/3) cygwin snapshots >> (20120207..20120214) broke rxvt. > > I'll need a few more details than "it broke rxvt". vis. cgf's reply, never mind... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
On 2/14/2012 1:05 PM, Hans Horn wrote: > something in the recent post-1.7.10(0.259/5/3) cygwin snapshots > (20120207..20120214) broke rxvt. I'll need a few more details than "it broke rxvt". -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
On Tue, Feb 14, 2012 at 10:05:37AM -0800, Hans Horn wrote: >Folks, > >something in the recent post-1.7.10(0.259/5/3) cygwin snapshots >(20120207..20120214) broke rxvt. Even though this terminal is abandoned >it is still my favorite one due to its simple copy/past abilities. I >hate to see it go away. Don't worry. We don't intentionally break shipping applications. >Reverted to 1.7.10.. > >Any clues what might have caused this? Yes. The problem should be fixed in the latest snapshot. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: STC for libapr1 failure
On 2/14/2012 10:24 AM, Corinna Vinschen wrote:
> On Feb 14 09:58, David Rothenberger wrote:
>> On 2/14/2012 6:45 AM, Corinna Vinschen wrote:
>>> On Feb 14 15:02, Corinna Vinschen wrote:
On Feb 14 00:00, David Rothenberger wrote:
> The libapr1 test cases are failing again for flock locks. This same
> test case failed with 1.7.9 with a fatal error[1], but that was
> corrected. The test is no longer encountering the fatal error, but
> it is producing the wrong result.
Thanks for the testcase. I think I found the issue. An event handle
was closed in the wrong place, outside of the important mutex lock for
the lock object. I applied the patch to CVS. Your testcase now appears
to run fine for me. Can you try your entire testsuite again and see
if there's another failure lurking?
>>>
>>> I uploaded a snapshot for testing.
>>
>> Thanks. The snapshot fixes the flock test case, but now the fcntl test
>> case is failing.
>
> *Sob*. How so? Does it hang or does it allow multiple concurrent
> exclusive locks as the flock case?
Sorry, I should have said. It hangs.
>> I'll try to send an STC for that case, but I suspect the one from last
>> year will have the problem.
>
> Please send it anyway.
It's attached. If you run it with an argument (any argument), each child
will print its loop count and you can see what happens. If it doesn't
hang for you, try increasing MAX_ITER or CHILDREN at the top.
--
David Rothenberger daver...@acm.org
QOTD:
"Oh, no, no... I'm not beautiful. Just very, very pretty."
/***
* This is a STC to show that fcntl hangs.
*
* It tries to use fcntl() for file locking. It creates a temporary
* file, the uses fork to spawn a number of children. Each child opens
* the file, then repeatedly uses flock to lock and unlock it.
*
* While each child has the lock, it increments a counter stored in
* shared memory in a racy way, passing the current value to a function
* which sleeps briefly, then returns the incremented counter.
*
* If all works correctly, the counter should end up be incremented
* by each child iteration.
*
* However, this test currently just hangs.
*
* Compile: gcc -Wall -o stc-flock-fork stc-flock-fork.c
***/
#include
#include
#include
#include
#include
#include
#include
#define NUM_TEST_ITERS 1
#define MAX_ITER 10
#define CHILDREN 3
#define MAX_COUNT (MAX_ITER * CHILDREN)
/* Counter stored in shared memory. */
static volatile int *x;
/* A temporary file used for fcntl. */
char tmpfilename[] = "/tmp/fcntlXX";
struct flock mutex_lock_it;
struct flock mutex_unlock_it;
/* a slower more racy way to implement (*x)++ */
static int increment(int n)
{
usleep(1);
return n+1;
}
/* Fork and use fcntl to lock and unlock the file repeatedly in the child. */
void make_child(int childnum, int verbose, int trylock, pid_t *pid)
{
if ((*pid = fork()) < 0) {
perror("fork failed");
exit(1);
}
else if (*pid == 0) {
int fd2 = open(tmpfilename, O_RDWR);
if (fd2 < 0) {
perror("child open");
exit(1);
}
int rc;
int i;
for (i=0; i 1) ? 1 : 0;
/* Create the temporary file. */
fd = mkstemp(tmpfilename);
if (fd < 0) {
perror("open failed");
exit(1);
}
close(fd);
/* Initialize shared memory */
init_shm();
/* Setup mutexes */
mutex_lock_it.l_whence = SEEK_SET; /* from current point */
mutex_lock_it.l_start = 0; /* -"- */
mutex_lock_it.l_len = 0; /* until end of file */
mutex_lock_it.l_type = F_WRLCK; /* set exclusive/write lock */
mutex_lock_it.l_pid = 0; /* pid not actually interesting */
mutex_unlock_it.l_whence = SEEK_SET; /* from current point */
mutex_unlock_it.l_start = 0; /* -"- */
mutex_unlock_it.l_len = 0; /* until end of file */
mutex_unlock_it.l_type = F_UNLCK;/* set exclusive/write lock */
mutex_unlock_it.l_pid = 0; /* pid not actually interesting */
/* Perform the test multiple times. */
for (i = 0; i < NUM_TEST_ITERS; ++i) {
/* Create the children. */
for (n = 0; n < CHILDREN; n++)
make_child(n, verbose, 0, &child[n]);
/* Wait for them to finish. */
for (n = 0; n < CHILDREN; n++)
await_child(child[n]);
/* Check counter */
if (*x != MAX_COUNT) {
printf("Iteration %d: FAILED: *x (%d) != MAX_COUNT (%d)\n", i, *x,
MAX_COUNT);
exit(1);
}
}
/* Clean up. */
unlink(tmpfilename);
return 0;
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Re: PROGRAMFILES variable is not set during openssh session
Greetings, Corinna Vinschen! >> > >> PROGRAMFILES variable is not set during openssh session. >> > >> This is very important for remote administrative tasks. >> > >> > > OpenSSH 6.0p1 is due soon. I asked to apply a patch upstream so that >> > > PROGRAMFILES is added back to the environment variables passed over >> > > to the child process. >> > >> > Both of them? (on x86_64 systems, there's two relevant variables) >> >> Argh. Can of worms. No, only the 32 bit variant for now. > Oh, btw., 32 bit processes only see the 32 bit PROGRAMFILES variable > by default. Which makes sense since PROGRAMFILES for 32 bit processes > is the same as PROGRAMFILES for 64 bit processes... I can't say that I understood your reply, I'll just go into hiding thinking that you know what you doing >.> -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.02.2012, <01:18> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
need help with perl script and rsync
Hello, We use ActiveState perl in a backup processes at my work. A programmer created a perl script to create an incremental backup using rsync. The script does not do the incremental backup, just a full backup. It worked in winxp, but now that we are using it on win7 its not incrementing. I cannot get in contact with the programmer. Is there someone here that can look at the script and find out what the issue is? Mahalo, Kasi -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sed strips CRs
Greetings, Earnie Boyd! >>> The standard response to issues dealing with CRLF files is to point the >>> user to dos2unix and text mode mounts. This should be adequate without >>> the hidden behavior of sed/grep/awk and probably others. >> >> While your reasoning is sound, I prefer them to behave the way they are for >> my >> own goals. >> I can't possible alter between text and binary mounts, or use d2u on and off >> in an attempt to produce consistent and predictable end results. > Consistent behavior is what I see as the issue. IMO, sed, grep and > awk should behave the same as on UNIX for consistent and predictable > behavior. Treating CR as white space not only helps the Windows user > it also helps the Unix user when Windows files are transferred to it. > I know that for sed at least treating CR as white space works very > well. Most apparent: it breaking EOL matches. -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.02.2012, <01:12> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On 14/02/2012 12:57 PM, Corinna Vinschen wrote: On Feb 14 12:46, Ryan Johnson wrote: On 14/02/2012 11:26 AM, Corinna Vinschen wrote: On Feb 14 10:47, Ryan Johnson wrote: On 14/02/2012 10:17 AM, Corinna Vinschen wrote: Does anybody know a system call which allows to fetch the network drive state (connected/not connected) without a billion microsecond timeout? [...] What if we parsed the mount table instead of calling readdir? I don't know how that's computed, but it's never been a performance problem, it only shows drives that are actually connected [...] What mount table? Cygwin's? It calls GetFileAttributes on the drive's root dir as well... This is bizarre... what would cause calls to the same Windows API function behave so differently when called by stat vs ls vs bash-autocomplete? I'm happy to accept that there's some weirdness on my box, but I would have expected that weirdness to be consistent at any given instant in time (either all go slow or all behave normally). SMB just is not consistent. More often than not the timing behaviour is just plain puzzeling. And, btw., in *my* testing I got hangs in mount as well if I disabled the remote share. But only once. Subsequent calls were fast. And after enabling the remote share, mount happily ignored that fact for about a minute or so. Caching, anybody? Heisenburg? Impossible to know both what SMB share a mount points to and whether it's currently connected? It's really unfortunate Windows doesn't have a GetLocalDrives() or GetAccessibleDriveLetters() function. Actually, isn't there a function to convert DOS paths to those funky //?/ paths? Maybe that would be both fast and give enough information to keep stat() happy; readdir() would still be out of luck tho. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question About G++ Library in Cygwin
On 2/14/2012 2:24 PM, Jia Wu wrote:
Hi,
I just installed the latest version of Cygwin, selecting Devel,
Database and Interpreter packages. When I try to compile a very simple
Hello.cpp, I got some problems.
Hello.cpp code:
#include
int main()
{
std::cout<< "Hello, World!"<< std::endl;
}
Error report:
$ gcc hello.cpp
In file included from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/postypes.h:42:0,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/iosfwd:42,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ios:39,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ostream:40,
from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/iostream:40,
from hello.cpp:2:
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:145:11: error:
‘::fgetws’ has not been declared
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:147:11: error:
‘::fputws’ has not been declared
...
Please tell me what is problem and how should I figure it out! Many thanks!!
You're using the wrong front-end. Use g++.
--
Larry
_
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Question About G++ Library in Cygwin
Hi,
I just installed the latest version of Cygwin, selecting Devel,
Database and Interpreter packages. When I try to compile a very simple
Hello.cpp, I got some problems.
Hello.cpp code:
#include
int main()
{
std::cout << "Hello, World!" << std::endl;
}
Error report:
$ gcc hello.cpp
In file included from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/postypes.h:42:0,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/iosfwd:42,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ios:39,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ostream:40,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/iostream:40,
from hello.cpp:2:
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:145:11: error:
‘::fgetws’ has not been declared
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:147:11: error:
‘::fputws’ has not been declared
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:151:11: error:
‘::getwc’ has not been declared
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:152:11: error:
‘::getwchar’ has not been declared
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:157:11: error:
‘::putwc’ has not been declared
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/cwchar:158:11: error:
‘::putwchar’ has not been declared
In file included from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/locale_facets.h:43:0,
from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/basic_ios.h:39,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ios:45,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ostream:40,
from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/iostream:40,
from hello.cpp:2:
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:44:35:
error: ‘_U’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:45:32:
error: ‘_L’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:46:32:
error: ‘_U’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:46:37:
error: ‘_L’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:47:32:
error: ‘_N’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:48:33:
error: ‘_X’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:48:38:
error: ‘_N’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:49:32:
error: ‘_S’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:50:32:
error: ‘_P’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:50:37:
error: ‘_U’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:50:42:
error: ‘_L’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:50:47:
error: ‘_N’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:50:52:
error: ‘_B’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:51:32:
error: ‘_P’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:51:37:
error: ‘_U’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:51:42:
error: ‘_L’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:51:47:
error: ‘_N’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:52:32:
error: ‘_C’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:53:32:
error: ‘_P’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:54:32:
error: ‘_U’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:54:37:
error: ‘_L’ was not declared in this scope
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/ctype_base.h:54:42:
error: ‘_N’ was not declared in this scope
Please tell me what is problem and how should I figure it out! Many thanks!!
Best,
Jia Wu
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: STC for libapr1 failure
On Feb 14 09:58, David Rothenberger wrote: > On 2/14/2012 6:45 AM, Corinna Vinschen wrote: > > On Feb 14 15:02, Corinna Vinschen wrote: > >> On Feb 14 00:00, David Rothenberger wrote: > >>> The libapr1 test cases are failing again for flock locks. This same > >>> test case failed with 1.7.9 with a fatal error[1], but that was > >>> corrected. The test is no longer encountering the fatal error, but > >>> it is producing the wrong result. > >> > >> Thanks for the testcase. I think I found the issue. An event handle > >> was closed in the wrong place, outside of the important mutex lock for > >> the lock object. I applied the patch to CVS. Your testcase now appears > >> to run fine for me. Can you try your entire testsuite again and see > >> if there's another failure lurking? > > > > I uploaded a snapshot for testing. > > Thanks. The snapshot fixes the flock test case, but now the fcntl test > case is failing. *Sob*. How so? Does it hang or does it allow multiple concurrent exclusive locks as the flock case? > I'll try to send an STC for that case, but I suspect the one from last > year will have the problem. Please send it anyway. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
On Feb 14 10:05, Hans Horn wrote: > Folks, > > something in the recent post-1.7.10(0.259/5/3) cygwin snapshots > (20120207..20120214) broke rxvt. Even though this terminal is > abandoned it is still my favorite one due to its simple copy/past > abilities. I hate to see it go away. > Reverted to 1.7.10.. > > Any clues what might have caused this? No, but if you're using rxvt for it's simple copy/paste, why don't you use mintty instead, which provides the same type of simple copy/paste? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH *** fatal error - unable to load C:\WINDOWS\system32\user32.dll, Win32 error 1114
On Feb 14 17:54, Charles Stepp wrote: > > Jim Garrison troux.com> writes: > > > > > I'm consistently getting a stack trace when attempting to run a command via > ssh, using a dsa key, on a remote > > Windows Server 2003 SP2 x64 that has Cygwin sshd installed and configured. > The error is occurring at the > > remote sshd process: > > > > $ ssh qaautotest1 ls > > 2 [main] sshd 3156 D:\cygwin\usr\sbin\sshd.exe: *** fatal error - > unable to load > > C:\WINDOWS\system32\user32.dll, Win32 error 1114 > > Stack trace: > > Frame Function Args > > 002298B4 6102796B (002298B4, , , 0040) > > ... > > I'm, also getting this error. See bottom of my comments...perhaps a cygwin vs > Windows path problem. Does the FAQ help? http://cygwin.com/faq-nochunks.html#faq.using.sshd-in-domain Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: {ming/libming1/libming-devel/perl-ming/python-ming/tcl-ming}-0.4.4-1: A SWF output library
Hi New versions of 'ming/libming1/libming-devel/perl-ming/python-ming/tcl-ming' have been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 o tcl-ming linked against the Unix version of tcl o tcl-ming now provides a pkgIndex.tcl file and installs below TCL_LIBDIR ming NEWS: === * Generally improve swftoscript and decompiler * Change makefdb to name output files by font ID, to play nicer with swftoscript. * Add support for 'class A extends B' syntax in actioncompiler * Fix bug in 'makeswf' failing to catch some compile errors (bugzilla #94) and being too silent in swf embedding errors * Fix bug in action compiler dealing with class methods (bugzilla #94) * Add support for libpng > 1.4 (bugzilla #96) * Add font kernings support (bugzilla #95) * Add button characters export capabilities * Add support for 'swfAction ' syntax in asm blocks CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
Folks, something in the recent post-1.7.10(0.259/5/3) cygwin snapshots (20120207..20120214) broke rxvt. Even though this terminal is abandoned it is still my favorite one due to its simple copy/past abilities. I hate to see it go away. Reverted to 1.7.10.. Any clues what might have caused this? Thx., H. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH *** fatal error - unable to load C:\WINDOWS\system32\user32.dll, Win32 error 1114
Jim Garrison troux.com> writes: > > I'm consistently getting a stack trace when attempting to run a command via ssh, using a dsa key, on a remote > Windows Server 2003 SP2 x64 that has Cygwin sshd installed and configured. The error is occurring at the > remote sshd process: > > $ ssh qaautotest1 ls > 2 [main] sshd 3156 D:\cygwin\usr\sbin\sshd.exe: *** fatal error - unable to load > C:\WINDOWS\system32\user32.dll, Win32 error 1114 > Stack trace: > Frame Function Args > 002298B4 6102796B (002298B4, , , 0040) > ... I'm, also getting this error. See bottom of my comments...perhaps a cygwin vs Windows path problem. Target server of ssh or scp or sftp: Info - Windoze 2003 sp2 CStepp@blahblahblah# uname -a CYGWIN_NT-5.2 blahblahblah 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin ssh blablahblah -l CStepp hostname Authentication successful. 7 [main] sshd 1324 D:\cygwin\usr\sbin\sshd.exe: *** fatal error - unable to load C:\WINDOWS\system32\user32.dll, Win32 error 1114 Stack trace: Frame Function Args 002297D4 6102F96B (002297D4, , , ) 00229AC4 6102F96B (6119BD20, 8000, , 6119DB0F) 0022AAF4 61005F0C (6119D140, 0022AB20, 77E5C70B, 0022AB44) ... This is from an HP-UX sever or my pc running cygwin to the Windoze 2003 host. # HM... !!! # CStepp@blahblahblah# ls -lart C:\WINDOWS\system32\user32.dll ls: cannot access C:WINDOWSsystem32user32.dll: No such file or directory CStepp@blahblahblah# ls -lart C:\\WINDOWS\\system32\\user32.dll cygwin warning: MS-DOS style path detected: C:\WINDOWS\system32\user32.dll Preferred POSIX equivalent is: /cygdrive/c/WINDOWS/system32/user32.dll CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames -rwxr-xr-x 1 CStepp Domain Users 583680 Mar 1 2007 C:\WINDOWS\system32\user32.dll -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: STC for libapr1 failure
On 2/14/2012 6:45 AM, Corinna Vinschen wrote: > On Feb 14 15:02, Corinna Vinschen wrote: >> On Feb 14 00:00, David Rothenberger wrote: >>> The libapr1 test cases are failing again for flock locks. This same >>> test case failed with 1.7.9 with a fatal error[1], but that was >>> corrected. The test is no longer encountering the fatal error, but >>> it is producing the wrong result. >> >> Thanks for the testcase. I think I found the issue. An event handle >> was closed in the wrong place, outside of the important mutex lock for >> the lock object. I applied the patch to CVS. Your testcase now appears >> to run fine for me. Can you try your entire testsuite again and see >> if there's another failure lurking? > > I uploaded a snapshot for testing. Thanks. The snapshot fixes the flock test case, but now the fcntl test case is failing. I'll try to send an STC for that case, but I suspect the one from last year will have the problem. -- David Rothenberger daver...@acm.org QOTD: "I drive my car quietly, for it goes without saying." -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On Feb 14 12:46, Ryan Johnson wrote: > On 14/02/2012 11:26 AM, Corinna Vinschen wrote: > >On Feb 14 10:47, Ryan Johnson wrote: > >>On 14/02/2012 10:17 AM, Corinna Vinschen wrote: > >>>Does anybody know a system call which allows to fetch the network drive > >>>state (connected/not connected) without a billion microsecond timeout? > >>[...] > >>What if we parsed the mount table instead of calling readdir? I > >>don't know how that's computed, but it's never been a performance > >>problem, it only shows drives that are actually connected [...] > >What mount table? Cygwin's? It calls GetFileAttributes on the drive's > >root dir as well... > This is bizarre... what would cause calls to the same Windows API > function behave so differently when called by stat vs ls vs > bash-autocomplete? I'm happy to accept that there's some weirdness > on my box, but I would have expected that weirdness to be consistent > at any given instant in time (either all go slow or all behave > normally). SMB just is not consistent. More often than not the timing behaviour is just plain puzzeling. And, btw., in *my* testing I got hangs in mount as well if I disabled the remote share. But only once. Subsequent calls were fast. And after enabling the remote share, mount happily ignored that fact for about a minute or so. Caching, anybody? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On 14/02/2012 11:26 AM, Corinna Vinschen wrote: On Feb 14 10:47, Ryan Johnson wrote: On 14/02/2012 10:17 AM, Corinna Vinschen wrote: Does anybody know a system call which allows to fetch the network drive state (connected/not connected) without a billion microsecond timeout? [...] What if we parsed the mount table instead of calling readdir? I don't know how that's computed, but it's never been a performance problem, it only shows drives that are actually connected [...] What mount table? Cygwin's? It calls GetFileAttributes on the drive's root dir as well... This is bizarre... what would cause calls to the same Windows API function behave so differently when called by stat vs ls vs bash-autocomplete? I'm happy to accept that there's some weirdness on my box, but I would have expected that weirdness to be consistent at any given instant in time (either all go slow or all behave normally). At least the problem has gone back into hiding for the moment... I guess I'll just have to hope Windows doesn't change its mind again for a while. Thanks for looking into this. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On Feb 14 18:18, Corinna Vinschen wrote: > On Feb 14 16:17, Corinna Vinschen wrote: > > So, even if we fix fstat, it doesn't solve the problem for readdir. The > > GetFileAttributes call is obviously supposed to find out if the drive is > > accessible. If not, it's omitted from the cygdrive dir. Unfortunately... > > > > Does anybody know a system call which allows to fetch the network drive > > state (connected/not connected) without a billion microsecond timeout? > > I just looked into this and I really don't see a way. While there's a > NetUseGetInfo call, which is pretty fast even for unavailable drives, > it's not reliable. Even if the drive is available again, it can take > minutes in which it still returns a status of "Session lost". I'm not > sure this is what we want. ...and the call doesn't work for NFS drives. Too bad. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On Feb 14 16:17, Corinna Vinschen wrote: > So, even if we fix fstat, it doesn't solve the problem for readdir. The > GetFileAttributes call is obviously supposed to find out if the drive is > accessible. If not, it's omitted from the cygdrive dir. Unfortunately... > > Does anybody know a system call which allows to fetch the network drive > state (connected/not connected) without a billion microsecond timeout? I just looked into this and I really don't see a way. While there's a NetUseGetInfo call, which is pretty fast even for unavailable drives, it's not reliable. Even if the drive is available again, it can take minutes in which it still returns a status of "Session lost". I'm not sure this is what we want. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On Feb 14 10:47, Ryan Johnson wrote: > On 14/02/2012 10:17 AM, Corinna Vinschen wrote: > >Does anybody know a system call which allows to fetch the network drive > >state (connected/not connected) without a billion microsecond timeout? > [...] > What if we parsed the mount table instead of calling readdir? I > don't know how that's computed, but it's never been a performance > problem, it only shows drives that are actually connected [...] What mount table? Cygwin's? It calls GetFileAttributes on the drive's root dir as well... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Spurious characters in USERPROFILE variable when running ssh
On Feb 8 18:51, Corinna Vinschen wrote: > On Feb 8 18:33, Kai-Mikael JÃÃ-Aro wrote: > > I have set up an sshd server on my Windows XP box. If I run the > > bash shell locally on the XP box, the USERPROFILE environment > > variable is shown as C:\Documents and Settings\Administrator but if > > I run ssh to the XP box, USERPROFILE displays as \??\C:\Documents > > and Settings\Administrator. > > Thanks for the report. I fixed that in CVS. Please try the next > (not yet created) developer snapshot fromhttp://cygwin.com/snapshots/ I just uploaded a new snashot. The snapshot worked perfectly (once I managed to install it ;-). Thank you very much! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On 14/02/2012 10:17 AM, Corinna Vinschen wrote: On Feb 14 09:44, Ryan Johnson wrote: On 14/02/2012 8:52 AM, Corinna Vinschen wrote: On Feb 14 08:37, Ryan Johnson wrote: (\??\C:\cygwin\cygdrive,0x28BB68) ^^^ This looks suspicious. I assume you're suffering from SMB network scanning. is there a workaround? Neither "always run elevated" nor "always keep all network drives mounted" seems like a reasonable requirement What are you expecting? Was my reply in http://cygwin.com/ml/cygwin/2012-02/msg00375.html not sufficient? The reply explains why running elevated avoids the problem -- apparently a side-effect of Windows' user token handling. It does not explain why it's a good idea to always run elevated to get a side effect that compensates for bad behavior which is arguably a bug (though that's what I'm doing right now for lack of a better option -- I often work off-grid, so I can't always have all network drives mapped). AFAICT, `stat /cydrive` runs into trouble because it enumerates all drive letters using GetFileAttributes, and only counts local drives as "links" to the "directory" : 2 + ndrives - nfloppies - nnonlocal. That's only for stat and, yes, that can be removed and the link set to 1, as for disk-based directories. But that's not all. GetFileAttributes is called in readdir as well, and if it works, the subsequent code tries to open the drive and fetch the inode number. The inode number is important because otherwise find(1) and other tools might print confused warnings. So, even if we fix fstat, it doesn't solve the problem for readdir. The GetFileAttributes call is obviously supposed to find out if the drive is accessible. If not, it's omitted from the cygdrive dir. Unfortunately... Does anybody know a system call which allows to fetch the network drive state (connected/not connected) without a billion microsecond timeout? I was also thinking about this readdir vs. stat thing after my last post... I've never noticed `ls /cygdrive` being a problem. This is why I thought it was emacs at first, and why I didn't notice z: at first. Strangely, bash auto-completion for `/cygdrive/^I` sometimes is fast and sometimes is slow. I was going to suggest doing in fhandler_cygdrive::fstat whatever fhandler_cygdrive::readdir does, but source diving confirms that the two functions do essentially the same thing (huh???). Even more strangely, none of my open terminals exhibits the problem right this minute, even though some of them have been open this whole time. There must be some external factor that makes Windows sometimes try to connect those drives and sometimes not. What if we parsed the mount table instead of calling readdir? I don't know how that's computed, but it's never been a performance problem, it only shows drives that are actually connected, and everything in /cygdrive should be mounted (if not, fhandler_cygdrive::readdir and stat are both broken). Thoughts? Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On Feb 14 09:44, Ryan Johnson wrote: > On 14/02/2012 8:52 AM, Corinna Vinschen wrote: > >On Feb 14 08:37, Ryan Johnson wrote: > >(\??\C:\cygwin\cygdrive,0x28BB68) > ^^^ > This looks suspicious. I assume you're suffering from SMB network > scanning. > >>>is there a workaround? Neither "always run elevated" nor "always > >>>keep all network drives mounted" seems like a reasonable > >>>requirement > >What are you expecting? Was my reply in > >http://cygwin.com/ml/cygwin/2012-02/msg00375.html not sufficient? > The reply explains why running elevated avoids the problem -- > apparently a side-effect of Windows' user token handling. > > It does not explain why it's a good idea to always run elevated to > get a side effect that compensates for bad behavior which is > arguably a bug (though that's what I'm doing right now for lack of a > better option -- I often work off-grid, so I can't always have all > network drives mapped). > > AFAICT, `stat /cydrive` runs into trouble because it enumerates all > drive letters using GetFileAttributes, and only counts local drives > as "links" to the "directory" : 2 + ndrives - nfloppies - nnonlocal. That's only for stat and, yes, that can be removed and the link set to 1, as for disk-based directories. But that's not all. GetFileAttributes is called in readdir as well, and if it works, the subsequent code tries to open the drive and fetch the inode number. The inode number is important because otherwise find(1) and other tools might print confused warnings. So, even if we fix fstat, it doesn't solve the problem for readdir. The GetFileAttributes call is obviously supposed to find out if the drive is accessible. If not, it's omitted from the cygdrive dir. Unfortunately... Does anybody know a system call which allows to fetch the network drive state (connected/not connected) without a billion microsecond timeout? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: STC for libapr1 failure
On Feb 14 15:02, Corinna Vinschen wrote: > On Feb 14 00:00, David Rothenberger wrote: > > The libapr1 test cases are failing again for flock locks. This same > > test case failed with 1.7.9 with a fatal error[1], but that was > > corrected. The test is no longer encountering the fatal error, but > > it is producing the wrong result. > > Thanks for the testcase. I think I found the issue. An event handle > was closed in the wrong place, outside of the important mutex lock for > the lock object. I applied the patch to CVS. Your testcase now appears > to run fine for me. Can you try your entire testsuite again and see > if there's another failure lurking? I uploaded a snapshot for testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On 14/02/2012 8:52 AM, Corinna Vinschen wrote:
On Feb 14 08:37, Ryan Johnson wrote:
Bump?
Stagger!
On 13/02/2012 8:31 AM, Ryan Johnson wrote:
On 11/02/2012 5:11 AM, Corinna Vinschen wrote:
On Feb 10 20:18, Ryan Johnson wrote:
Hi all,
For some reason file operations have become very slow inside emacs
starting yesterday. It's especially painful when saving a file
that's managed by mercurial (more than 20 seconds!), but I've seen
it on the command line as well (x-server takes a similar amount of
time to start, for example). I'm running the latest everything and
I've run rebaseall. I verified that Windows Defender did not
silently re-enable itself since I last disabled it (you can't
actually uninstall it) and no other BLODA are present on my machine.
The problem persists across reboots.
I have vague memories that this has turned up in the past (maybe
12-15 months ago?) but Google isn't turning up anything. Attaching
strace to emacs during the save makes it take a full 35 seconds and
reports the following:
$ cat emacs.strace | awk '{if ($1> 100) { print }}' | grep -v
timer_thread
26910790 26912157 [main] emacs-X11 5188 child_copy: dll bss - hp
0x264 low 0x611FC000, high 0x61230770, res 1
1128419 2125655 [main] python2.6 5188 read: read(5, 0x8009DB60,
65536) blocking
25850184 32830582 [main] python2.6 5188 stat_worker: 0 =
(\??\C:\cygwin\cygdrive,0x28BB68)
^^^
This looks suspicious. I assume you're suffering from SMB network
scanning.
is there a workaround? Neither "always run elevated" nor "always
keep all network drives mounted" seems like a reasonable
requirement
What are you expecting? Was my reply in
http://cygwin.com/ml/cygwin/2012-02/msg00375.html not sufficient?
The reply explains why running elevated avoids the problem -- apparently
a side-effect of Windows' user token handling.
It does not explain why it's a good idea to always run elevated to get a
side effect that compensates for bad behavior which is arguably a bug
(though that's what I'm doing right now for lack of a better option -- I
often work off-grid, so I can't always have all network drives mapped).
AFAICT, `stat /cydrive` runs into trouble because it enumerates all
drive letters using GetFileAttributes, and only counts local drives as
"links" to the "directory" : 2 + ndrives - nfloppies - nnonlocal. This
relies on the fact (a side effect?) that GetFileAttributes returns
ERROR_BAD_NETPATH for network shares (but apparently only after timing
out an attempt to connect disconnected ones). Not sure what happens for
USB drives (are they "floppies" ?). Is there no other way to enumerate
the local drives, and even if there isn't, does anybody actually care
about that particular link count? AFAIK, directory link counts only
matter when you want to run fsck (which cygwin doesn't have) or delete a
directory. Even if cygwin's rm pays attention to link counts, which I
doubt, anyone issuing `rm -rf /cygdrive` has far bigger problems on
their hands.
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: STC for libapr1 failure
On Feb 14 00:00, David Rothenberger wrote:
> The libapr1 test cases are failing again for flock locks. This same
> test case failed with 1.7.9 with a fatal error[1], but that was
> corrected. The test is no longer encountering the fatal error, but
> it is producing the wrong result.
Thanks for the testcase. I think I found the issue. An event handle
was closed in the wrong place, outside of the important mutex lock for
the lock object. I applied the patch to CVS. Your testcase now appears
to run fine for me. Can you try your entire testsuite again and see
if there's another failure lurking?
Btw., mmap is really simple. For your testcase that could be, for
instance:
#include
void init_shm ()
{
x = mmap (NULL, getpagesize (), PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
if (!x)
{
perror ("mmap failed");
exit (1);
}
}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
On Feb 14 08:37, Ryan Johnson wrote:
> Bump?
Stagger!
> On 13/02/2012 8:31 AM, Ryan Johnson wrote:
> >On 11/02/2012 5:11 AM, Corinna Vinschen wrote:
> >>On Feb 10 20:18, Ryan Johnson wrote:
> >>>Hi all,
> >>>
> >>>For some reason file operations have become very slow inside emacs
> >>>starting yesterday. It's especially painful when saving a file
> >>>that's managed by mercurial (more than 20 seconds!), but I've seen
> >>>it on the command line as well (x-server takes a similar amount of
> >>>time to start, for example). I'm running the latest everything and
> >>>I've run rebaseall. I verified that Windows Defender did not
> >>>silently re-enable itself since I last disabled it (you can't
> >>>actually uninstall it) and no other BLODA are present on my machine.
> >>>The problem persists across reboots.
> >>>
> >>>I have vague memories that this has turned up in the past (maybe
> >>>12-15 months ago?) but Google isn't turning up anything. Attaching
> >>>strace to emacs during the save makes it take a full 35 seconds and
> >>>reports the following:
> >>>
> >>>$ cat emacs.strace | awk '{if ($1> 100) { print }}' | grep -v
> >>>timer_thread
> >>>26910790 26912157 [main] emacs-X11 5188 child_copy: dll bss - hp
> >>>0x264 low 0x611FC000, high 0x61230770, res 1
> >>>1128419 2125655 [main] python2.6 5188 read: read(5, 0x8009DB60,
> >>>65536) blocking
> >>>25850184 32830582 [main] python2.6 5188 stat_worker: 0 =
> >>>(\??\C:\cygwin\cygdrive,0x28BB68)
> >> ^^^
> >> This looks suspicious. I assume you're suffering from SMB network
> >> scanning.
> >is there a workaround? Neither "always run elevated" nor "always
> >keep all network drives mounted" seems like a reasonable
> >requirement
What are you expecting? Was my reply in
http://cygwin.com/ml/cygwin/2012-02/msg00375.html not sufficient?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File operations really slow in emacs
Bump?
On 13/02/2012 8:31 AM, Ryan Johnson wrote:
On 11/02/2012 5:11 AM, Corinna Vinschen wrote:
On Feb 10 20:18, Ryan Johnson wrote:
Hi all,
For some reason file operations have become very slow inside emacs
starting yesterday. It's especially painful when saving a file
that's managed by mercurial (more than 20 seconds!), but I've seen
it on the command line as well (x-server takes a similar amount of
time to start, for example). I'm running the latest everything and
I've run rebaseall. I verified that Windows Defender did not
silently re-enable itself since I last disabled it (you can't
actually uninstall it) and no other BLODA are present on my machine.
The problem persists across reboots.
I have vague memories that this has turned up in the past (maybe
12-15 months ago?) but Google isn't turning up anything. Attaching
strace to emacs during the save makes it take a full 35 seconds and
reports the following:
$ cat emacs.strace | awk '{if ($1> 100) { print }}' | grep -v
timer_thread
26910790 26912157 [main] emacs-X11 5188 child_copy: dll bss - hp
0x264 low 0x611FC000, high 0x61230770, res 1
1128419 2125655 [main] python2.6 5188 read: read(5, 0x8009DB60,
65536) blocking
25850184 32830582 [main] python2.6 5188 stat_worker: 0 =
(\??\C:\cygwin\cygdrive,0x28BB68)
^^^
This looks suspicious. I assume you're suffering from SMB network
scanning.
is there a workaround? Neither "always run elevated" nor "always keep
all network drives mounted" seems like a reasonable requirement
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sed strips CRs
On Mon, Feb 13, 2012 at 7:56 PM, Andrey Repin wrote: > Greetings, Nellis, Kenneth! > >> The standard response to issues dealing with CRLF files is to point the >> user to dos2unix and text mode mounts. This should be adequate without >> the hidden behavior of sed/grep/awk and probably others. > > While your reasoning is sound, I prefer them to behave the way they are for my > own goals. > I can't possible alter between text and binary mounts, or use d2u on and off > in an attempt to produce consistent and predictable end results. Consistent behavior is what I see as the issue. IMO, sed, grep and awk should behave the same as on UNIX for consistent and predictable behavior. Treating CR as white space not only helps the Windows user it also helps the Unix user when Windows files are transferred to it. I know that for sed at least treating CR as white space works very well. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: PROGRAMFILES variable is not set during openssh session
On Feb 14 09:27, Corinna Vinschen wrote: > On Feb 14 04:49, Andrey Repin wrote: > > Greetings, Corinna Vinschen! > > > > >> PROGRAMFILES variable is not set during openssh session. > > >> This is very important for remote administrative tasks. > > > > > OpenSSH 6.0p1 is due soon. I asked to apply a patch upstream so that > > > PROGRAMFILES is added back to the environment variables passed over > > > to the child process. > > > > Both of them? (on x86_64 systems, there's two relevant variables) > > Argh. Can of worms. No, only the 32 bit variant for now. Oh, btw., 32 bit processes only see the 32 bit PROGRAMFILES variable by default. Which makes sense since PROGRAMFILES for 32 bit processes is the same as PROGRAMFILES for 64 bit processes... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can not make port forwarding from Cygwin when ControlMaster/ControlPath used.
On Feb 13 19:50, Charles Wilson wrote: > On 2/13/2012 9:00 AM, Corinna Vinschen wrote: > > Btw., connection sharing doesn't work on Cygwin. For this to work we > > need descriptor passing over AF_LOCAL sockets, which isn't implemented > > in Cygwin. > > Yes, please! (I know, I know, SHTDI). >http://cygwin.com/ml/cygwin/2009-10/msg00397.html > See Corinna's and cgf's comments downthread. ...and in contrast to what Dave replied even the DuplicateHandle part is not trivial. It requires one of the processes to have PROCESS_DUP_HANDLE rights for the other process. But since you're connected over a socket, you don't know the process ID of your peer(*). And then, either one of the processes is an admin process, or both processes belong to the same user account, or one of the processes must know the SID of the peer process and open up its process for PROCESS_DUP_HANDLE access to that user account. Corinna (*) getpeereid only works for the listening/connecting processes, not for forked child processes thereof. > > -- > Chuck > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: PROGRAMFILES variable is not set during openssh session
On Feb 14 04:49, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> PROGRAMFILES variable is not set during openssh session. > >> This is very important for remote administrative tasks. > > > OpenSSH 6.0p1 is due soon. I asked to apply a patch upstream so that > > PROGRAMFILES is added back to the environment variables passed over > > to the child process. > > Both of them? (on x86_64 systems, there's two relevant variables) Argh. Can of worms. No, only the 32 bit variant for now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: STC for libapr1 failure
On 2/14/2012 12:00 AM, David Rothenberger wrote: > The libapr1 test cases are failing again for flock locks. I forgot to mention that this same test is failing in the libapr1 test suite when using fcntl locks. I haven't extracted an STC for that, but it's probably very similar to the previous one here http://cygwin.com/ml/cygwin/2011-08/msg00496.html with the shared memory counter added. -- David Rothenberger daver...@acm.org The main problem I have with cats is, they're not dogs. -- Kevin Cowherd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
STC for libapr1 failure
The libapr1 test cases are failing again for flock locks. This same
test case failed with 1.7.9 with a fatal error[1], but that was
corrected. The test is no longer encountering the fatal error, but
it is producing the wrong result.
I extracted the attached STC to demonstrate the problem. It starts a
number of child processes, each of which repeatedly grab and release
a lock on a temporary file. While they have the lock, the increment
a counter in shared memory in a racy way.
If all goes well, the counter should end up having the value of
CHILDREN * ITERS_PER_CHILDREN. And it does, sometimes. Other times,
however, it's less than this value, indicating the lock did not
work.
(I'm using shmget for shared memory, so you have to have cygserver
running. APR has a number of shared memory methods, including mmap,
but this was the easiest for me to extract.)
As before, I haven't been doing C programming in a while, so I'm not
100% sure the test case is valid, but it does demonstrate the same
problem the APR test case is having.
I've tried this on my Win7-64 box running the 20120210 snapshot and
on a WinXP running stock 1.7.10. I get the same results in both
places.
Regards,
David
[1] http://cygwin.com/ml/cygwin/2011-08/msg00480.html
--
David Rothenberger daver...@acm.org
I think we are in Rats' Alley where the dead men lost their bones.
-- T.S. Eliot
/***
* This is a STC to show that flock occasionally does not work.
*
* It tries to use flock() for file locking. It creates a temporary
* file, the uses fork to spawn a number of children. Each child opens
* the file, then repeatedly uses flock to lock and unlock it.
*
* While each child has the lock, it increments a counter stored in
* shared memory in a racy way, passing the current value to a function
* which sleeps briefly, then returns the incremented counter.
*
* If all works correctly, the counter should end up be incremented
* by each child iteration.
*
* However, this is failing for me occasionally. The counter ends up
* being less than the expected value.
*
* This test was extracted from the APR test suite.
*
* Compile: gcc -Wall -o stc-flock-fork stc-flock-fork.c
***/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MAX_ITER 200
#define CHILDREN 6
#define MAX_COUNT (MAX_ITER * CHILDREN)
/* Counter stored in shared memory. */
static volatile int *x;
/* A temporary file used for flock. */
char tmpfilename[] = "/tmp/flocktstXX";
/* a slower more racy way to implement (*x)++ */
static int increment(int n)
{
usleep(1);
return n+1;
}
/* Fork and use flock to lock and unlock the file repeatedly in the child. */
void make_child(int trylock, pid_t *pid)
{
if ((*pid = fork()) < 0) {
perror("fork failed");
exit(1);
}
else if (*pid == 0) {
int fd2 = open(tmpfilename, O_RDONLY);
if (fd2 < 0) {
perror("child open");
exit(1);
}
int rc;
int i;
for (i=0; i--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
