headers
Glyn | 1 Aug 2012 08:47
Picon
Favicon

libgc bug when using Gnu C nested functions

/*
This small program causes a libgc error when compiled and run in Cygwin:

     $ gcc gcerror.c -lgc -o x.exe
     $ ./x.exe
     42
     GC Warning: Thread stack pointer 0x22aa98 out of range, pushing 
everything
*/

#include <gc/gc.h>
#include <stdio.h>

void *dummy;

void f (void (*x)())
{
     x();
}

int main ()
{
     int i;

     void g ()
     {
         printf("%i\n", i);
     }

     i = 42;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 1 Aug 2012 09:02
Favicon

Re: sshd crashing

On Jul 31 15:59, A Lichner wrote:
> 
> Thanks Corinna. The fix works.
> Ales
> 
> 
> Corinna Vinschen-2 wrote:
> > 
> > On Jul 31 14:28, Corinna Vinschen wrote:
> >> On Jul 30 17:49, Aleš wrote:
> >> > 
> >> > Hello,
> >> > 
> >> > I can confirm the issue. It's occurring after upgrade to 1.7.16 and
> >> seems to
> >> > be limited to VMWare guests in my case. Any write attempt within the
> >> /etc
> >> > directory causes sshd to crash. Other directories are fine.
> >> > 
> >> > uname -a before upgrade (sshd doens't crash):
> >> > CYGWIN_NT-6.0-WOW64 dbs6 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
> >> > and after upgrade (sshd crashes):
> >> > CyGWIN_NT-6.0-WOW64 dbs6 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin
> >> > 
> >> > 
> >> > cygrunsrv -S sshd
> >> > ssh localhost
> >> > $ touch /etc/x
> >> > Connection to localhost closed by remote host.
> >> > Connection to localhost closed.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Corinna Vinschen | 1 Aug 2012 11:05
Favicon

Re: Using recvmsg() with non-unicast datagram (UDP) socket: inconsistent results

On Jul 31 12:43, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hi,
> 
> Observed is an inconsistent result when recvmsg() is used on a
> UDP socket with or without ancillary control message parameters.
> 
> Here's is an example:
> 
>     static char buf[1 << 16];
>     struct sockaddr_in sin;
>     struct msghdr msg;
>     struct iovec iov;
> #ifndef CYGWIN_BUG
>     char cmsgbuf[32];
> #endif /*CYGWIN_BUG*/
>     int n;
> 
>     iov.iov_base       = buf;
>     iov.iov_len        = sizeof(buf);
>     memset(&sin, 0, sizeof(sin));
>     memset(&msg, 0, sizeof(msg));
>     msg.msg_name       = (caddr_t) &sin;
>     msg.msg_namelen    = sizeof(sin);
>     msg.msg_iov        = &iov;
>     msg.msg_iovlen     = 1;
> #ifndef CYGWIN_BUG
>     memset(cmsgbuf, 0, sizeof(cmsgbuf));
>     msg.msg_control    = cmsgbuf;
>     msg.msg_controllen = sizeof(cmsgbuf);
> #endif /*CYGWIN_BUG*/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nikolai Weibull | 1 Aug 2012 11:12
Picon
Gravatar

Perl 5.14.2 seems to expect gcc-4

Hi!

Cygwin updated perl to 5.14.2 on my system and now I can’t compile
XML::LibXML.  It seems that

c:\lib\perl5\5.14\i686-cygwin-threads-64int\Config.pm

expects cc to be gcc-4.  Gcc-4 doesn’t exist yet, it seems.  What’s
going on here?
Permalink | Reply | 11 comments |
headers
Nikolai Weibull | 1 Aug 2012 11:18
Picon
Gravatar

Re: Perl 5.14.2 seems to expect gcc-4

On Wed, Aug 1, 2012 at 11:12 AM, Nikolai Weibull <now <at> bitwi.se> wrote:
> Hi!
>
> Cygwin updated perl to 5.14.2 on my system and now I can’t compile
> XML::LibXML.  It seems that
>
> c:\lib\perl5\5.14\i686-cygwin-threads-64int\Config.pm
>
> expects cc to be gcc-4.  Gcc-4 doesn’t exist yet, it seems.  What’s
> going on here?

Sorry, scratch that, gcc-4 is available.  I got confused by the
separate version schemes (which I realize are necessary, but easy to
miss when you’re a bit stressed out.)
Permalink | Reply | 10 comments |
headers
Corinna Vinschen | 1 Aug 2012 11:32
Favicon

Re: sshd crashing

On Aug  1 09:02, Corinna Vinschen wrote:
> On Jul 31 15:59, A Lichner wrote:
> > 
> > Thanks Corinna. The fix works.
> > Ales
> > [...]
> > Corinna Vinschen-2 wrote:
> > > I've just applied a patch to fix this problem.  It seems this is a long
> > > standing bug which could result in random stack corruption after changing
> > > or adding any file to /etc.  I'm just generating a developer snapshot.
> > > Please test the today's snapshot from http://cygwin.com/snapshots/
> > > Just replacing /bin/cygwin1.dll with the snapshot DLL is sufficient.
> 
> Thanks to you and Pawel for your feedback.

I've just uploaded another snapshot.  Can you please test this one as
well?

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Permalink | Reply | 2 comments |
headers
Corinna Vinschen | 1 Aug 2012 11:43
Favicon

Re: crash on latest cygwin snapshot

Hi Marco, Hi Ken,

On Jul  2 16:43, marco atzeri wrote:
> On 6/27/2012 3:46 AM, Christopher Faylor wrote:
> >
> >Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
> >I'm still working on it.
> >
> >cgf
> >
> 
> it seems solved on 20120702 snapshots

can you please test your crashing scenarios with the latest developer
snapshot from today?  After some private discussion, cgf and I have a
hunch that the underlying problem was the problem I fixed yesterday, and
cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
code optimization so that your problem wasn't visible anymore.

I reverted cgf's changes to Makefile.in and generated the today's
snapshot specificially to test our hypothesis.  Please give it a try.

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
(Continue reading)

Permalink | Reply | 24 comments |
headers
marco atzeri | 1 Aug 2012 12:34
Picon

Re: crash on latest cygwin snapshot

On 8/1/2012 11:43 AM, Corinna Vinschen wrote:
> Hi Marco, Hi Ken,
>
> On Jul  2 16:43, marco atzeri wrote:
>> On 6/27/2012 3:46 AM, Christopher Faylor wrote:
>>>
>>> Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
>>> I'm still working on it.
>>>
>>> cgf
>>>
>>
>> it seems solved on 20120702 snapshots
>
> can you please test your crashing scenarios with the latest developer
> snapshot from today?  After some private discussion, cgf and I have a
> hunch that the underlying problem was the problem I fixed yesterday, and
> cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
> code optimization so that your problem wasn't visible anymore.
>
> I reverted cgf's changes to Makefile.in and generated the today's
> snapshot specificially to test our hypothesis.  Please give it a try.
>
>
> Thanks,
> Corinna
>

$ uname -a
CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.17s(0.262/5/3) 20120801 11:02:01
(Continue reading)

Permalink | Reply | 23 comments |
headers
Ryan Johnson | 1 Aug 2012 14:04
Picon
Picon
Favicon

Re: How to keep a dependency from [continually] appearing in setup

On 31/07/2012 6:07 PM, Ken Brown wrote:
> On 7/30/2012 1:33 AM, Wynfield Henman wrote:
>> I use the in-the-wild, 'texlive 2012' distribution, which I like to
>> tinker with and customize.
>> Due to a, what I believe is a dependency by auctex on texlive for some
>> reason, I keep getting a list of about 10 texlive related packages
>> automatically appended to what I want to install and I have to keep
>> manually [skip] them.
>>
>> I would like to know some efficient way I could make that go away and
>> just have setup ignore texlive or have it see that I have it already,
>> but that it's just not a cygwin package, but user installed.
>
> setup.exe only knows about Cygwin packages.  You might be able to edit 
> /etc/setup/installed.db to trick setup.exe into thinking that you've 
> installed Cygwin's texlive.
Of course, then it will try to upgrade the non-existent package(s), 
potentially leading to problems down the road...

Seriously, though, there are some surprising dependencies on texlive 
right now (usually via dblatex), and it's a big enough package set 
(several hundred MB download) that it's no surprise lots of people want 
to avoid its being pulled in every other time they run setup.

I don't suppose there's an easy refactoring that could help avoid this 
problem?

Ryan
(Continue reading)

Permalink | Reply | 10 comments |
headers
Corinna Vinschen | 1 Aug 2012 14:29
Favicon

Re: crash on latest cygwin snapshot

On Aug  1 12:34, marco atzeri wrote:
> On 8/1/2012 11:43 AM, Corinna Vinschen wrote:
> >Hi Marco, Hi Ken,
> >
> >On Jul  2 16:43, marco atzeri wrote:
> >>On 6/27/2012 3:46 AM, Christopher Faylor wrote:
> >>>
> >>>Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
> >>>I'm still working on it.
> >>>
> >>>cgf
> >>>
> >>
> >>it seems solved on 20120702 snapshots
> >
> >can you please test your crashing scenarios with the latest developer
> >snapshot from today?  After some private discussion, cgf and I have a
> >hunch that the underlying problem was the problem I fixed yesterday, and
> >cgf's changes to Makefile.in on 2012-07-01 made just enough changes in
> >code optimization so that your problem wasn't visible anymore.
> >
> >I reverted cgf's changes to Makefile.in and generated the today's
> >snapshot specificially to test our hypothesis.  Please give it a try.
> >
> >
> >Thanks,
> >Corinna
> >
> 
> $ uname -a
(Continue reading)

Permalink | Reply | 22 comments |

Gmane