Re: Using cygwin headers/libraries in MS compiled programs
writes: > Folks, > > Apologies for the dumb question and please re-direct if there is a better > forum. > > How do I use cygwin *.h and *.dll in MS console programs? > > If I include in a MS program I get many conflicts between > the cygwin CRT and MS CRT stuff. Is my only options to "port" the headers > to MS and dynamically load the cygwin functions with LoadLibrary()? > > What calling conventions do I need for cygwin functions in MS compiled > code? > > All I really want is cygwin_conv_path() so that my MS programs can accept > cygwin paths. Why not just wright a bash script to invoke your program like: prog.exe "`cygpath -alw _path_`" This way, no matter whether is _path_ in Posix or Win32 format, you can get what you want. > > Regards, Neil > > > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
`cygstart bash' won't work as advertised in man-page
it is said in the manual that
EXAMPLES
Start Bash in a new window
$ cygstart bash
but what I get is:
{ b...@bhj1 /q }
$cygstart bash
Unable to start 'Q:\bash': The specified file was not found.
I'm testing out cygwin-1.7, and it works fine on cygwin-1.5. Is this a
designed feature to reduce security risk that user must specify the full
path if the file is not in the working folder?
--
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/
of and oc
cygstart is so useful that I want type less keys:
alias of=cygstart #on cygwin-1.5
or:
function of ()
{
if which "$1" > /dev/null 2>&1; then
if [[ "$1" == of ]]; then
local file=`which cygstart`;
else
local file="`which \"$1\"`";
fi;
shift;
cygstart "$file" "$@";
else
cygstart "$@";
fi
} #on cygwin-1.7, because we must specify full path now
oc is my name for `open containing folder', and I peeked into source of
Firefox to write it:
function oc ()
{
cygstart `which explorer.exe` /n,/select,\""`cygpath -alw \"$1\"`"\"
}
It won't work for non-ascii file names though, as a Chinese, I feel
a bit sorry for that
--
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/
bash `test -e' problem with cdrom drive and soft-disk drive
If you have cd-rom/soft-disk drive, please run the following test case,
for x in {a..z}; do
if test -e /cygdrive/$x/Windows ; then
echo "Windows found on /cygdrive/$x"
cd /cygdrive/$x
fi
done
And here's the result:
Windows found on /cygdrive/a
bash: cd: /cygdrive/a: No medium found
Windows found on /cygdrive/c
Windows found on /cygdrive/j
bash: cd: /cygdrive/j: No medium found
Windows found on /cygdrive/k
bash: cd: /cygdrive/k: No medium found
--
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: bash `test -e' problem with cdrom drive and soft-disk drive
Corinna Vinschen writes:
> On Jun 8 22:53, Haojun Bao wrote:
>>
>> If you have cd-rom/soft-disk drive, please run the following test case,
>>
>> for x in {a..z}; do
>> if test -e /cygdrive/$x/Windows ; then
>>echo "Windows found on /cygdrive/$x"
>>cd /cygdrive/$x
>> fi
>> done
>>
>> And here's the result:
>>
>> Windows found on /cygdrive/a
>> bash: cd: /cygdrive/a: No medium found
>> Windows found on /cygdrive/c
>> Windows found on /cygdrive/j
>> bash: cd: /cygdrive/j: No medium found
>> Windows found on /cygdrive/k
>> bash: cd: /cygdrive/k: No medium found
>
> And what's the problem?
The problem is that I think if `cd /cygdrive/a' failes, then so should
`test -e /cygdrive/a/Windows'
--
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: bash `test -e' problem with cdrom drive and soft-disk drive
Corinna Vinschen writes:
> On Jun 8 22:53, Haojun Bao wrote:
>>
>> If you have cd-rom/soft-disk drive, please run the following test case,
>>
>> for x in {a..z}; do
>> if test -e /cygdrive/$x/Windows ; then
>>echo "Windows found on /cygdrive/$x"
>>cd /cygdrive/$x
>> fi
>> done
>>
>> And here's the result:
>>
>> Windows found on /cygdrive/a
>> bash: cd: /cygdrive/a: No medium found
>> Windows found on /cygdrive/c
>> Windows found on /cygdrive/j
>> bash: cd: /cygdrive/j: No medium found
>> Windows found on /cygdrive/k
>> bash: cd: /cygdrive/k: No medium found
>
> And what's the problem?
Also, here's another test case:
for x in {a..z}; do PATH=/cygdrive/$x/bin:"$PATH"; ls.exe; done
The result will be take a long time to complete if you have a `A:' drive
in `My Computer', like the following:
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/a/bin/ls.exe: Permission denied
bash: /cygdrive/j/bin/ls.exe: Permission denied
bash: /cygdrive/k/bin/ls.exe: Permission denied
Since I have nothing in drive A:/J:/K:, I think something is wrong with
the file system mounting. Can you reproduce it?
Oh, forgot to mention, I'm testing the cygwin-1.7.
--
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: Garbage man pages
Dave Korn writes: > Bill McCormick wrote: >> Bill McCormick wrote: >>> Bill McCormick wrote: Hello, There's something wrong with my man pager; it's producing garbage output. My ~/.bashrc has these entries: export MANPAGER='less -isrR' export PAGER='less -r' >>> I've looked the the archives and others have other problems and >>> solutions that are documented (ref: >>> http://sourceware.org/ml/cygwin/2006-11/msg00745.html) but this >>> solution isn't working for me. Also, I'm not finding anything in the >>> FAQ or User's Guide. >>> >> BTW, this is a brand new install on a raid 1 mirror. Does cygwin maybe >> have some problem with raid drives? > > It really shouldn't make any difference, Cygwin just relies on the > underlying OS' support for devices. If you can open a file on the drive in > windows explorer and it doesn't come up full of garbage, cygwin ought to get > the same results. > > Must admit I haven't a clue what's causing your problem, never seen anything > like it before. It looks like possibly the decompression is going wrong - > what happens if you run 'zcat' on the corresponding man page .gz file? I > can't reproduce what you get even after running the two export commands you > list there. > > cheers, > DaveK > > -- > 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/ Hi, I also have the same issue. however, there was a warning before I do `man find' that says: Warning: cannot open configuration file /usr/share/misc/man.conf So, after a `find /etc -name "man.conf"', I fixed it by this command: cp /etc/defaults/usr/share/misc/man.conf /usr/share/misc/man.conf This maybe a packaging problem? -- 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/
job control "Bad address" error
hi, I searched the mail list for job control and didnot see my issue, and I can reproduce it both at work and at home: type the command: cat|cat type ^Z, type bg or fg And it will display cat: -: Bad address Could you please try to reproduce it? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Garbage man pages
Dave Korn writes: > > I said I'd check: there doesn't seem anything wrong with the packaging, > which hasn't changed in a couple of years now; the most likely thing is that > you and Bao experienced some kind of failure during running the postinstall > scripts. Checking the log files /var/log/setup.* might show some indication > of the problem. (But it also might not, error-handling paths are a known > weakness in setup.exe.) Thanks:-) The following lines are in my /var/log/setup.log: 2009/06/04 18:06:49 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/man.sh 2009/06/04 18:06:50 abnormal exit: exit code=127 -- 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: Garbage man pages
Dave Korn writes: > > I said I'd check: there doesn't seem anything wrong with the packaging, > which hasn't changed in a couple of years now; the most likely thing is that > you and Bao experienced some kind of failure during running the postinstall > scripts. Checking the log files /var/log/setup.* might show some indication > of the problem. (But it also might not, error-handling paths are a known > weakness in setup.exe.) Thanks:-) I can confirm your guess, the following lines are in my /var/log/setup.log: 2009/06/04 18:06:49 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/man.sh 2009/06/04 18:06:50 abnormal exit: exit code=127 Here's a complete list of abnormal exits, note that I did 2 install, first time is default, second time is full-install. I used `grep abnormal -B 1 setup.log': 2009/06/04 18:06:44 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/000-cygwin-post-install.sh 2009/06/04 18:06:47 abnormal exit: exit code=127 2009/06/04 18:06:47 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/passwd-grp.sh 2009/06/04 18:06:47 abnormal exit: exit code=127 2009/06/04 18:06:47 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/update-info-dir.sh 2009/06/04 18:06:48 abnormal exit: exit code=127 2009/06/04 18:06:48 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/coreutils.sh 2009/06/04 18:06:48 abnormal exit: exit code=127 2009/06/04 18:06:48 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo0.sh 2009/06/04 18:06:48 abnormal exit: exit code=127 2009/06/04 18:06:48 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/bash.sh 2009/06/04 18:06:49 abnormal exit: exit code=127 2009/06/04 18:06:49 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/base-files-profile.sh 2009/06/04 18:06:49 abnormal exit: exit code=127 2009/06/04 18:06:49 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/base-files-mketc.sh 2009/06/04 18:06:49 abnormal exit: exit code=127 2009/06/04 18:06:49 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/man.sh 2009/06/04 18:06:50 abnormal exit: exit code=127 2009/06/04 18:06:50 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo.sh 2009/06/04 18:06:50 abnormal exit: exit code=127 -- 2009/06/04 18:59:17 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/clamav.sh 2009/06/04 18:59:18 abnormal exit: exit code=1 -- 2009/06/04 18:59:26 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/exim.sh 2009/06/04 18:59:26 abnormal exit: exit code=2 -- 2009/06/04 19:57:08 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/brltty.sh 2009/06/04 19:57:09 abnormal exit: exit code=1 -- 2009/06/04 19:58:26 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/postinstall-ec-fonts-mftraced.sh 2009/06/04 19:58:31 abnormal exit: exit code=1 -- 2009/06/04 20:03:28 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/shared-mime-info.sh 2009/06/04 20:03:28 abnormal exit: exit code=127 -- 2009/06/04 20:05:41 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/x3270.sh 2009/06/04 20:05:41 abnormal exit: exit code=127 -- 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/
find(1) assertion for folder with a sub-folder named `x:'
hi, Here's a test case to make find(1) assertion: mkdir no-such-dir/foo/bar: -p #this will not assert find no-such-dir/ mkdir no-such-dir/foo/c: -p #this will assert now find no-such-dir/ #this wil not assert cd no-such-dir/foo/; find .; cd - #this `rm' will fail silently rm no-such-dir/ -rf || echo rm failed #this `rm' will fail with `no such file/dir' rm no-such-dir/ -r The `find' assertion is like this: assertion "ent->fts_info == FTS_NSOK || state.type != 0" failed: file "/usr/src/findutils-4.5.4-1/src/findutils-4.5.4/find/ftsfind.c", line 475, function: consider_visiting -- 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/
Switched back to cygwin EMACS from EMACS for win32
(This is not a bug report for cygwin or Emacs, it's more like a story). Long time ago, I used old cygwin EMACS, 21.x version, but I found it crashes now and then, so I struggled til I found native EMACS 23 beta is provided at (*) (*) http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl. I went very far (to myself at least) by googling around for solutions with stuff like cygwin-mount.el, TRAMP/pscp/plink, w32-symlinks.el, gnuserv, visemacs (for Visual Studio), and by writing some scripts/helper programs myself. It was fun and the result is quite satisfactory. But then recently I found a very annoying thing. I switched to use GNUS/nnimap to read mail from GMail. It was very slow, so I googled around and found a solution: use offlineimap and dovecot (**). I have installed andLinux for running these. (**) http://sachachua.com/wp/2008/05/08/geek-how-to-use-offlineimap-and-the-dovecot-mail-server-to-read-your-gmail-in-emacs-efficiently/ But it was still very SLOW! The `imap read: k' is running like a stopwatch. I set up Thunderbird to test, and it can download the same mail (about 1M) instantly. I used Procexp (***) and found out EmacsW32 is reading output from OpenSSL about 64K/sec. I googled again (with keywords `pipe 64k win32') and assume this is some Win32/DOS compatibility thing? Anyhow, cygwin-1.7 comes with Emacs23, so I just switched back and was happy again:-) (***) http://download.sysinternals.com/Files/ProcessExplorer.zip Thanks to you all cygwin developpers! -- 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: find(1) assertion for folder with a sub-folder named `x:'
"Phil Betts" writes: > Corinna Vinschen wrote: >> On Jun 19 17:55, Haojun Bao wrote: >> > hi, >> > >> > Here's a test case to make find(1) assertion: >> > >> > mkdir no-such-dir/foo/bar: -p >> > >> > #this will not assert >> > find no-such-dir/ >> > >> > mkdir no-such-dir/foo/c: -p >> >> I think the right answer here is "don't do that". Don't create files >> or directories starting with a single character, followed by a colon. >> The problem is that a path starting with "X:" is treated as an >> absolute Win32 path. >> >> Right now you cannot have both. Either a path starting with "X:" is >> treated as Win32 path, or Cygwin must stop handling Win32 paths at all >> and only allow POSIX paths. > > Just to underline what Corinna said, consider the consequences of > the following: Corinna said, right now I can't have both, so maybe in the future:-). I think Cygwin can stop handling Win32 paths since we already have cygpath, so if one want to `rm -rf c:/', one can simply write rm -rf `cygpath -au c:/` or simply rm -rf /cygdrive/c Sometimes mixing Win32/Posix paths is good, sometimes it's bad. And things are a bit different now in cygwin-1.7 since chars like `:' in a filename are allowed. > > mkdir -p foo/c: > cd foo > rm -rf c:/ > > In case you can't see why that's bad, DON'T TRY IT!! Don't even copy > it, because you will accidentally paste it into a terminal window, you > will get to say "oopsy!" [1], and you will hurt your forehead on > your keyboard. > > If you can't resist the temptation, do invite friends round to watch; > you'll have a humorous shared memory for later in life. Also consider > videoing it, and getting a friend to post it on YouTube for you. Haha, I'm from mainland China, and our goverment established GFW (Great Fireuck-wall of WWW), also known as Golden Shield Project, and YouTube has been blocked for several months. Pretty pathetic eh? > > > [1] See http://www.theregister.co.uk/2008/10/03/bofh_2008_episode_32/ > > > Phil -- 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: commanline argument parsing
grischka writes:
> If I compile this snippet:
>
> #include
> int main (int argc, char **argv)
> {
> int i;
> for (i = 0; i < argc; ++i)
> printf("argv[%d] %s\n", i, argv[i]);
> return 0;
> }
>
> with cygwin GCC and then run it from CMD prompt:
>
> C:\cygwin\home\me> test \"stuff\"
>
> it prints this:
>
> argv[0] test
> argv[1] \stuff"
>
> Is that expected? I'm aware that there is some conversion going on
> and that it's meant to work from a cygwin shell really, but still.
Yes, it's expected. The 1st `\' is not special to windows, so it get
printed, the 1st `"' start a quote and it's removed, the 2nd `\' is in a
quoted string, so it's removed but the 2nd `"' following it gets
printed. And you didn't end your quoted string properly.
You can also try test "x""y", it should print `argv[1] x"y'
>
> Could someone shed light upon the reasoning with this?
On Windows, you can only start a program with a string: `command args',
every program will do their own cmd line argument parsing. Most, but not
all, GUI apps will explicitly use the CRT (CommandLineToArgvW) to parse
it, since the WinMain is like (note the 3rd argument):
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
and there is no ARGC and ARGV. On the other hand, all CLI apps do have
ARGC and ARGV, but it's only because windows already called
CommandLineToArgvW for you (I think).
On Posix system, there's no concept like a lpCmdLine, the shell
(bash/tcsh, whatever it is) will parse the `cmdline' and invoke execve.
On cygwin, I didn't read the code, but I guess execve need do the
reverse work of CommandLineToArgvW, that is, build a lpCmdLine from
ARGC/ARGV, and hand it to CreateProcess
--
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
`run emacs' in win32 console cause bad emacs performance
hi, When I start emacs (alternated to emacs-X11) with `run emacs' on the Windows console (started with the Cygwin.bat shortcut), the emacs performance is not good (moving the cursor up/down is not smooth), and not stable (hang/crash sometimes). But if started directly with `emacs' or from the Start Menu shortcut of emacs (C:\cygwin\bin\run.exe -p /usr/X11R6/bin emacs -display 127.0.0.1:0.0), then all is good. Also good if started with `run emacs' in a RXVT/PUTTY-CYG console. One difference I see is the /proc/`emacs pid'/fd, in the former way, there is only one fd: lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> socket:[1608]= I believe this fd is the connection to X server; if started otherwise, the fd list is: lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> /dev/console lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 1 -> /dev/console lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 2 -> /dev/console lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 3 -> socket:[1624]= or with /dev/console changed to /dev/ttyN. -- 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: `run emacs' in win32 console cause bad emacs performance
procmon.tgz Description: application/tar-gz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: `run emacs' in win32 console cause bad emacs performance
Ken Brown writes: > On 7/3/2009 12:43 PM, Haojun Bao wrote: > [empty message with attachment] > > Was this supposed to be a reply to my request for more information? > I'll repeat what I said: > >> I can't reproduce this, but you haven't really given enough details. >> I don't know if you're using cygwin 1.5 or 1.7, or which version of >> emacs you're running, or >> >> http://cygwin.com/problems.html >> http://www.catb.org/~esr/faqs/smart-questions.html > > Please look at those two links and follow the guidelines for reporting > a problem. ehhh, man, very sorry, I might been busted by gmail, I don't know how this happen. The following is the reply I wrote to your request. Luckily Gmail saved it in Sent Mail. Here it is, without the attachment: Sorry. Cygwin is 1.7, I update very often, and I can reproduce it both at home and in office. Here's the steps to reproduce it: 0. Start X, and set DISPLAY: $startxwin.sh $export DISPLAY=:0 1. start bash from cygwin.bat: $cygstart /Cygwin.bat 2. In the cygwin.bat console window, start emacs-X11 using run.exe: $run emacs-X11.exe -q 3. In the emacs window, move cursor up/down, take a note it's speed, and run: $ps aux|grep emacs $ls -l /proc/3804/fd/ #3804 is the emacs pid Here's the output: lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> socket:[1584]= a2. Quit emacs, start it again in cygwin.bat window, this time use: $emacs-X11.exe -q #without the `run' a3. In the emacs window, move cursor up/down, I can see it's smoother this time. It's reproducible on my PCs both at home/office. And the fd list: lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> /dev/console lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 1 -> /dev/console lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 2 -> /dev/console lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 3 -> socket:[1612]= Also, I used Procmon to see how emacs is doing. Emacs is sending/recving lots of TCP packets to localhost 1053 (X server I guess), but in the 1st case, 552/861 of their sizes are 32 bytes, while on the 2nd case, 318 out of 723 packets are of size 32. Also, I checked how many of the packets are of size [100, 1000), the result is more illustrative, in the 1st case, 86/861, in the second case, 281/723 The Procmon result with only TCP data is attached, after unpack, there is a slow.csv and a fast.csv. -- 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: `run emacs' in win32 console cause bad emacs performance
Haojun Bao writes:
> Ken Brown writes:
>
>> On 7/3/2009 12:43 PM, Haojun Bao wrote:
>> [empty message with attachment]
>>
>> Was this supposed to be a reply to my request for more information?
>> I'll repeat what I said:
>>
>>> I can't reproduce this, but you haven't really given enough details.
>>> I don't know if you're using cygwin 1.5 or 1.7, or which version of
>>> emacs you're running, or
>>>
>>> http://cygwin.com/problems.html
>>> http://www.catb.org/~esr/faqs/smart-questions.html
>>
>> Please look at those two links and follow the guidelines for reporting
>> a problem.
>
> ...
> 3. In the emacs window, move cursor up/down, take a note it's speed, and
> run:
>$ps aux|grep emacs
>$ls -l /proc/3804/fd/ #3804 is the emacs pid
> Here's the output:
>lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> socket:[1584]=
>
> ...
> a3. In the emacs window, move cursor up/down, I can see it's smoother
> this time. It's reproducible on my PCs both at home/office. And the fd
> list:
>lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> /dev/console
>lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 1 -> /dev/console
>lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 2 -> /dev/console
>lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 3 -> socket:[1612]=
>
hi, I have simplified the test case a bit. Wrote 2 .py files, one I get
slow emacs, the other I get normal(smooth) emacs:
$cat slow.py
#!/bin/python
import os
os.close(0)
os.close(1)
os.close(2)
#must make sure X server is running already, or else this doesn't show
#anything, even no -nw version of emacs. my /bin/emacs is alternative to
#/usr/bin/emacs-X11
os.system("emacs -q")
$cat fast.py
#!/bin/python
import os
os.system("emacs -q")
(And my original problem is `run emacs' in cygwin.bat console will cause
emacs slow, and I observed there's only one fd (socket to X) open for
the emacs process started this way; no stdin/out/err).
--
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
lftp depency packages not auto-selected
Run Cygwin setup-1.7.exe for the first time, select lftp explicitly, the basic system is just "Default". After installation complete, start lftp fails, first will complain libexpat missing. After install libexpat, lftp will again complain libstdc++ missing. -- 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
Emacs w3m `w3m-toggle-inline-images' cause segfault
Here's how to reproduce it: 1. install w3m-el 2. start Xwin, and then start emacs with: emacs.exe -q -l ~/1.el 3. Press M-x w3m in emacs to start w3m 4. Press g in *w3m* buffer, type http://www.cnn.com/ (I use this URL because it contains many images. A site with few images will not reproduce this). 5. Press T in the *w3m* buffer to toggle inline images, then Emacs will segfault. And sometimes it may complain "doing vfork resource temporarily unavailable" instead of segfault. The contents of ~/1.el: (progn (setq load-path (cons "~/tools/emacs-site-lisp/w3m/" load-path)) (load "w3m")) Note that I have installed w3m at ~/tools/emacs-site-lisp/w3m/. I tried debugging with gdb, after building cygwin1.dll and emacs-23.0.96 (applied /usr/src/emacs-23.0.92-10.src.patch first), and here's the bt: Program received signal SIGSEGV, Segmentation fault. 0x6109443a in fhandler_pipe::create (fhs=0x0, psize=6, mode=164) at ../../.././../winsup/cygwin/pipe.cc:325 325 fhs[1]->init (w, FILE_CREATE_PIPE_INSTANCE | GENERIC_WRITE, mode); Current language: auto; currently c++ (gdb) bt #0 0x6109443a in fhandler_pipe::create (fhs=0x0, psize=6, mode=164) at ../../.././../winsup/cygwin/pipe.cc:325 #1 0x7c802542 in WaitForSingleObject () from /cygdrive/c/WINDOWS/system32/kernel32.dll #2 0x610b8cd3 in sig_send (p=0x60ff, s...@0x228ff4, tls=0x0) at ../../.././../winsup/cygwin/sigproc.cc:728 #3 0x610b5987 in _pinfo::kill (this=0x60ff, s...@0x228ff4) at ../../.././../winsup/cygwin/signal.cc:210 #4 0x610b5d9b in kill0 (pid=4084, s...@0x228ff4) at ../../.././../winsup/cygwin/signal.cc:252 #5 0x610b5ec1 in kill (pid=4084, sig=11) at ../../.././../winsup/cygwin/signal.cc:270 #6 0x610b3118 in _sigfe () from /usr/bin/cygwin1.dll #7 0x00758801 in bss_sbrk_buffer () #8 0x002295b4 in ?? () #9 0x0400 in ?? () #10 0x0022ce64 in ?? () #11 0x0022919c in ?? () #12 0x610283e7 in _cygtls::call_signal_handler (this=0xff4) at ../../.././../winsup/cygwin/exceptions.cc:1389 Backtrace stopped: frame did not save the PC Lisp Backtrace: "start-process" (0x229a84) "apply" (0x229b30) "let*" (0x229cb8) "let" (0x229e38) "w3m-process-with-environment" (0x229f08) "let" (0x22a088) ... (omitted). -- 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: Emacs w3m `w3m-toggle-inline-images' cause segfault
Ken Brown writes: > On 7/21/2009 10:22 PM, Haojun Bao wrote: >> Here's how to reproduce it: >> >> 1. install w3m-el >> >> 2. start Xwin, and then start emacs with: >>emacs.exe -q -l ~/1.el > > Cygwin's emacs-*-23.0.92-10 packages don't provide emacs.exe. So you > must be using the version you compiled yourself, unless you somehow > have an emacs.exe left over from a previous cygwin version of emacs. > (I mention this in case someone wants to try to reproduce your > problem, in which case your instructions would fail.) Yes, you are right, I'm using my self compiled version. The official version has same issue though. > >> 3. Press M-x w3m in emacs to start w3m >> >> 4. Press g in *w3m* buffer, type http://www.cnn.com/ (I use this URL >> because it contains many images. A site with few images will not >> reproduce this). >> >> 5. Press T in the *w3m* buffer to toggle inline images, then Emacs will >> segfault. And sometimes it may complain "doing vfork resource >> temporarily unavailable" instead of segfault. > > I think fork failures are sometimes fixed by rebasing and sometimes > result from http://cygwin.com/acronyms/#BLODA. Have you looked into > either of those possibilities? Beyond that, I have no ideas, but > maybe the experts can see something useful in your gdb output. Yes, I have done a rebase, and disabled Avira AntiVir Free Edition (which is not on the BLODA, but anyway), and the problem remains. I don't have any software in TBLODA installed. -- 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
Emacs can't start-process more than 30~40 processes (Was: Re: Emacs w3m `w3m-toggle-inline-images' cause segfault)
I have reduced the test case in this mail http://cygwin.com/ml/cygwin/2009-07/msg00111.html to a simpler one: $/bin/emacs --batch -q --execute '(let ((num 0)) (while (< num 30) (setq num (+ num 1)) (message "num is %d" num) (start-process "hello" nil "/usr/bin/echo")))' Emacs will coredump at the 30th process it tries to start on my XP. Now I think this should seem familiar to the experts. I tried to gdb it, the backtrace shows segfault is happening at the same place (#0 0x610949d8 in fhandler_pipe::create () from /usr/bin/cygwin1.dll) You might need to tweak the (< num 30) to (< num 40) or bigger, also, to use gdb on it, you need write the lisp into a file and use `-l' to load the file: cat > ~/2.el
Re: Emacs can't start-process more than 30~40 processes (Was: Re: Emacs w3m `w3m-toggle-inline-images' cause segfault)
Haojun Bao writes: > I have reduced the test case in this mail > http://cygwin.com/ml/cygwin/2009-07/msg00111.html > to a simpler one: > > $/bin/emacs --batch -q --execute '(let ((num 0)) > (while (< num 30) > (setq num (+ num 1)) > (message "num is %d" num) > (start-process "hello" nil "/usr/bin/echo")))' > > Emacs will coredump at the 30th process it tries to start on my XP. > > Now I think this should seem familiar to the experts. I tried to gdb it, > the backtrace shows segfault is happening at the same place > (#0 0x610949d8 in fhandler_pipe::create () from /usr/bin/cygwin1.dll) > > You might need to tweak the (< num 30) to (< num 40) or bigger, also, to > use gdb on it, you need write the lisp into a file and use `-l' to load > the file: > > cat > ~/2.el < (let ((num 0)) > (while (< num 40) > (setq num (+ num 1)) > (message "num is %d" num) > (start-process "hello" nil "/usr/bin/echo"))) > End > > gdb --args ./emacs --batch -q -l ~/2.el I have debugged it again, and I think I have more clue. I have read the how-cygheap-works.txt, and this might be a known problem. It's because the cygheap space has been used up. With Procexp, I can see cygwin1.dll is based 0x6100, with size 0x30 (3M). When segfault is about to happen, cygheap_max is 0x6164e924, and the _csbrk is called with a increase of (gdb) p sbs $16 = 65544 This will increase cyghead to 0x6165e92c, but from Proxexp I can see cygncurses-9.dll is based at 0x6165. Besides, this code snippet from pipe.cc fhandler_pipe::create didn't check for NULL pointer, and directly caused the segfault. fhs[0] = (fhandler_pipe *) build_fh_dev (*piper_dev); fhs[1] = (fhandler_pipe *) build_fh_dev (*pipew_dev); //bhj: we should check NULL here. mode |= mode & O_TEXT ?: O_BINARY; fhs[0]->init (r, FILE_CREATE_PIPE_INSTANCE | GENERIC_READ, mode); fhs[1]->init (w, FILE_CREATE_PIPE_INSTANCE | GENERIC_WRITE, mode); My question is, is there anyway out of this? Can I just rebase cygwin1.dll to the end of all other DLLs? -- 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: Emacs can't start-process more than 30~40 processes
Dave Korn writes: > Haojun Bao wrote: > >> >> My question is, is there anyway out of this? Can I just rebase >> cygwin1.dll to the end of all other DLLs? > > It ought to work. Would you mind giving it a try and letting us know if it > helps? It might be a good idea to tweak rebaseall to do this for us. > Yes, it helped, the max start-process number is improved from ~30 to ~37. I think it's hit another issue. Here's the details: I can't run rebase.exe on cygwin1.dll directly, since the latter is loaded by the former. I wrote a .bat file to rebase it: cd c:\cygwin\bin c: copy cygwin1.dll 2.dll rebase -b 0x4500 2.dll copy 2.dll cygwin1.dll I did not try to rebase cygwin1.dll to the end of all other DLLs though, I don't know if that is feasible. Instead, I just make it a lot more far away from the DLL that's next to it in the address space. (The old base for cygwin1 is 0x6100, and next is cygncurses-9.dll based at 0x6165, the max cygheap is ~6.6M; new cygwin1 base is 0x4500, and the next DLL is cygz.dll, with a base 0x5495, with a max cygheap ~256M). After this, the emacs can start more processes, but still not unlimited, neither will it segfault; it just exits will code 255 after printing "Wrong type argument: stringp, 0". This must be another issue now, I will debug it when I have more time. $/bin/emacs --batch -q --execute '(let ((num 0)) (while (< num 80) (setq num (+ num 1)) (message "num is %d" num) (start-process "hello" nil "/usr/bin/echo")))' output ... ... num is 37 Wrong type argument: stringp, 0 -- 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: Emacs can't start-process more than 30~40 processes
Christopher Faylor writes: > On Tue, Jul 28, 2009 at 10:52:44AM +0800, Haojun Bao wrote: >>I have debugged it again, and I think I have more clue. I have read the >>how-cygheap-works.txt, and this might be a known problem. >> >>It's because the cygheap space has been used up. With Procexp, I can see >>cygwin1.dll is based 0x6100, with size 0x30 (3M). When segfault >>is about to happen, cygheap_max is 0x6164e924, and the _csbrk is called >>with a increase of >>(gdb) p sbs >>$16 = 65544 >>This will increase cyghead to 0x6165e92c, but from Proxexp I can see >>cygncurses-9.dll is based at 0x6165. >> >>Besides, this code snippet from pipe.cc fhandler_pipe::create didn't >>check for NULL pointer, and directly caused the segfault. >> >> fhs[0] = (fhandler_pipe *) build_fh_dev (*piper_dev); >> fhs[1] = (fhandler_pipe *) build_fh_dev (*pipew_dev); >> >>//bhj: we should check NULL here. > > Not necessarily. We don't expect these functions to return NULL. It > would be interesting to know how many fds are open at this point. If it > is a large number then maybe we have to start enforcing an fd max. If > it is a "small" number then something is wrong and we're allocating too > much of the cygheap. The cygheap was always supposed to be relatively > small. Maybe we're abusing it too much in 1.7. There are quite some fds. In start-process, emacs will allocate 1 PTY and 1 pipe for each process it starts. Each fhandler_base is about 32K, but the _csbrk must allocate 65544 bytes for it. -- 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: Emacs can't start-process more than 30~40 processes
Christopher Faylor writes: > On Wed, Jul 29, 2009 at 03:32:28PM +0800, Haojun Bao wrote: >>> >>> Not necessarily. We don't expect these functions to return NULL. It >>> would be interesting to know how many fds are open at this point. If it >>> is a large number then maybe we have to start enforcing an fd max. If >>> it is a "small" number then something is wrong and we're allocating too >>> much of the cygheap. The cygheap was always supposed to be relatively >>> small. Maybe we're abusing it too much in 1.7. >> >>There are quite some fds. In start-process, emacs will allocate 1 PTY >>and 1 pipe for each process it starts. > > Yes, I assumed that there were a bunch of fds but I was looking for an > exact number rather than "quite some". I can't give exact details about > how to find the number now but I thought that since you were looking at > the code it wouldn't be too hard to figure this value out. > Sorry. There are a total of 40 fds in one test run from /proc/PID/fd. Seems the PTYs and pipes are allocated and released soon, what remains are /dev/ptmx fds. $'ls' -l /proc/5668/fd total 0 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> /dev/tty2 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 1 -> /dev/tty2 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 2 -> /dev/tty2 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 37 -> /dev/tty36 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 38 -> pipe:[2180]| lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 39 -> pipe:[2232]| ... #bhj: fd 3-36 are all opened -> /dev/ptmx ... -- 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: How cygwin realize posix pipe?
Tatsuro MATSUOKA writes: > Hello > > I have involved in the octave project. > Octave uses gnuplot as a graphic backend and data are sent and recieved via > pipe. > > A report of slowness issue of the plot on octave on windows reported. So one of your program is native and the other cygwin. It's like a similar issue I met when using native Emacs+Gnus and cygwin programs (openssl client) to read imap mails, it is very slow. I guess it was a pipe size issue, for old DOS compatibility, the pipe buffer is 64K, and if I check the i/o rate of openssl with Procexp, I can see something like 64K. This is a very wild guess though. First I see sth. in Procexp to be about 64K, then I googled with "windows pipe 64k". Maybe you can try tweak the pipe buffer size. -- 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
avira (http://www.avira.com/) should be added to BLODA?
Hi,
Avira will cause findutils configure take a lng time. And I doubt
many other anti-virus software will cause problems here.
I tried to build findutil, the `configure' hangs (but not really) when
testing long file name. I checked the conftest.c to see where it seemed
to hang.
At the end of the test (after making 1366 folders in straight line), the
code will back up, deleting all the folders one by one.
For the deepest folders, it's taking ~30 seconds to delete each. My
guess is the conservative average will be ~10 secs, and takes ~13000
secs to finish the conftest, so I just terminated the process and
decided to report a bug (I actually did yesterday, but the email seem to
be lost in the way).
Then it occured to me this might be a BLODA issue, so I disabled the
Avira Guard and test again, and the conftest finishes quickly.
The conftest source is below (sorry can't use attachment. You can get it
from findutils-4.5.4/gnulib/m4/getcwd-path-max.m4 too), I only added 2
printf to show folder depth.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef AT_FDCWD
# define AT_FDCWD 0
#endif
#ifdef ENAMETOOLONG
# define is_ENAMETOOLONG(x) ((x) == ENAMETOOLONG)
#else
# define is_ENAMETOOLONG(x) 0
#endif
/* Don't get link errors because mkdir is redefined to rpl_mkdir. */
#undef mkdir
#ifndef S_IRWXU
# define S_IRWXU 0700
#endif
/* The length of this name must be 8. */
#define DIR_NAME "confdir3"
#define DIR_NAME_LEN 8
#define DIR_NAME_SIZE (DIR_NAME_LEN + 1)
/* The length of "../". */
#define DOTDOTSLASH_LEN 3
/* Leftover bytes in the buffer, to work around library or OS bugs. */
#define BUF_SLOP 20
int
main ()
{
#ifndef PATH_MAX
/* The Hurd doesn't define this, so getcwd can't exhibit the bug --
at least not on a local file system. And if we were to start worrying
about remote file systems, we'd have to enable the wrapper function
all of the time, just to be safe. That's not worth the cost. */
exit (0);
#elif ((INT_MAX / (DIR_NAME_SIZE / DOTDOTSLASH_LEN + 1) \
- DIR_NAME_SIZE - BUF_SLOP) \
<= PATH_MAX)
/* FIXME: Assuming there's a system for which this is true,
this should be done in a compile test. */
exit (0);
#else
char buf[PATH_MAX * (DIR_NAME_SIZE / DOTDOTSLASH_LEN + 1)
+ DIR_NAME_SIZE + BUF_SLOP];
char *cwd = getcwd (buf, PATH_MAX);
size_t initial_cwd_len;
size_t cwd_len;
int fail = 0;
size_t n_chdirs = 0;
if (cwd == NULL)
exit (1);
cwd_len = initial_cwd_len = strlen (cwd);
while (1)
{
size_t dotdot_max = PATH_MAX * (DIR_NAME_SIZE / DOTDOTSLASH_LEN);
char *c = NULL;
cwd_len += DIR_NAME_SIZE;
/* If mkdir or chdir fails, it could be that this system cannot create
any file with an absolute name longer than PATH_MAX, such as cygwin.
If so, leave fail as 0, because the current working directory can't
be too long for getcwd if it can't even be created. For other
errors, be pessimistic and consider that as a failure, too. */
if (mkdir (DIR_NAME, S_IRWXU) < 0 || chdir (DIR_NAME) < 0)
{
if (! (errno == ERANGE || is_ENAMETOOLONG (errno)))
fail = 2;
break;
}
if (PATH_MAX <= cwd_len && cwd_len < PATH_MAX + DIR_NAME_SIZE)
{
c = getcwd (buf, PATH_MAX);
if (!c && errno == ENOENT)
{
fail = 1;
break;
}
if (c || ! (errno == ERANGE || is_ENAMETOOLONG (errno)))
{
fail = 2;
break;
}
}
if (dotdot_max <= cwd_len - initial_cwd_len)
{
if (dotdot_max + DIR_NAME_SIZE < cwd_len - initial_cwd_len)
break;
c = getcwd (buf, cwd_len + 1);
if (!c)
{
if (! (errno == ERANGE || errno == ENOENT
|| is_ENAMETOOLONG (errno)))
{
fail = 2;
break;
}
if (AT_FDCWD || errno == ERANGE || errno == ENOENT)
{
fail = 1;
break;
}
}
}
if (c && strlen (c) != cwd_len)
{
fail = 2;
break;
}
++n_chdirs;
printf("%d\n", n_chdirs);
}
/* Leaving behind such a deep directory is not polite.
So clean up here, right away, even though the driving
shell script would also clean up. */
{
size_t i;
/* Try rmdir first, in case the chdir failed. */
rmdir (DIR_NAME);
for (i = 0; i <= n_chdirs; i++)
{
printf("%d\n", n_chdirs - i);
if (chdir ("..") < 0)
break;
if (rmdir (DIR_NAME) != 0)
break;
}
}
exit (fail);
#endif
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.ht
Re: avira (http://www.avira.com/) should be added to BLODA?
Dave Korn writes: > Haojun Bao wrote: >> Hi, >> >> Avira will cause findutils configure take a lng time. And I doubt >> many other anti-virus software will cause problems here. > > Hmm, it turns out it's already there since we had a similar report back in > March(*), but the FAQ on the website still points to the 1.5 version by > default. Compare Right. Thanks. Aside the FAQ, the link on http://cygwin.com/acronyms/#BLODA should also be updated to reflect cygwin1.7 . It's the one I followed. -- 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
Misc programs/scripts/config files I wrote
When I update/build cygwin, I must make sure to kill all cygwin processes, or I will be required to reboot. So I just wrote a script using win32 native python to terminate all process that has cygwin1.dll loaded: terminateModule.py cygwin1.dll Sadly, I can't simply post the .py file out, because it uses a few other files (I'm too lazy). You can check out http://code.google.com/p/windows-config/ for details. Now this might be inappropriate for this ml, but I'm posting in the hope that what I have done could be useful to other cygwin users. These are not completely cygwin, but it is definitely most related. Run the following commands: svn checkout http://windows-config.googlecode.com/svn/trunk/ windows-config-read-only #(perform a virus scan if you don't trust me:-) cd windows-config-read-only/bin/windows ./after-check-out.sh #you will see webpages opened, these are some tools you need to install ./startup.sh It started as a simple .bashrc, and I used a local svn server to version control it in the belief that we should VC anything (of value). Then I found out google code and switched to avoid syncing my .rc files using a USB stick between home and work. There are some .exe files in windows-config-read-only/bin/windows, the source code of them can be found in windows-config-read-only/gcode. Some other .exe files are also installed by download-external.sh (invoked by after-check-out.sh), for e.g., some programs from sysinternals, Procmon/Procexp/handles/winobj, etc. startup.sh will invoke substartup.sh to start some programs in windows-config-read-only/bin/windows/startup, and then it will "ln -sf" itself into your "$HOMEDRIVE$HOMEPATH/Start Menu/Programs/Startup" so that next time you login Windows, it will run itself again. It will also change your /etc/passwd to set your HOME to windows-config-read-only! Be careful:-) Don't worry Windows don't know how to start your startup.sh, startup.sh will invoke setreg.sh to setup the registry for .sh/bash association, among other things. Some other useful things: = Access MSDN from Emacs (.emacs, helpEmacs.py) = Integrate windows programs and cygwin programs (grep for shellHelper_vc6/shellHelper_cyg) = Compile vc6/vc7/vc8/vc9 projects from Emacs with compilation mode (vccompile) = Access JDK help documents from Emacs (.emacs jdkhelp.sh) = grep registry (regrep.py) = replace registry using regexp (regsub.py) (for e.g. regsub.py 'c:.documents and settings' 'd:\\Profiles' to point the windows user folder to another disk, which can be useful if you re-install windows) = open regedit.exe with the current item specified on the command line (regopen.py 'HKEY_CLASSES_ROOT\.sh') = bashHere/emacsedit with right mouse menu for Explorer = source code reading (grepall.py -e "printf" .) -- 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: Misc programs/scripts/config files I wrote
"Larry Hall (Cygwin)" writes: > On 08/13/2009 05:27 AM, Haojun Bao wrote: >> >> When I update/build cygwin, I must make sure to kill all cygwin >> processes, or I will be required to reboot. > > > > Your reference to "build" doesn't make sense to me but if by "update" you > mean via 'setup.exe', then 'setup.exe' does warn of these situations so > that you can avoid the reboot. Yes, when `setup.exe' warn cygwin1.dll can't be replaced, you have 2 options, 1, kill all cygwin processes and continue, or, 2, ignore it and reboot. Any by `build', I mean build cygwin1.dll and then copy it to /bin, then again if some cygwin processes are running I need kill them. Now, I can kill them manualy one by one, and make sure I have killed all by try and error; or I do that with scripts. -- 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
find(1) memory leak in cygheap
I found this problem when running updatedb, the find will print
2 [main] find 2592 C:\cygwin\bin\find.exe: *** fatal error -
cmalloc would have returned NULL
I have dumped the cygheap using gdb to see what's in it, the size is
about 25M, and I use strings.exe to examine the strings
in it, all the folder names that find has looked into is in it, both
native format and cygwin format of the folders names.
And there are lot's of folders in my android source folder, so the
cygheap is filled up. I think maybe this is a memory leak?
Please use the following script to test:
#!/bin/bash
set -e
set -o pipefail
mkdir /xxx -p
cd /xxx
#make sure the folder is long enough so that the memory fill easily.
LONG_FOLDER=`/bin/python -c 'print ("./" + "x"*200)*35'`
mkdir -p ${LONG_FOLDER}
cd ${LONG_FOLDER}
for ((x=0; x<1000; x++)); do echo $x; done|xargs mkdir -p
cd /xxx
find .|wc -l
echo OK
cd /
rm xxx -rf
--
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: find(1) memory leak in cygheap
On Wed, Aug 19, 2009 at 11:04 PM, Haojun Bao wrote:
> On Wed, Aug 19, 2009 at 10:03 PM, Christopher
> Faylor wrote:
>> On Wed, Aug 19, 2009 at 07:47:37PM +0800, Haojun Bao wrote:
>>>I found this problem when running updatedb, the find will print
>>>
>>> 2 [main] find 2592 C:\cygwin\bin\find.exe: *** fatal error -
>>>cmalloc would have returned NULL
>>>
>>>I have dumped the cygheap using gdb to see what's in it, the size is
>>>about 25M, and I use strings.exe to examine the strings
>>>in it, all the folder names that find has looked into is in it, both
>>>native format and cygwin format of the folders names.
>>>
>>>And there are lot's of folders in my android source folder, so the
>>>cygheap is filled up. I think maybe this is a memory leak?
>>>
>>>Please use the following script to test:
>>
>> How about if you provide us with cygcheck output first?
>>
> Sorry, here's the cygcheck output attached
>
I have done some debugging, and the culprit should be dup(2) syscall.
Here's another test case, this time written in C.
Note that the cygheap_start and cygheap_max value will be very likely
different on your computer, so you should use gdb to take a peek into
cygwin1.dll to get your value. Or else you should remove the reference
to these memory location.
The test case will show cygheap is always growing, and at the end it will print
1 [main] a 3560 Q:\a.exe: *** fatal error - cmalloc would have returned NULL
Here's the code:
#include
#include
#include
#include
#include
#include
void ** _cygheap_start = (void **)0x612076b0;
void ** cygheap_max = (void **)0x6114b104;
#include
int main()
{
/*make a big buffer to fill quicker*/
char buf[4095] = {'/'};
int i;
for (i=1; ihttp://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: find(1) memory leak in cygheap
On Thu, Aug 20, 2009 at 4:39 PM, Corinna
Vinschen wrote:
> On Aug 20 14:09, Haojun Bao wrote:
>> I have done some debugging, and the culprit should be dup(2) syscall.
>> Here's another test case, this time written in C.
>>
>> Note that the cygheap_start and cygheap_max value will be very likely
>> different on your computer, so you should use gdb to take a peek into
>> cygwin1.dll to get your value. Or else you should remove the reference
>> to these memory location.
>>
>> The test case will show cygheap is always growing, and at the end it will
>> print
>> 1 [main] a 3560 Q:\a.exe: *** fatal error - cmalloc would have returned
>> NULL
>
> Thanks for the testcase! It was pretty easy to find the culprit with
> it. Deep in dup(), the strings for the filenames of the new file
> descriptor were allocated twice. While I was at it, I also found two
> other potential memory leaks, which would just show up much less
> frequent.
>
> This fixes your find testcase as well, and probably (hopefully?) also
> the problem reported in http://cygwin.com/ml/cygwin/2009-08/msg00620.html
>
> I applied a patch to CVS and will upload a -60 release asap.
>
>
> Thanks again,
> Corinna
>
Great. In fact, I also found this code myself might cause problem in path.h:
(we should test if path is NULL, and free it before the memcpy, and
other member pointers should also be checked and free-ed first, is it
about right?:-)
215 path_conv &operator =(path_conv& pc)
216 {
217memcpy (this, &pc, sizeof pc);
218path = cstrdup (pc.path);
219set_normalized_path (pc.normalized_path);
220wide_path = NULL;
221return *this;
222 }
--
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
bar and bar.exe under same folder and cygwin-svn version control (don't do that!)
This might turn out a big surprise for the unwary (and unwise, like me), who put `bar' and `bar.exe' in the same folder, under svn version control. `bar' is a Linux binary, `bar.exe' is for Winows. Now, if you `rm bar' (for some reason), and modify `bar.exe', then do a `svn ci', you will see both file got check in: $svn ci -m '' Sendingbar Sendingbar.exe Transmitting file data .. here's how to reproduce it: mkdir /tmp/svn svnadmin create /tmp/svn/foo svn co file:///tmp/svn/foo cd foo touch bar bar.exe svn add bar bar.exe svn ci -m '' rm bar -f echo bar > bar.exe svn ci -m '' And, in the working copy, you can't `svn revert bar' to get it un-removed, it will do nothing, the reasoning could be like the following: svn asks cygwin: has `bar' changed? cygwin: (thinking to itself: `bar'? I see no *bar*, but a *bar.exe*, you must be talking about that one. Let me see...) *it* has not changed! svn: nothing to be done! (cygcheck.out is not available, as I think it's not related:-) -- 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: Many Cygwin (mintty) windows - How to close all?
Arun Biyani writes: > Chris Sutcliffe wrote: Is there some sort of Cygwin command that - 1. Closes all Mintty windows 2. Unloads services - such as cron 3. Exits X server in short, gets rid of all Cygwin processes so I can update & restart without having to do all this myself. >>> I use the attached script (run it elevated on Vista and above) before >>> updating with setup. This is only tested on Vista. >> >> Doing a 'kill -9 -1' works for me in terms of getting rid of all my >> mintty windows at once. I'm not sure if it will kill services and >> exit the X server as well. >> >> Chris >> > Thanks for the suggestions. > Arun Or you may want to check out http://windows-config.googlecode.com The following 2 files can do the job you thus wanted: http://windows-config.googlecode.com/svn/trunk/bin/windows/terminateModule.py together with http://windows-config.googlecode.com/svn/trunk/gcode/modules/modules/Program.cs The C# .net programming provides a `System.Diagnostics' package, which you can use to enum every process and every PE32 executable (dll or exe) loaded by each process, then you just grep "cygwin1.dll" and TerminateProcess each of them. Put it in a python script... You can terminate all notepad.exe with `terminateModule.py notepad.exe' for example. Another thing, when running `terminateModule.py', the python must be the native win32 python, with pywin32 installed, not the one shipped with cygwin. The reason should be apparent. Then there comes another problem, you must run it like "c:/python25/python q:/bin/windows/terminateModule.py notepad.exe" which is too boring So, I just wrote a bash helper that will make it possible to invoke native python from the shebang like: #!/bin/env pywinstart.exe the pywinstart.exe is a *general* .exe file, which will only invoke bash with a `helper.sh' and the command line arguments, in helper.sh, it will see pywinstart.exe is executing, so instead it will invoke a *pywinstart.sh*, which then *cygstart* the native python, with the .py file path "~/bin/windows/terminateModule.py" transformed to it's win32 path using `cygpath -alm' If you are interested, consider checkout the whole http://windows-config.googlecode.com/svn/trunk and execute its bin/windows/after-check-out.sh and bin/windows/startup.sh, and reboot. See what happens... Be fore-warned: it will change your keyboard's CapsLock into Control, among other not very polite things:-) > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Many Cygwin (mintty) windows - How to close all?
Dave Korn writes: > Haojun Bao wrote: > >> The C# .net programming ... > > Yeh. Or you could just use the cygwin native tools from the procps package, > which have the advantage of not having to install hundreds of megabytes of MS > bloatware. You don't need to install the Visual Stuio, the compiled binary is also in the svn, so you only need the vs-redist, which probably is already there. > >> The C# .net programming provides a `System.Diagnostics' package, which >> you can use to enum every process and every PE32 executable (dll or exe) >> loaded by each process, then you just grep "cygwin1.dll" and >> TerminateProcess each of them. Put it in a python script... > > How on earth is that not *hugely* more trouble and effort than just typing > "kill -9 -1"? > >> Another thing, when running `terminateModule.py', the python must be the >> native win32 python, with pywin32 installed, not the one shipped with >> cygwin. The reason should be apparent. Then there comes another problem, > > First you have a problem. Then you decided to use a non-cygwin version of > something that is also a cygwin app to help you. Now you have two problems! > This entire design is pointlessly baroque. Not so bad if I get the idea reused:-) See below. > >> the pywinstart.exe is a *general* .exe file, which will only invoke bash >> with a `helper.sh' and the command line arguments, in helper.sh, it will >> see pywinstart.exe is executing, so instead it will invoke a >> *pywinstart.sh*, which then *cygstart* the native python, with the .py >> file path "~/bin/windows/terminateModule.py" transformed to it's win32 >> path using `cygpath -alm' > > Are you being deliberately masochistic? Why not do it all blindfold as well > just to make things even harder on yourself? Installing the .NET runtime, and > a whole new python distro, and a bunch of scripts, and all this just to > duplicate the existing functionality that "pkill" and "pgrep" provide > in a I didn't know `pkill' and `pgrep' before, so I gave it a try right now. To my suprise, it can grep and kill non-cygwin programs such as notepad.exe. But only if it is started under cygwin, not if it's from the Run-Dialog. > fraction of the size and hassle? *shrugs* It's your life to waste, I > guess. > >> Be fore-warned: it will change your keyboard's CapsLock into Control, >> among other not very polite things:-) > > So apart from being far more trouble, taking far more time and effort, and > disk space, and cpu cycles, and being fragile, it ALSO has the additionl > benefit of messing up your settings? > > Cost-benefit trade-off. You are doing it wrong. Thanks for pointing this out to me. I'm really sweating and thinking now. But then I must go on to explain why I have done those things. It all because I need to make cygwin/non-cygwin programs work together. For e.g., I use Visual Studio, and there's a visemacs addin which can send files to emacs for editting. It works for the native Emacs, but later I switched to cygwin-Emacs, and visemacs stopped working, because it will send the file path in win32 format. So using the same idea (and the same binary, only another hardlink), I have an emacsedit.exe and emacsedit.sh, in the latter `cygpath -au' will be used to invoke emacsclient.exe with the posix pathname. Also, I use firefox chm reader addon to read some e-book, I want to be able to double click on a .chm file and it get opened with firefox, not hh.exe. I need write a `ffchm.sh' like this: #!/bin/bash firefox chm:file://"`cygpath -alw \"$1\"`" But then, I can't associate .chm with this .sh file in registry, it must be a .exe file, so another hardlink as ffchm.exe to my over-used shell-help.exe. > > cheers, > DaveK > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN_NT-5.1 1.7.0(0.214/5/3) ps (cygwin) 1.11 - how do I display the arguments to the processes?
Chris January writes: > > Install the procps package and then use the procps command. > You can also try WMIC which comes with Windows, on XP in my case. If you need for e.g., PID/PPID/CMDLINE, especially if you need see Windows native processes and if procps can't do that (I don't know if it can or not), then you can use this script: #!/bin/perl ## here, "http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
emacsclient.exe won't exit (was: Re: [1.7] Updated: cygwin-1.7.0-65)
Hi, Corinna Vinschen writes: > > Nver mind. With the help of your testcase I found the problem. I'll > apply a fix shortly, but I have to think about it some more first. > After upgrade to -65 cygwin.dll, emacsclient.exe won't exit, no matter if the --no-wait option is added. There's a socket kept open between the client and the server: $netstat.exe -b -n|grep 3005 -A 1 TCP127.0.0.1:3005 127.0.0.1:3112 ESTABLISHED 3472 [emacs-X11.exe] -- TCP127.0.0.1:3112 127.0.0.1:3005 ESTABLISHED 2584 [emacsclient.exe] The test case is simple, just run `emacsclient -n . ' when emacs-x11 has already (start-server). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Performance and stat()
Dave Korn writes: > On 04/06/2010 18:33, Christopher Wingert wrote: >>> [quit top-posting] >> >> Now you are my mom too? > > No, I am. Now quit playing with all your new friends and > dinner! > > cheers, > Your Mom OK. I'm a Chinese, and I'm laughing out loud with this one. http://www.chinasmack.com/2009/stories/jia-junpeng-your-mom-wants-you-to-go-home-to-eat.html -- 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: One final time
Laugh out loud rolling in bed can not fall asleep. cyf, you must be BOFH! This guy wanted to send a private email to the "leader", and now complains because the leader drags him back into the mailing list... On Mon, Jun 7, 2010 at 12:05 AM, Christopher Wingert wrote: > > Just FYI, just to be clear how petty Mr. Faylor is: > > I wrote my last email to the mailing list at 06/05/2010 23:16. > > I unsubscribed to the cygwin@cygwin.com mailing list and received > success at 06/05/2010 23:26. > > I received no further cygwin emails till 06/06/2010 01:26. > > At that time, Mr Faylor added me back into the list specifically for > the purposes to get the last word in. > > The message: http://www.cygwin.com/ml/cygwin/2010-06/msg00149.html > > Again good luck with your project, but leave me alone! > > Chris > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
