Hello,
The /usr/include/sys/poll.h file in the latest snapshot is broken.
--- test.c -
#include
int main(void)
{
return 0;
}
--
$ gcc a.c
In file included from /usr/include/poll.h:11,
On Thu, Apr 21, 2011 at 3:06 AM, Christopher Faylor wrote:
> I just noticed today that cygz.dll was rebased right into the middle of
> cygwin1.dll's address range. So, I added a -v to the rebaseall run and
> saw that there were quite a few dlls stomping all over cygwin.
>
> I wonder if this expla
I just noticed today that cygz.dll was rebased right into the middle of
cygwin1.dll's address range. So, I added a -v to the rebaseall run and
saw that there were quite a few dlls stomping all over cygwin.
I wonder if this explains why we're seeing problems which are not cured
by rebase? Maybe r
SJ Wright sent the following at Tuesday, April 19, 2011 7:31 PM
>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 --
On 4/20/2011 12:01 PM, Eric Blake wrote:
On 04/20/2011 09:51 AM, Harry Putnam wrote:
Do you have CRLF line endings on your ~/.inputrc? That would explain
failures. To fix it, run 'd2u ~/.inputrc'. Other than that, it works
for me, so I'm not sure why you're having problems.
A great sugges
Christopher Faylor wrote:
> I forgot to add one bit of data. Unless you go out of your way to
> change it, Cygwin's select can't wait for an fd > 63. It's basically a
> bit mask. So, there are two limitations: 1) the number of handles that
> you can wait for with WaitForMultipleObjects() and 2)
On 04/20/2011 09:51 AM, Harry Putnam wrote:
> setup: Cygwin (very recent update) on win 7 (64bit)
>
>ls /etc/setup/*read*
> /etc/setup/libreadline7.lst.gz /etc/setup/readline.lst.gz
>
> ---- ---=--- -
>
> I've never had a cygwin inst
setup: Cygwin (very recent update) on win 7 (64bit)
ls /etc/setup/*read*
/etc/setup/libreadline7.lst.gz /etc/setup/readline.lst.gz
---- ---=--- -
I've never had a cygwin install where using an ~/.inputrc worked.
I've tried quite a few
On Wed, Apr 20, 2011 at 09:48:09AM -0400, bob 295 wrote:
>(I'm on the list in digest mode so things can't thread easily)
>
>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 (f
Issuing
figure(2)
generates:
octave:1> sombrero
octave:2> figure(2)
0 [main] octave-3.4.0 5048 C:\cygwin\bin\octave-3.4.0.exe: ***
fatal error - couldn't release memory 0x19221000(61440) for
'\\?\C:\cygwin\lib\octave\3.4.0\oct\i686-pc-cygwin\lookup.oct'
alignment, Win32 error 487
Stack t
Hello,
I have test my patch, but it not resolve my memory issue (
http://cygwin.com/ml/cygwin/2011-04/msg00292.html )
Regards,
Thomas
2011/4/20 Corinna Vinschen
> On Apr 20 15:16, Thomas Stalder wrote:
>> I don't know, it's just a question. The patch are not tested.
>
> Maybe you should actuall
(I'm on the list in digest mode so things can't thread easily)
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 p
On Apr 20 15:16, Thomas Stalder wrote:
> Hello,
>
> I just have a question, the same change would it not necessary for the
> functions: serial_cleanup, mailslot_cleanup and socket_cleanup in
> select.cc (like attached patch) ?
>
> I don't know, it's just a question. The patch are not tested.
May
Hello,
I just have a question, the same change would it not necessary for the
functions: serial_cleanup, mailslot_cleanup and socket_cleanup in
select.cc (like attached patch) ?
I don't know, it's just a question. The patch are not tested.
Regards,
Thomas
2011/4/20 Christopher Faylor
>>2011-04
Works well!
Many thanks,
Thomas
2011/4/18 Corinna Vinschen
> I applied a fix which enforces the Linux behaviour. Please give the
> next developer snapshot from http://cygwin.com/snapshots/ a try.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com
Hello,
Thanks for the fix.
I have made some tests with the CVS version and I don't have anymore
not closed Handle, but I still have a memory leaks.
I have made 2 testcases :
$ gcc server.c -o server
$ gcc server.c -Dnoleak -o servernoleak
$ gcc client.c -o client
I execute sever.exe and client
On Apr 20 06:15, Andy Koppe wrote:
> No need for that test case actually. Symbolic links within /proc just
> seem to be broken:
Fixed in CVS. Just an oversight when the /proc virtual devices
have been renumbered a couple of days ago.
Thanks for the report,
Corinna
--
Corinna Vinschen
Den 2011-04-20 03:10 skrev Christopher Faylor:
> On Tue, Apr 19, 2011 at 11:31:38PM +0200, Peter Rosin wrote:
>>> Den 2011-04-18 13:43 skrev Peter Rosin:
Using the following STC, I'm seeing what appears to be a memory
leak in select(2).
>> Back with a patch this time. Fixes i
18 matches
Mail list logo
