[ANNOUNCEMENT] Updated: quilt-0.48-3 -- Tool to work with series of patches

[Jari Aalto]

PACKAGE DESCRIPTION
===

Homepage: http://freshmeat.net/projects/quilt
License : GPL

Tool to work with series of patches

Program manages a series of patches by keeping track of the changes each
of them makes. They are logically organized as a stack, and you can
apply, un-apply, refresh them easily by traveling into the stack
(push/pop). Quilt is good for managing additional patches applied to a
package received as a tarball or maintained in another version control
system. The stacked organization proved to be efficient for the
management of very large patch sets (more than hundred patches).

With quilt, all work occurs within a single directory tree. Since
version 0.30, commands can be invoqued from anywhere within the source
tree. Commands are of the form quilt cmd, similar to CVS commands.
They can be abbreviated as long as the specified part of the command
is unique. All commands print some help text with "quilt  -h".

CHANGES SINCE LAST RELEASE
==

- Patches from Debian project are included.

INSTALL OR UPGRADE NOTES


None.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

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

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

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

cygwin-announce-unsubscribe-you=yourdomain.com(at)cygwin.com

More information on unsubscribing can be found:

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

Please read *all* of the information on unsubscribing that is available
starting at the above 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

[ANNOUNCEMENT] Updated: python-feedparse 5.0.1-1 -- Universal Feed Parser for Python

[Jari Aalto]

PACKAGE DESCRIPTION
===

Homepage: http://feedparser.org
License : MIT

Python module for downloading and parsing syndicated feeds. It can
handle RSS 0.90, Netscape RSS 0.91, Userland RSS 0.91, RSS 0.92, RSS
0.93, RSS 0.94, RSS 1.0, RSS 2.0, Atom, and CDF feeds. Provides the
same API to all formats, and sanitizes URIs and HTML.

CHANGES SINCE LAST RELEASE
==

/usr/share/doc/feedparser-*/changes-*.html
http://code.google.com/p/feedparser/source/browse/trunk/www/docs/ => changes

INSTALL OR UPGRADE NOTES


Standard install.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

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

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

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

cygwin-announce-unsubscribe-you=yourdomain.com(at)cygwin.com

More information on unsubscribing can be found:

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

Please read *all* of the information on unsubscribing that is available
starting at the above 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

[ANNOUNCEMENT] Updated: arc 5.21p-1 -- The ARC archive utility

[Jari Aalto]

PACKAGE DESCRIPTION
===

Homepage: http://www.sourceforge.net/projects/arc
License : GPL

This program is based on the MSDOS ARC program, version 5.21, plus a
few enhancements. ARC performs Huffman Squeezing on data. The Huffman
Squeeze algorithm was removed from MSDOS ARC after version 5.12. It
turns out to be more efficient than Lempel-Ziv style compression when
compressing graphic images. Squeeze analysis is always done now, and
the best of packing, squeezing, or crunching is used.

CHANGES SINCE LAST RELEASE
==

http://arc.cvs.sourceforge.net/arc/arc/Changelog?revision=HEAD&view=markup

INSTALL OR UPGRADE NOTES


Standard install.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

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

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

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

cygwin-announce-unsubscribe-you=yourdomain.com(at)cygwin.com

More information on unsubscribing can be found:

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

Please read *all* of the information on unsubscribing that is available
starting at the above 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

OSS device names under Cygwin

[Johan Henkens]

I'm trying to expand the usability of Shairport, a recent Airplay software that 
uses the libao audio library to support the output to specified devices under 
Windows 7 with cygwin. However, I have been unable to find any information on 
how to access the different device names or ID's for the different output 
devices for the oss implementation (default for libao in cygwin in appears). I 
have figured it out using the wmm implementation in libao, but I am still 
curious as to if it can be solved without switching the audio driver.

What are / how can I find out more about the device id's/names that would be 
needed to get selectable audio output using oss with libao?

--
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 No Longer Works After A Cygwin Upgrade

[Ken Brown]

On 4/18/2011 5:44 PM, Tim Daneliuk wrote:

On 4/18/2011 3:27 PM, Ken Brown wrote:

On 4/18/2011 4:02 PM, marco atzeri wrote:

On Mon, Apr 18, 2011 at 10:01 PM, Tim Daneliuk wrote:

This has happened the last few times I did an upgrade with setup.exe.
emacs, emacs-nox, and emacs -nw will not start at all. Xemacs works
fine.

Previously, I was able to work around this by falling back to a
previous version of emacs, but this too seems broken now.

Ideas?


http://cygwin.com/problems.html


While we're waiting for a full problem report, I'll make my best guess: The OP 
needs to run rebaseall.

Ken


I already tried this.  No go.


And what about the other two suggestions you've been given in this thread:

1. http://cygwin.com/problems.html

2. cygcheck /usr/bin/emacs

Ken


--
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 No Longer Works After A Cygwin Upgrade

[Tim Daneliuk]

On 4/19/2011 6:57 AM, Ken Brown said this:
> On 4/18/2011 5:44 PM, Tim Daneliuk wrote:
>> On 4/18/2011 3:27 PM, Ken Brown wrote:
>>> On 4/18/2011 4:02 PM, marco atzeri wrote:
 On Mon, Apr 18, 2011 at 10:01 PM, Tim Daneliuk wrote:
> This has happened the last few times I did an upgrade with setup.exe.
> emacs, emacs-nox, and emacs -nw will not start at all. Xemacs works
> fine.
>
> Previously, I was able to work around this by falling back to a
> previous version of emacs, but this too seems broken now.
>
> Ideas?

 http://cygwin.com/problems.html
>>>
>>> While we're waiting for a full problem report, I'll make my best guess: The 
>>> OP needs to run rebaseall.
>>>
>>> Ken
>>
>> I already tried this.  No go.
> 
> And what about the other two suggestions you've been given in this thread:
> 
> 1. http://cygwin.com/problems.html
> 
> 2. cygcheck /usr/bin/emacs
> 

I finally just did a clean reinstall of the whole system.  It likely
took less time to do this than to track down whatever obscure
anomaly was glitching up emacs ...
-- 

Tim Daneliuk
tun...@tundraware.com

--
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 No Longer Works After A Cygwin Upgrade

[Warren Young]

I don't think cygcheck can resolve a symlink.

(I'm not near a Windows machine to test right now)


For the archives, yes, it can.

I don't have emacs on my machine (vi is the one true editor) but the 
only difference between the two invocation methods is that if you pass a 
symlink, cygcheck emits an extra line at the start indicating that it 
chased a link.  Something like this:


-> C:\cygwin\bin\emacs-nox.exe

I tested this with /bin/infotocap vs. /bin/tic.exe.

(Why that pair?  It just grabbed my attention first after ls /bin.)

--
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: Octave Plotting, Invoking Octave

[Doug Pace]

Thanks Marco

  I deleted the cygwin directory and reinstalled, selecting cygwin 1.7.8-1.
This did not work either; but I may have done a rebaseall after installing 
octave.

Got octave working with this sequence:

install cygwin, with x11; do a >/cygwin/bin/ash ? ./rebaseall;
run setup again:  downgrade to 1.7.8-1, select octave, octave-forge ...;
(do NOT run ./rebaseall)
now sombrero demo plot works in octave.
BUT with the figure displayed a second Octave -> figure  command does not work.

Doug

REFERENCE:  http://cygwin.com/ml/cygwin/2011-04/msg00252.html

On Mon, Apr 18, 2011 at 6:25 PM, Doug Pace  wrote:

Installed cygwin with gnuplot, X11, and octave.

Octave will not run the 'sombrero' demo plot.

Have removed c:\cygwin and reinstalled; have attempted previous releases of
cygwin and octave.
Yes, I needed to use ash and do
? ? ? ? ? ?$ ./rebaseall
to get startx to work.

Now octave no longer opens, no error messages are issued just returns to the
shell prompt.

This is on XP sp 3.
Thanks for any help,


Doug,
rebaseall seems to break octave on WinXP. I already noted it on 1.7.9
and on some snapshots.

Workaround.
- reinstall octave
- downgrade cygwin from 1.7.9-1 to 1.7.8-1

At least on my WinXP SP3 it works.


--
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: Octave Plotting, Invoking Octave

[marco atzeri]

On Tue, Apr 19, 2011 at 4:09 PM, Doug Pace  wrote:
> Thanks Marco
>
>  I deleted the cygwin directory and reinstalled, selecting cygwin 1.7.8-1.
> This did not work either; but I may have done a rebaseall after installing
> octave.
>
> Got octave working with this sequence:
>
> install cygwin, with x11; do a >/cygwin/bin/ash ? ./rebaseall;
> run setup again:  downgrade to 1.7.8-1, select octave, octave-forge ...;
> (do NOT run ./rebaseall)
> now sombrero demo plot works in octave.
> BUT with the figure displayed a second Octave -> figure  command does not
> work.

For me it is fine.

octave:1> sombrero
octave:2> figure (2)
octave:3> x=1:10;
octave:4> plot(x,x)
octave:5> figure (3)
octave:6> plot(x,x)

and I have 3 window plots.

>
> Doug
>

Marco

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

named pipe (fifo) question

[bob 295]

I'm porting a library from Linux to Cygwin and I've encountered a problem with 
the behavior of named pipes (fifo's).

In my sequence a pair of fifos are opened by each end of the conversation.   
One is opened as WRONLY,  the other as RDWR.   Some documentation seems to 
frown on RDWR pipes.   We found that this allows us to trap certain errors 
when processes on other ends of the pipe vanish.

The message exchange sequence is then:

For the sender
i) open the WRONLY pipe to receiver
ii) write an integer on the WRONLY pipe
iii) drop into a read on the RDWR pipe (which blocks in Linux)

For the receiver
i) drop into read on the RDWR pipe (which blocks in Linux)
ii) process the message
iii) open the WRONLY end of pipe for response
iv) write an integer onto the WRONLY pipe back to sender
v) close the WRONLY end of pipe

The sender leaves the WRONLY pipe open in case another message will be sent.  
It only closes the file descriptor upon process exit.   The receiver opens, 
writes and closes its WRONLY end on each pass.  In Linux this sequence works 
just fine and has been working in all versions for at least 10 years now.

However,  on Cygwin it would appear that after the first time the receiver 
closes the WRONLY end of the sender's pipe,  the sender's next read comes 
back with a 0 (eof) repeatedly without ever blocking.  

Is this the intended POSIX behavior?   Is the problem the RDWR open? 

Thanks in advance for your help.

bob


--
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: named pipe (fifo) question

[Christopher Faylor]

On Tue, Apr 19, 2011 at 11:01:55AM -0400, bob 295 wrote:
>I'm porting a library from Linux to Cygwin and I've encountered a problem with 
>the behavior of named pipes (fifo's).
>...
>Is this the intended POSIX behavior?   Is the problem the RDWR open? 

The problem is that Cygwin's implementation of fifos is very buggy.  I wouldn't
recommend using them for anything but the simplest of applications.

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

[ANNOUNCEMENT] Cygwin now licensed under GPLv3+

[Corinna Vinschen]

Hi Cygwin friends and users,


I'm happy to announce that, effective immediately, Red Hat has
relicensed Cygwin from "GNU Public License version 2" (GPLv2) to
"GNU Public License version 3 or later" (GPLv3+).

The Open Source Licensing Exception persists, as well as the
availability of the Cygwin Alternative License, as described on
http://cygwin.com/licensing.html

This shouldn't affect a lot of you, but if you're concerned that this
change in the Cygwin license might affect you and your projects, see
http://www.gnu.org/licenses/ in the first place.  You can also ask
questions on the cygwin or cygwin-licensing mailing list, but be aware
that we can't give valid legal advice.  It's always better to ask
a lawyer who's specialized in licensing questions.


Have fun,
Corinna


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

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.


-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developercygwin AT cygwin DOT com
Red Hat, Inc.

--
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: Linking statically against GraphicsMagick: problems with libxml2 and libpng

[Dmitry Katsubo]

Hi Marc,

On 05.04.2011 10:48, marco atzeri wrote:
> you can check the package source and propose the change

I have went through the manual installation of libxml: the package was
installed absolutely OK. After "make install" I got:

$ ls -1 /usr/local/lib/libxml2*
/usr/local/lib/libxml2.a
/usr/local/lib/libxml2.dll.a
/usr/local/lib/libxml2.la

$ ls -1 /usr/local/bin/cygxml2*
/usr/local/bin/cygxml2-2.dll

I believe this is Cygwin packaging problem, which does not put libxml2.a
into destination devel package. I am not familiar with how the binary
packages are created. Perhaps you can help me here. Is it possible to
have a look at the logs at Cygwin build server? I can attach mine, which
show how libxml2.a is successfully build and installed.

-- 
With best regards,
Dmitry

--
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: Linking statically against GraphicsMagick: problems with libxml2 and libpng

[marco atzeri]

On Tue, Apr 19, 2011 at 8:36 PM, Dmitry Katsubo wrote:
> Hi Marc,
>
> On 05.04.2011 10:48, marco atzeri wrote:
>> you can check the package source and propose the change
>
> I have went through the manual installation of libxml: the package was
> installed absolutely OK. After "make install" I got:
>
> $ ls -1 /usr/local/lib/libxml2*
> /usr/local/lib/libxml2.a
> /usr/local/lib/libxml2.dll.a
> /usr/local/lib/libxml2.la
>
> $ ls -1 /usr/local/bin/cygxml2*
> /usr/local/bin/cygxml2-2.dll
>
> I believe this is Cygwin packaging problem, which does not put libxml2.a
> into destination devel package. I am not familiar with how the binary
> packages are created. Perhaps you can help me here. Is it possible to
> have a look at the logs at Cygwin build server? I can attach mine, which
> show how libxml2.a is successfully build and installed.

Hi Dmitry,
there is no cygwin build server. Any maintainer build the packages by itself.
To replicate download the source package with setup and

$ cd /usr/src
$ cygport libxml2-2.7.7-1.cygport prep compile


>From the Yaakov's package source build log  I see :

checking whether to build shared libraries... yes
checking whether to build static libraries... no

so something is blocking the "theoretical" default configuration

  --enable-shared[=PKGS]  build shared libraries [default=yes]
  --enable-static[=PKGS]  build static libraries [default=yes]

and looking on configure we see that the default seems no

--
  # Check whether --enable-static was given.
if test "${enable_static+set}" = set; then :
  enableval=$enable_static; p=${PACKAGE-default}
case $enableval in
yes) enable_static=yes ;;
no) enable_static=no ;;
*)
 enable_static=no
  # Look at the argument we got.  We use all the common list separators.
  lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
  for pkg in $enableval; do
IFS="$lt_save_ifs"
if test "X$pkg" = "X$p"; then
  enable_static=yes
fi
  done
  IFS="$lt_save_ifs"
  ;;
esac
else
  enable_static=yes
fi
-

so an enable static should be added to the .cygport.

> --
> With best regards,
> Dmitry
>

Marco

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

0417 snapshot: exec() fails on /proc/self/exe

[Andy Koppe]

With the latest snapshot, exec() fails on /proc/self/exe:

$ cat test.c
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
  if (argc > 1 && !fork()) {
execl("/proc/self/exe", argv[0], (char *)0);
puts(strerror(errno));
  }
  return 0;
}

$ cc test.c

$ ./a bla
Bad file descriptor

With 1.7.9, it prints nothing, which is the expected behaviour.
Looking at POSIX, EBADF is not a valid errno for exec().

(The argument in the test is there as a way to stop it from becoming a
fork bomb.)

Andy

--
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, mailto: URLs, and launching an executable

[Wm. David Bentlage]

Hi,

What's the reason for the following change in cygstart between cygwin
1.5 and 1.7?  Can the cygwin 1.5 behavior be restored?


ai016aadm01@app-stl-33 ~
$ uname -a
CYGWIN_NT-5.2 app-stl-33 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin

ai016aadm01@app-stl-33 ~
$ cygstart -v mailto:
ShellExecute(NULL, "(null)", "mailto:";, "(null)", "(null)", 1)

ai016aadm01@app-stl-33 ~
$ cygstart -v bash
ShellExecute(NULL, "(null)", "bash", "(null)", "(null)", 1)



ai016aadm01@app-stl-33 ~
$ uname -a
CYGWIN_NT-5.2 app-stl-33 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin

ai016aadm01@app-stl-33 ~
$ cygstart -v mailto:
ShellExecute(NULL, "(null)", "W:\home\m278638\mailto", "(null)", "(null)", 1)
Unable to start 'W:\home\m278638\mailto': The specified file was not found.

ai016aadm01@app-stl-33 ~
$ cygstart -v bash
ShellExecute(NULL, "(null)", "W:\home\m278638\bash", "(null)", "(null)", 1)
Unable to start 'W:\home\m278638\bash': The specified file was not found.


Under cygwin 1.5, I could open a new email in the default application
using "cygstart mailto:".  Under cygwin 1.7, I get an error.
Performing "cygstart mailto://"; will get cygwin 1.7 cygstart to
recognize mailto: as a URL instead of a file, but that's not proper
mailto: URL syntax.

Under cygwin 1.5, a new bash window is launched (per the man page).
Under cygwin 1.7, I get an error.  I can open bash in cygwin 1.7 if I
specify the full path to the bash executable.

Thanks,
Dave B.

--
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: Memory leak in select

[Peter Rosin]

Den 2011-04-18 21:23 skrev Peter Rosin:
> Den 2011-04-18 17:28 skrev Christopher Faylor:
>> On Mon, Apr 18, 2011 at 11:24:41AM -0400, Christopher Faylor wrote:
>>> On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
 Den 2011-04-18 14:23 skrev Peter Rosin:
> Den 2011-04-18 13:43 skrev Peter Rosin:
>> Hi!
>>
>> Using the following STC, I'm seeing what appears to be a memory
>> leak in select(2).
>>
> 8<---(selectleak.c)-
> #include 
> #include 
>
> int
> main(void)
> {
>   fd_set fdset;
>
>   long flags = fcntl(0, F_GETFL);
>   fcntl(0, F_SETFL, flags | O_NONBLOCK);
>
>   for (;;) {
>   int res;
>   char buf[20];
>
>   FD_ZERO(&fdset);
>   FD_SET(0, &fdset);
>   res = select(1, &fdset, NULL, NULL, NULL);
>   if (!res)
>   continue;
>   if (res < 0)
>   return 1;
>   res = read(0, buf, sizeof(buf));
>   if (!res)
>   break;
>   if (res < 0)
>   return 1;
>   }
>
>   return 0;
> }
> 8<--

 Ok, I'm taking a wild swing at this, and my guess is that the call
 sel.cleanup () in cygwin_select prematurely zeros out the cleanup
 member of the select_record. The call to sel.poll () then adds
 "stuff" to the select_record that really should have been cleaned
 up, but isn't since cleanup has already been executed and then
 zapped (by select_stuff::cleanup).

 But what do I know?
>>>
>>> How does sel.poll add "stuff" that should be cleaned up?  That function
>>> only looks for bits to set.
> 
> I shouldn't have included the strace, and I shouldn't have guessed about
> the cause of the problem without verifying my claims. Sorry about that.
> But for the record the included strace snippet is reoccurring like that
> many many times (the address of the allocation that isn't freed is
> moving).  Further evidence; the STC leaks 1 MB every 3 seconds on my
> computer, that just can't be right.

Back with a patch this time.  Fixes it for me...

Cheers,
Peter

2011-04-19  Peter Rosin  

* select.cc (pipe_cleanup): Don't leak a select_pipe_info when a
thread turned out not to be needed.

Index: select.cc
===
RCS file: /cvs/src/src/winsup/cygwin/select.cc,v
retrieving revision 1.163
diff -u -r1.163 select.cc
--- select.cc   4 Apr 2011 12:23:36 -   1.163
+++ select.cc   19 Apr 2011 21:25:44 -
@@ -644,13 +644,15 @@
 pipe_cleanup (select_record *, select_stuff *stuff)
 {
   select_pipe_info *pi = (select_pipe_info *) stuff->device_specific_pipe;
-  if (pi && pi->thread)
+  if (!pi)
+return;
+  if (pi->thread)
 {
   pi->stop_thread = true;
   pi->thread->detach ();
-  delete pi;
-  stuff->device_specific_pipe = NULL;
 }
+  delete pi;
+  stuff->device_specific_pipe = NULL;
 }
 
 int

--
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: cygstart, mailto: URLs, and launching an executable

[Charles Wilson]

On 4/19/2011 4:58 PM, Wm. David Bentlage wrote:
> Under cygwin 1.5, a new bash window is launched (per the man page).
> Under cygwin 1.7, I get an error.  I can open bash in cygwin 1.7 if I
> specify the full path to the bash executable.

cygwin-1.4.0:

* Support in cygstart for unicode arguments/filenames
  (from IWAMURO Motonori).

IIRC, part of this change affected how "bare" names (e.g. without paths)
were handled, to facilitate proper unicode support.

This may be relevant:
http://cygwin.com/ml/cygwin/2010-01/msg01101.html
but I never got a patch.

I suspect this will need debugging for the 'bash' case, and an explicit
workaround for 'mailto:'.

PTC...

--
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: 0417 snapshot: exec() fails on /proc/self/exe

[Eric Blake]

On 04/19/2011 02:16 PM, Andy Koppe wrote:
> int main(int argc, char *argv[])
> {
>   if (argc > 1 && !fork()) {
> execl("/proc/self/exe", argv[0], (char *)0);
> puts(strerror(errno));
>   }
>   return 0;
> }
> 
> $ cc test.c
> 
> $ ./a bla
> Bad file descriptor
> 
> With 1.7.9, it prints nothing, which is the expected behaviour.
> Looking at POSIX, EBADF is not a valid errno for exec().

EBADF is not listed for execl(), but _is_ listed for fexecve(), and when
you consider that /proc/self is a special file system that opens file
descriptors rather than files, it makes (a bit) of sense.  At any rate,
POSIX states that other errors than those documented (such as EBADF for
execl()) may be returned if the condition for those errors matches other
use of that errno value and does not skip over any existing mandated
errors.  It also means that maybe cygwin should behave as if O_EXEC
rather than O_RDONLY were used when populating "/proc/self/exe", seeing
as how execl() on that file basically boils down to an fexecve() call.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Idea on how to improve cygstart

[SJ Wright]

Hi.

Well, maybe there's a better word than "improve." Maybe "streamline" 
would be better. Anyhow, here it is.


Allow users to create a list of paths to GUI apps they have on their 
systems -- other than the selected Windows defaults -- and using either 
aliases (like "monkey" for SeaMonkey 2.0 or "irfan" for IrfanView) or a 
syntax similar to how ImageMagick used to work (library:filetype) when 
converting files from one format to another, facilitate quick and easy 
opening of files in applications Cygwin users would _prefer to open them 
in, rather than the assigned default.


Should this prove to be too radical a re-working of cygstart, then 
perhaps it's time to introduce another utility to perform the above 
tasks, and have it install with Cygwin and update with upgrades. Maybe 
call it "userstart" or "winstart" or something along those lines?


Unless I miss my guess, this might put Cygwin ahead of complete and 
genuine Linux/Unix distributions such as Ubuntu, It's been my experience 
with the latter that instead of system defaults, one only has recourse 
on the command line to a spare list of GUI apps that open different file 
types, and not all of them are "out-of-the-box" Debian or GNOME 
installs, which puts one at a disadvantage (if only w/regard to the time 
involved in doing "apt-gets").


Steve W

--
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: Memory leak in select

[Christopher Faylor]

On Tue, Apr 19, 2011 at 11:31:38PM +0200, Peter Rosin wrote:
>Den 2011-04-18 21:23 skrev Peter Rosin:
>> Den 2011-04-18 17:28 skrev Christopher Faylor:
>>> On Mon, Apr 18, 2011 at 11:24:41AM -0400, Christopher Faylor wrote:
 On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
> Den 2011-04-18 14:23 skrev Peter Rosin:
>> Den 2011-04-18 13:43 skrev Peter Rosin:
>>> Hi!
>>>
>>> Using the following STC, I'm seeing what appears to be a memory
>>> leak in select(2).
>>>
>> 8<---(selectleak.c)-
>> #include 
>> #include 
>>
>> int
>> main(void)
>> {
>>  fd_set fdset;
>>
>>  long flags = fcntl(0, F_GETFL);
>>  fcntl(0, F_SETFL, flags | O_NONBLOCK);
>>
>>  for (;;) {
>>  int res;
>>  char buf[20];
>>
>>  FD_ZERO(&fdset);
>>  FD_SET(0, &fdset);
>>  res = select(1, &fdset, NULL, NULL, NULL);
>>  if (!res)
>>  continue;
>>  if (res < 0)
>>  return 1;
>>  res = read(0, buf, sizeof(buf));
>>  if (!res)
>>  break;
>>  if (res < 0)
>>  return 1;
>>  }
>>
>>  return 0;
>> }
>> 8<--
>
> Ok, I'm taking a wild swing at this, and my guess is that the call
> sel.cleanup () in cygwin_select prematurely zeros out the cleanup
> member of the select_record. The call to sel.poll () then adds
> "stuff" to the select_record that really should have been cleaned
> up, but isn't since cleanup has already been executed and then
> zapped (by select_stuff::cleanup).
>
> But what do I know?

 How does sel.poll add "stuff" that should be cleaned up?  That function
 only looks for bits to set.
>> 
>> I shouldn't have included the strace, and I shouldn't have guessed about
>> the cause of the problem without verifying my claims. Sorry about that.
>> But for the record the included strace snippet is reoccurring like that
>> many many times (the address of the allocation that isn't freed is
>> moving).  Further evidence; the STC leaks 1 MB every 3 seconds on my
>> computer, that just can't be right.
>
>Back with a patch this time.  Fixes it for me...
>
>Cheers,
>Peter
>
>2011-04-19  Peter Rosin  
>
>   * select.cc (pipe_cleanup): Don't leak a select_pipe_info when a
>   thread turned out not to be needed.

Makes sense.  I've checked this in (with a different ChangeLog).

Thanks for the patch.

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: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-23.3-2 (TEST)

[Ken Brown]

On 3/25/2011 6:36 AM, Ken Brown wrote:

New test releases of the emacs, emacs-X11, and emacs-el packages
(23.3-2) are now available, leaving 23.3-1 as current and 23.2-3 as
previous.  These are rebuilds of the 23.3-1 packages, patched to use
mmap for buffer allocation.

Please test this release and report any problems to the Cygwin mailing
list.  If no regressions are reported, I will promote this release to
current in a few weeks.


No regressions were reported, so the 23.3-2 packages are now current, 
leaving 23.3-1 as previous.


Ken

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

[1.7.9] frequent five-second pauses for no apparent reason

[Jeremy Hetzler]

As of today, I'm experiencing intermittent five-second pauses when I
run Cygwin processes. Even the simplest executables (ls, mkdir) can
experience these freezes. I can't break out of them with ctrl-c. I
stripped down my PATH to /usr/bin with no effect. My Cygwin
installation and home directory are on a local drive.

It sometimes seems to happen on process exit. For example, 'ls --help'
will sometimes print the help and then freeze. Long-running
interactive processes (vim, less) don't seem to freeze during
execution.

I can make it happen more often by stressing the CPU with other Cygwin
processes. For example, a terminal running "while true; do time
ls>/dev/null; sleep 1; done" will only show the problem once in a
while. If I open another terminal and run "while true; do true; done",
it happens constantly.

This only started today, when I ran setup.exe and upgraded everything,
including the cygwin package. Was something changed that might be
causing this?

CYGWIN_NT-5.1 HetzlerXP 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
on WinXP.

Thanks,
Jeremy Hetzler


cygcheck.out
Description: Binary data
--
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: 0417 snapshot: exec() fails on /proc/self/exe

[Andy Koppe]

On 19 April 2011 21:16, Andy Koppe wrote:
> With the latest snapshot, exec() fails on /proc/self/exe:
>
> $ cat test.c
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main(int argc, char *argv[])
> {
>  if (argc > 1 && !fork()) {
>    execl("/proc/self/exe", argv[0], (char *)0);
>    puts(strerror(errno));
>  }
>  return 0;
> }
>
> $ cc test.c
>
> $ ./a bla
> Bad file descriptor
>
> With 1.7.9, it prints nothing, which is the expected behaviour.
> Looking at POSIX, EBADF is not a valid errno for exec().

No need for that test case actually. Symbolic links within /proc just
seem to be broken:

$ ls -l /proc/self/exe
ls: cannot read symbolic link /proc/self/exe: Invalid argument
lrwxrwxrwx 1 Andy None 0 Apr 20 06:15 /proc/self/exe

$ ls -l /proc/3372
ls: cannot read symbolic link /proc/3372/cwd: Invalid argument
ls: cannot read symbolic link /proc/3372/exe: Invalid argument
ls: cannot read symbolic link /proc/3372/root: Invalid argument
total 0
-r--r--r-- 1 Andy None 0 Apr 20 06:14 cmdline
-r--r--r-- 1 Andy None 0 Apr 20 06:14 ctty
lrwxrwxrwx 1 Andy None 0 Apr 20 06:14 cwd
lrwxrwxrwx 1 Andy None 0 Apr 20 06:14 exe
-r--r--r-- 1 Andy None 0 Apr 20 06:14 exename
...

Andy

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