Please test snapshots

Please test snapshots

[Christopher Faylor]

We're considering rolling a new release which fixes some of the problems
which have cropped up here in the last few weeks.

So, if you haven't already, we'd appreciate having people try out the
latest snapshot at: http://cygwin.com/snapshots/ .

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: Please test snapshots

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On 8/5/12 8:34 PM, Christopher Faylor wrote:
> We're considering rolling a new release which fixes some of the problems
> which have cropped up here in the last few weeks.
> 
> So, if you haven't already, we'd appreciate having people try out the
> latest snapshot at: http://cygwin.com/snapshots/ .
>

It's been working fine for me.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Please test snapshots

[Achim Gratz]

Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
> So, if you haven't already, we'd appreciate having people try out the
> latest snapshot at: http://cygwin.com/snapshots/ .

The August 3rd snapshot looks good so far in my testing.


Regards,
Achim.




--
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: Please test snapshots

[Filipp Gunbin]

Christopher Faylor writes:

> We're considering rolling a new release which fixes some of the problems
> which have cropped up here in the last few weeks.
>
> So, if you haven't already, we'd appreciate having people try out the
> latest snapshot at: http://cygwin.com/snapshots/ .
>
> cgf

Seems ok after a day of use (including Emacs).

Filipp

--
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: Please test snapshots

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On 8/6/2012 7:37 AM, Filipp Gunbin wrote:
> Christopher Faylor writes:
> 
>> We're considering rolling a new release which fixes some of the problems
>> which have cropped up here in the last few weeks.
>>
>> So, if you haven't already, we'd appreciate having people try out the
>> latest snapshot at: http://cygwin.com/snapshots/ .
>>
>> cgf
> 
> Seems ok after a day of use (including Emacs).

I just saw a hang building Emacs (using "make bootstrap"). An emacs.exe process
stopped and ignored SIGINT. Hitting C-z after that point didn't suspend the
emacs build, but instead caused mintty to hang. The Emacs process didn't respond
to signals at all, and I had to kill it manually from process explorer.






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Please test snapshots

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On 8/6/2012 2:07 PM, Daniel Colascione wrote:
> I just saw a hang building Emacs (using "make bootstrap")

Signal handling appears to be broken. Here's a simple testcase. Run the program
and hit control-c. It'll print "got Alarm clock", then stop accepting any
signals at all, even SIGSTOP. The same program works fine on my Debian stable box.

#define _GNU_SOURCE 1
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <pthread.h>

int
main()
{
    sigset_t waitmask;
    int sig;

    sigemptyset (&waitmask);
    sigaddset (&waitmask, SIGINT);
    sigprocmask (SIG_BLOCK, &waitmask, NULL);

    for (;;) {
        sig = sigwaitinfo (&waitmask, NULL);
        fprintf (stderr, "got %s\n", sys_siglist[sig]);
        if (sig == SIGINT) {
            break;
        }
    }

    return 0;
}


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Please test snapshots

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On 8/6/2012 5:15 PM, Daniel Colascione wrote:
> On 8/6/2012 2:07 PM, Daniel Colascione wrote:
>> I just saw a hang building Emacs (using "make bootstrap")
> 
> Signal handling appears to be broken. Here's a simple testcase. Run the program
> and hit control-c. It'll print "got Alarm clock", then stop accepting any
> signals at all, even SIGSTOP. The same program works fine on my Debian stable box.

By the way: this regression was introduced between the 2012-07-15 snapshot and
the 2012-07-21 snapshot.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Please test snapshots

[Achim Gratz]

I'm at the August 7th snapshot now and Emacs just died on me with this message:

> Connection lost to X server `:0.0'
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.

The X server is still running as well as a number of other X applications.


Regards,
Achim.


--
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: Please test snapshots

[Christopher Faylor]

On Mon, Aug 06, 2012 at 05:15:10PM -0700, Daniel Colascione wrote:
>On 8/6/2012 2:07 PM, Daniel Colascione wrote:
>> I just saw a hang building Emacs (using "make bootstrap")
>
>Signal handling appears to be broken. Here's a simple testcase. Run the program
>and hit control-c. It'll print "got Alarm clock", then stop accepting any
>signals at all, even SIGSTOP. The same program works fine on my Debian stable box.

I forgot to send out a notice about this.

This particular issue should be fixed in the latest snapshot.

You mention generic "signal handling" rather than "sigwaitinfo" so I don't
know if there are other issues.  It doesn't seem like much would work if
signal handling was completely broken, though.

Thanks for the test case.

cgf

>#define _GNU_SOURCE 1
>#include <unistd.h>
>#include <stdio.h>
>#include <stdlib.h>
>#include <signal.h>
>#include <pthread.h>
>
>int
>main()
>{
>    sigset_t waitmask;
>    int sig;
>
>    sigemptyset (&waitmask);
>    sigaddset (&waitmask, SIGINT);
>    sigprocmask (SIG_BLOCK, &waitmask, NULL);
>
>    for (;;) {
>        sig = sigwaitinfo (&waitmask, NULL);
>        fprintf (stderr, "got %s\n", sys_siglist[sig]);
>        if (sig == SIGINT) {
>            break;
>        }
>    }
>
>    return 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: Please test snapshots

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On 8/8/2012 2:59 PM, Christopher Faylor wrote:
> On Mon, Aug 06, 2012 at 05:15:10PM -0700, Daniel Colascione wrote:
>> On 8/6/2012 2:07 PM, Daniel Colascione wrote:
>>> I just saw a hang building Emacs (using "make bootstrap")
>>
>> Signal handling appears to be broken. Here's a simple testcase. Run the program
>> and hit control-c. It'll print "got Alarm clock", then stop accepting any
>> signals at all, even SIGSTOP. The same program works fine on my Debian stable box.
> 
> I forgot to send out a notice about this.
> 
> This particular issue should be fixed in the latest snapshot.

The latest snapshot seems to fix the issue.

> 
> You mention generic "signal handling" rather than "sigwaitinfo" so I don't
> know if there are other issues.  It doesn't seem like much would work if
> signal handling was completely broken, though.

Apologies --- I should have been more specific. No, I haven't noticed any other
signal breakage aside from the sigwaitinfo problem and the Emacs build hang. I
can't reproduce either with the new snapshot.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Please test snapshots

[Achim Gratz]

Achim Gratz <Stromeko <at> NexGo.DE> writes:
> The X server is still running as well as a number of other X applications.

Something's wrong here with the new snapshot and signal handling / job control
in conjunction with X and the newest snapshot... this morning the shell
proclaimed (I left it running overnight) after the first command:

[1]  - Done                          gitk --all

However, I have only started one gitk since starting X and it is still running.


Regards,
Achim.


--
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: Please test snapshots

[Achim Gratz]

Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
> You mention generic "signal handling" rather than "sigwaitinfo" so I don't
> know if there are other issues.  It doesn't seem like much would work if
> signal handling was completely broken, though.

With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS
entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to
wait until it finally times out.

#  ping deadbeef
PING deadbeef (xx.xx.xx.xx): 56 data bytes

----deadbeef PING Statistics----
2 packets transmitted, 0 packets received, 100.0% packet loss



Regards,
Achim.



--
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: Please test snapshots

[Christopher Faylor]

On Thu, Aug 09, 2012 at 09:21:47AM +0000, Achim Gratz wrote:
>Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
>> You mention generic "signal handling" rather than "sigwaitinfo" so I don't
>> know if there are other issues.  It doesn't seem like much would work if
>> signal handling was completely broken, though.
>
>With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS
>entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to
>wait until it finally times out.
>
>#  ping deadbeef
>PING deadbeef (xx.xx.xx.xx): 56 data bytes
>
>----deadbeef PING Statistics----
>2 packets transmitted, 0 packets received, 100.0% packet loss

Ping doesn't time out after only two packets.  It sure looks like CTRL-C worked
above.

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: Please test snapshots

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On 8/9/12 2:21 AM, Achim Gratz wrote:
> Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
>> You mention generic "signal handling" rather than "sigwaitinfo" so I don't
>> know if there are other issues.  It doesn't seem like much would work if
>> signal handling was completely broken, though.
> 
> With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS
> entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to
> wait until it finally times out.

It works for me in bash. I don't have tcsh installed, but I don't see
why SIGINT would work differently there.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Please test snapshots

[Achim Gratz]

Christopher Faylor writes:
>>----deadbeef PING Statistics----
>>2 packets transmitted, 0 packets received, 100.0% packet loss
>
> Ping doesn't time out after only two packets.  It sure looks like CTRL-C worked
> above.

Maybe ping got indeed interrupted, but I didn't get the shell prompt
back for another two or three minutes.  Also, when the shell receives
the Ctrl-C (as it would when ping was already gone) it would normally
produce another prompt for each Ctrl-C, but this did not happen even
though I tried multiple times to interrupt ping.  After a while I got a
single prompt back.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves


--
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: Please test snapshots

[Achim Gratz]

Daniel Colascione <dancol <at> dancol.org> writes:
> It works for me in bash. I don't have tcsh installed, but I don't see
> why SIGINT would work differently there.

Yes, it works in bash for me, too.  Tcsh does something that apparently breaks
with the new snapshot, but since I don't get any error messages, it's hard to
tell what that might be.

I tried it again in tcsh, and the SIGINT clearly did not get delivered to ping
(the process was still running) and I had to kill it from another shell.  Once I
did that, the prompt in tcsh came back.  I can kill other processes in tcsh, but
sometimes they are not properly terminated, like here:

...  pty0    85441 08:14:58 /usr/bin/git <defunct>


Regards,
Achim.


--
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: Please test snapshots

[Christopher Faylor]

On Fri, Aug 10, 2012 at 06:31:25AM +0000, Achim Gratz wrote:
>Daniel Colascione writes:
>>It works for me in bash.  I don't have tcsh installed, but I don't see
>>why SIGINT would work differently there.
>
>Yes, it works in bash for me, too.  Tcsh does something that apparently
>breaks with the new snapshot, but since I don't get any error messages,
>it's hard to tell what that might be.

You're not really giving us much to go on.  I've tried ping (both
Windows and Cygwin version) under tcsh and both work fine.  And, the
small snippet that you cut/paste in your original bug report clearly
showed that ping was responding to CTRL-C.

>I tried it again in tcsh, and the SIGINT clearly did not get delivered
>to ping (the process was still running) and I had to kill it from
>another shell.  Once I did that, the prompt in tcsh came back.  I can
>kill other processes in tcsh, but sometimes they are not properly
>terminated, like here:
>
>...  pty0    85441 08:14:58 /usr/bin/git <defunct>

A <defunct> process doesn't mean that something is not properly
terminated.  Is this also a tcsh shell running git?

--
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: Please test snapshots

[Achim Gratz]

Christopher Faylor writes:
> You're not really giving us much to go on.

I don't have anything else, these are the only two (small) issues I've
seen after installation of the latest snapshot.

> A <defunct> process doesn't mean that something is not properly
> terminated.  Is this also a tcsh shell running git?

Actually it was make started in tcsh, which then forked git (I think it
goes through bash for this, but I'm not sure).  I've killed make while
git was running.  Anyway, the computer will be freshly booted on Monday,
I'll see if that is still reproduceable then.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
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: Please test snapshots

[Christopher Faylor]

On Fri, Aug 10, 2012 at 07:57:24PM +0200, Achim Gratz wrote:
>Christopher Faylor writes:
>> You're not really giving us much to go on.
>
>I don't have anything else, these are the only two (small) issues I've
>seen after installation of the latest snapshot.
>
>> A <defunct> process doesn't mean that something is not properly
>> terminated.  Is this also a tcsh shell running git?
>
>Actually it was make started in tcsh, which then forked git (I think it
>goes through bash for this, but I'm not sure).  I've killed make while
>git was running.  Anyway, the computer will be freshly booted on Monday,
>I'll see if that is still reproduceable then.

...and those are the kind of details which allows us to at least make
educated guesses about problems.  Showing a "defunct" ps listing, not so
much...

It's probably too late to ask but is the make process still around?

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: Please test snapshots

[Achim Gratz]

Christopher Faylor writes:
> ...and those are the kind of details which allows us to at least make
> educated guesses about problems.  Showing a "defunct" ps listing, not so
> much...

You know this, but a defunct listing means that a process terminated,
but wasn't reaped by it's parent process.  Unless that parent process
crashed hard I can't remember seeing that happen in Cygwin, which is why
I thought it noteworthy.

> It's probably too late to ask but is the make process still around?

I killed make because I forgot to add a variable definition on the
command line.  Only later did I find it left that zombie git process
that should have been terminated with it (I know it was associated with
that particular make invocation by its start time).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables


--
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: Please test snapshots

[Christopher Faylor]

On Fri, Aug 10, 2012 at 08:33:36PM +0200, Achim Gratz wrote:
>Christopher Faylor writes:
>> ...and those are the kind of details which allows us to at least make
>> educated guesses about problems.  Showing a "defunct" ps listing, not so
>> much...
>
>You know this, but a defunct listing means that a process terminated,
>but wasn't reaped by it's parent process.  Unless that parent process
>crashed hard I can't remember seeing that happen in Cygwin, which is why
>I thought it noteworthy.

...and that's why I asked:

>> It's probably too late to ask but is the make process still around?
>
>I killed make because I forgot to add a variable definition on the
>command line.  Only later did I find it left that zombie git process
>that should have been terminated with it (I know it was associated with
>that particular make invocation by its start time).

So you don't know if the make process was actually still around.  Got it.

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: Please test snapshots

[Achim Gratz]

Christopher Faylor writes:
>>I killed make because I forgot to add a variable definition on the
>>command line.  Only later did I find it left that zombie git process
>>that should have been terminated with it (I know it was associated with
>>that particular make invocation by its start time).
>
> So you don't know if the make process was actually still around.  Got it.

For all I know it was gone.  The shell had the control back and no
process was showing in ps.  I didn't think to look in process monitor,
sorry.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves


--
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: Please test snapshots

[Christopher Faylor]

On Fri, Aug 10, 2012 at 10:23:41PM +0200, Achim Gratz wrote:
>Christopher Faylor writes:
>>>I killed make because I forgot to add a variable definition on the
>>>command line.  Only later did I find it left that zombie git process
>>>that should have been terminated with it (I know it was associated with
>>>that particular make invocation by its start time).
>>
>> So you don't know if the make process was actually still around.  Got it.
>
>For all I know it was gone.  The shell had the control back and no
>process was showing in ps.  I didn't think to look in process monitor,
>sorry.

Yep, I wouldn't have expected you to check.  I wouldn't have either.

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: Please test snapshots

[Adam Dinwoodie]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

Christopher Faylor wrote:
>On Fri, Aug 10, 2012 at 06:31:25AM +0000, Achim Gratz wrote:
>>Daniel Colascione writes:
>>>It works for me in bash.  I don't have tcsh installed, but I don't see why
>>>SIGINT would work differently there.
>>
>>Yes, it works in bash for me, too.  Tcsh does something that apparently
>>breaks with the new snapshot, but since I don't get any error messages, it's
>>hard to tell what that might be.
>
>You're not really giving us much to go on.  I've tried ping (both Windows and
>Cygwin version) under tcsh and both work fine.  And, the small snippet that
>you cut/paste in your original bug report clearly showed that ping was
>responding to CTRL-C.

I'm still using this snapshot (I've had no reason to stop until now), and have
hit this issue two out of the last five times running Cygwin ping.  The ping                                                                                 process is still visible in Process Explorer after hitting ^C. There's no
obvious difference between when ^C terminates the process and when it doesn't.

When I've hit this, I've been running bash inside screen inside MinTTY, which
was started running with administrator permissions.

I've attached cygcheck output, and am happy to keep experimenting if it'll be
useful. I've not swapped to the latest snapshot yet, in case more repros with
this snapshot would be useful, but I'm equally happy to change to the latest
snapshot and/or the original cygwin1.dll to have a play around.

Example below (the last command is just sitting there, the previous one quit
immediately after ^C). Note it's still sitting there even though running `ping
winston1` in a different screen at this point shows that system is now
responding.

    ~
    $ ping winston1
    PING winston1.datcon.co.uk (10.236.0.21): 56 data bytes

    ----winston1.datcon.co.uk PING Statistics----
    3 packets transmitted, 0 packets received, 100.0% packet loss

    ~
    $ ping winston1
    PING winston1.datcon.co.uk (10.236.0.21): 56 data bytes

Killing ping in Process Explorer unsurprisingly returns the bash prompt
immediately.

[-- Attachment #2: cygcheck.out --]
[-- Type: application/octet-stream, Size: 52916 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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: Please test snapshots

[jojelino]

Hi, I think i found a glitch in gmon.c

the testcase is following. and you can see it doesn't work.

int main()
{
         char *proffile;
         {
           char gmon_out[] = "gmon.out";
           proffile = gmon_out;
         }
         printf("%s\n",proffile);
}

-------
$ ./a
a(â–’"
Actually the above can't be expected to work. the above is exactly same 
case with gmon.c:206
-- Regards.


--
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: Please test snapshots

[Corinna Vinschen]

On Aug 15 02:59, jojelino wrote:
> Hi, I think i found a glitch in gmon.c
> 
> the testcase is following. and you can see it doesn't work.
> 
> int main()
> {
>         char *proffile;
>         {
>           char gmon_out[] = "gmon.out";
>           proffile = gmon_out;
>         }
>         printf("%s\n",proffile);
> }
> 
> -------
> $ ./a
> a(â–’"
> Actually the above can't be expected to work. the above is exactly
> same case with gmon.c:206

Fixed in CVS.


Thanks,
Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please test snapshots

[Christopher Faylor]

On Tue, Aug 14, 2012 at 09:39:14PM +0200, Corinna Vinschen wrote:
>On Aug 15 02:59, jojelino wrote:
>> Hi, I think i found a glitch in gmon.c
>> 
>> the testcase is following. and you can see it doesn't work.
>> 
>> int main()
>> {
>>         char *proffile;
>>         {
>>           char gmon_out[] = "gmon.out";
>>           proffile = gmon_out;
>>         }
>>         printf("%s\n",proffile);
>> }
>> 
>> -------
>> $ ./a
>> a(???"
>> Actually the above can't be expected to work. the above is exactly
>> same case with gmon.c:206
>
>Fixed in CVS.

Btw, since this file hadn't changed in two years, it's unlikely
that this was a regression and probably deserved a new subject.
This really isn't an issue with the latest snapshot.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please test snapshots

[Christopher Faylor]

On Tue, Aug 14, 2012 at 12:48:03PM +0000, Adam Dinwoodie wrote:
>Christopher Faylor wrote:
>>On Fri, Aug 10, 2012 at 06:31:25AM +0000, Achim Gratz wrote:
>>>Daniel Colascione writes:
>>>>It works for me in bash.  I don't have tcsh installed, but I don't see why
>>>>SIGINT would work differently there.
>>>
>>>Yes, it works in bash for me, too.  Tcsh does something that apparently
>>>breaks with the new snapshot, but since I don't get any error messages, it's
>>>hard to tell what that might be.
>>
>>You're not really giving us much to go on.  I've tried ping (both Windows and
>>Cygwin version) under tcsh and both work fine.  And, the small snippet that
>>you cut/paste in your original bug report clearly showed that ping was
>>responding to CTRL-C.
>
>I'm still using this snapshot (I've had no reason to stop until now),
>and have hit this issue two out of the last five times running Cygwin
>ping.  The ping process is still visible in Process Explorer after
>hitting ^C.  There's no obvious difference between when ^C terminates
>the process and when it doesn't.

I managed to duplicate this once a couple of days ago in a mintty/tcsh
process but I had a very hard time consistently hitting it.  So I wrote
a test case which ran ping repeatedly in a loop under mintty while another
process killed it.  Eventually, I could duplicate the problem in a few
minutes.  There were two problems, one illustrated by the "sigwaitinfo"
mentioned in another thread and another caused by a race.

After making some changes to signal handling, I ran the test case for an
afternoon without issue.

The current snapshot has these changes.

I'd appreciate feedback on whether or not this fixes this problem.

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: Please test snapshots

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

On 8/16/2012 2:37 PM, Christopher Faylor wrote:
> On Tue, Aug 14, 2012 at 12:48:03PM +0000, Adam Dinwoodie wrote:
>> Christopher Faylor wrote:
>>> On Fri, Aug 10, 2012 at 06:31:25AM +0000, Achim Gratz wrote:
>>>> Daniel Colascione writes:
>>>>> It works for me in bash.  I don't have tcsh installed, but I don't see why
>>>>> SIGINT would work differently there.
>>>>
>>>> Yes, it works in bash for me, too.  Tcsh does something that apparently
>>>> breaks with the new snapshot, but since I don't get any error messages, it's
>>>> hard to tell what that might be.
>>>
>>> You're not really giving us much to go on.  I've tried ping (both Windows and
>>> Cygwin version) under tcsh and both work fine.  And, the small snippet that
>>> you cut/paste in your original bug report clearly showed that ping was
>>> responding to CTRL-C.
>>
>> I'm still using this snapshot (I've had no reason to stop until now),
>> and have hit this issue two out of the last five times running Cygwin
>> ping.  The ping process is still visible in Process Explorer after
>> hitting ^C.  There's no obvious difference between when ^C terminates
>> the process and when it doesn't.
>
> I managed to duplicate this once a couple of days ago in a mintty/tcsh
> process but I had a very hard time consistently hitting it.  So I wrote
> a test case which ran ping repeatedly in a loop under mintty while another
> process killed it.  Eventually, I could duplicate the problem in a few
> minutes.  There were two problems, one illustrated by the "sigwaitinfo"
> mentioned in another thread and another caused by a race.
>
> After making some changes to signal handling, I ran the test case for an
> afternoon without issue.
>
> The current snapshot has these changes.

With the current snapshot (20120816 17:19:27), I have problems with 
emacs-X11.exe.  When I start it under X (by typing 'emacs&' in an xterm 
window), its CPU usage goes up to 50% and its window never displays. 
The attached file gives the result of attaching gdb and giving the 
command 'thread apply all bt full'.

I reproduced this running emacs under mintty, but it took longer for it 
to happen.

The problem doesn't occur with the 20120815 snapshot.

Ken

[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 17941 bytes --]


Thread 10 (Thread 5884.0x17c4):
#0  0x76f6000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76fef896 in ntdll!RtlQueryTimeZoneInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x7375eb68 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 9 (Thread 5884.0x9a0):
#0  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x76fa3352 in ntdll!RtlCreateTagHeap () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

#3  0x000001b8 in ?? ()
warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

#4  0x044dac8c in ?? ()
No symbol table info available.
#5  0x6100538d in _cygtls::call2 (this=<optimized out>, func=0x2, 
    arg=0x18c9908, buf=0x6100551b)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#6  0x044dff88 in ?? ()
No symbol table info available.
#7  0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#8  0x018c9908 in ?? ()
No symbol table info available.
#9  0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#10 0x018c9908 in ?? ()
No symbol table info available.
#11 0x76f89ec5 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#12 0x6107f110 in cygwin_inet_network () from /usr/bin/cygwin1.dll
No symbol table info available.
#13 0x00000000 in ?? ()
No symbol table info available.

Thread 8 (Thread 5884.0xc58):
#0  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x76fa3352 in ntdll!RtlCreateTagHeap () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

#3  0x000001c4 in ?? ()
warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

#4  0x042dac8c in ?? ()
No symbol table info available.
#5  0x6100538d in _cygtls::call2 (this=<optimized out>, func=warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

0x2, 
    arg=0x18c9908, buf=0x6100551b)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#6  0x042dff88 in ?? ()
No symbol table info available.
#7  0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#8  0x018c9908 in ?? ()
No symbol table info available.
#9  0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#10 0x018c9908 in ?? ()
No symbol table info available.
#11 0x76f89ec5 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#12 0x6107f110 in cygwin_inet_network () from /usr/bin/cygwin1.dll
No symbol table info available.
#13 0x00000000 in ?? ()
No symbol table info available.

Thread 7 (Thread 5884.0x15b0):
#0  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x76fa3352 in ntdll!RtlCreateTagHeap () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.)

#3  0x000001e4 in ?? ()
warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0x1e3 in read in psymtab, but not in symtab.)

#4  0x040dac8c in ?? ()
No symbol table info available.
#5  0x6100538d in _cygtls::call2 (this=<optimized out>, func=warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

0x2, 
    arg=0x18cae60, buf=0x6100551b)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#6  0x040dff88 in ?? ()
No symbol table info available.
#7  0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#8  0x018cae60 in ?? ()
No symbol table info available.
#9  0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#10 0x018cae60 in ?? ()
No symbol table info available.
#11 0x76f89ec5 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#12 0x6107f110 in cygwin_inet_network () from /usr/bin/cygwin1.dll
No symbol table info available.
#13 0x00000000 in ?? ()
No symbol table info available.

Thread 6 (Thread 5884.0x130c):
#0  0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x75590a91 in WaitForSingleObjectEx ()
   from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.)

#3  0x00000320 in ?? ()
warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0x31f in read in psymtab, but not in symtab.)

#4  0x00000000 in ?? ()
No symbol table info available.

Thread 5 (Thread 5884.0x294):
#0  0x76f6f939 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f6f939 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x71ed635c in ?? () from /c/windows/System32/mswsock.dll
No symbol table info available.
#3  0x6100538d in _cygtls::call2 (this=<optimized out>, func=0x71ed62ee, 
    arg=0x18d20a0, buf=0x6100551b)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#4  0x03cdff88 in ?? ()
No symbol table info available.
#5  0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#6  0x018d20a0 in ?? ()
No symbol table info available.
#7  0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#8  0x018d20a0 in ?? ()
No symbol table info available.
#9  0x76f89ec5 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#10 0x6107f110 in cygwin_inet_network () from /usr/bin/cygwin1.dll
No symbol table info available.
#11 0x00000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 5884.0x96c):
#0  0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f6f8b1 in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x75590a91 in WaitForSingleObjectEx ()
   from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.)

#3  0x000002bc in ?? ()
warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0x2bb in read in psymtab, but not in symtab.)

#4  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 5884.0xa84):
#0  0x76f7013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f7013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x76fa2f51 in ntdll!RtlWeaklyEnumerateEntryHashTable ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

#3  0x00000003 in ?? ()
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

No symbol table info available.
#4  0x018cac28 in ?? ()
No symbol table info available.
#5  0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 5884.0xc28):
#0  0x76f6f99e in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f6f99e in ntdll!RtlUpdateClonedSRWLock ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x75593a5e in SetThreadPriority () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x610873cd in yield ()
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/miscfuncs.cc:252
        prio = 2
#4  0x610d6714 in _cygtls::lock() () from /usr/bin/cygwin1.dll
No symbol table info available.
#5  0x61030124 in setup_handler (sig=14, handler=0x592ca0, siga=..., 
    tls=0x28ce64)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/exceptions.cc:836
        res = <optimized out>
        hth = 0x80013000
        i = <optimized out>
        cx = {ContextFlags = 0, Dr0 = 0, Dr1 = 0, Dr2 = 0, Dr3 = 0, Dr6 = 0, 
          Dr7 = 0, FloatSave = {ControlWord = 0, StatusWord = 0, TagWord = 0, 
            ErrorOffset = 0, ErrorSelector = 0, DataOffset = 0, 
            DataSelector = 0, RegisterArea = '\000' <repeats 79 times>, 
            Cr0NpxState = 0}, SegGs = 0, SegFs = 0, SegEs = 51489176, 
          SegDs = 1627912124, Edi = 0, Esi = 2031619, Ebx = 51489116, Edx = 1, 
          Ecx = 0, Eax = 0, Ebp = 0, Eip = 0, SegCs = 0, EFlags = 0, Esp = 0, 
          SegSs = 0, 
          ExtendedRegisters = '\000' <repeats 12 times>, "\030", '\000' <repeats 31 times>"\340, ", '\000' <repeats 20 times>"\244, \030a\000\000\000\000È«\021\003^\370\aaL\310\031a", '\000' <repeats 152 times>"\320, \b'a\016\000\000\000\320\b'a\320\b'a\261=\000at\330(\000\016", '\000' <repeats 31 times>, "t\252\021\003\320\b'al\243\030a\000\000\000\000\016\000\000\000d\316(\000\001\000\000\000P\252\021\003\302<\000a+\000S\000+\000+\000T\377\021\003", '\000' <repeats 120 times>"\345, \370\366vH\323Xu\240", '\000' <repeats 15 times>, "`\253\021\003\004\254\021\003\244", '\000' <repeats 18 times>}
        interrupted = false
        __PRETTY_FUNCTION__ = "int setup_handler(int, void*, sigaction&, _cygtls*)"
#6  0x61030d77 in sigpacket::process (this=0x311ac04)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/exceptions.cc:1239
        continue_now = <optimized out>
        __PRETTY_FUNCTION__ = "int sigpacket::process()"
        thissig = @0x61272bd0: {{sa_handler = 0x592ca0 <alarm_signal_handler>, 
            sa_sigaction = 0x592ca0 <alarm_signal_handler>}, sa_mask = 8192, 
          sa_flags = 0}
        dummy = {{sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
          sa_flags = 1342177280}
        rc = 1
        handler = <optimized out>
#7  0x610dd1c7 in wait_sig ()
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/sigproc.cc:1439
        sigres = <optimized out>
        sig = 14
        bit = <optimized out>
        nb = 164
        dummy_mask = 0
        clearwait = false
        __PRETTY_FUNCTION__ = "void wait_sig(void*)"
        pack = {si = {si_signo = 14, si_code = 4, si_pid = 4764, 
            si_uid = 1001, si_errno = 0, {__pad = {1629095104, 
                0 <repeats 31 times>}, _si_commune = {_si_code = 1629095104, 
                _si_read_handle = 0x0, _si_write_handle = 0x0, 
                _si_process_handle = 0x0, {_si_fd = 0, 
                  _si_pipe_fhandler = 0x0, _si_str = 0x0}}, {{{{
                      si_tid = 1629095104, si_overrun = 0}, si_sigval = {
                      sival_int = 1629095104, sival_ptr = 0x611a04c0}, 
                    si_value = {sival_int = 1629095104, 
                      sival_ptr = 0x611a04c0}}}}, {si_status = 1629095104, 
                si_utime = 0, si_stime = 0}, si_addr = 0x611a04c0}}, 
          pid = 4764, tls = 0x28ce64, mask = 0x28d874, {wakeup = 0x0, 
            thread_handle = 0x0, next = 0x0}}
#8  0x61003e65 in cygthread::callfunc (this=0x6118a400, 
    issimplestub=<optimized out>)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygthread.cc:51
        pass_arg = 0x6118a400
#9  0x61004401 in cygthread::stub (arg=0x6118a400)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygthread.cc:99
        notify = <optimized out>
        info = 0x6118a400
        __PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#10 0x6100538d in _cygtls::call2 (this=<optimized out>, 
    func=0x610043a0 <cygthread::stub(void*)>, arg=0x6118a400, buf=0x6100551b)
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#11 0x0311ff88 in ?? ()
No symbol table info available.
#12 0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#13 0x6118a400 in cygthread::exiting () from /usr/bin/cygwin1.dll
No symbol table info available.
#14 0x0311ffd4 in ?? ()
No symbol table info available.
#15 0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#16 0x6118a400 in cygthread::exiting () from /usr/bin/cygwin1.dll
No symbol table info available.
#17 0x7409eb34 in ?? ()
No symbol table info available.
#18 0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 5884.0xcfc):
#0  0x7559317a in SleepEx () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#1  0x1d044b61 in ?? ()
No symbol table info available.
#2  0x00005d00 in ?? ()
No symbol table info available.
#3  0x8024d110 in ?? ()
No symbol table info available.
#4  0x610873a2 in yield ()
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/miscfuncs.cc:250
        i = 0
        prio = 0
#5  0x610d65fc in _sigfe () from /usr/bin/cygwin1.dll
No symbol table info available.
#6  0x61083180 in reallocf ()
    at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/malloc_wrapper.cc:96
No symbol table info available.
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#7  0x00000001 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x20 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.)

#8  0x00000020 in ?? ()
warning: (Internal error: pc 0x1f in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x10 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.)

#9  0x00000010 in ?? ()
warning: (Internal error: pc 0xf in read in psymtab, but not in symtab.)

No symbol table info available.
#10 0x00005d00 in ?? ()
No symbol table info available.
#11 0x00000000 in ?? ()
No symbol table info available.
A debugging session is active.

	Inferior 1 [process 5884] will be detached.

Quit anyway? (y or n) Detaching from program: /usr/bin/emacs-X11.exe, Pid 5884


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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: Please test snapshots

[Christopher Faylor]

On Thu, Aug 16, 2012 at 03:11:34PM -0400, Ken Brown wrote:
>With the current snapshot (20120816 17:19:27), I have problems with 
>emacs-X11.exe.  When I start it under X (by typing 'emacs&' in an xterm 
>window), its CPU usage goes up to 50% and its window never displays. 
>The attached file gives the result of attaching gdb and giving the 
>command 'thread apply all bt full'.
>
>I reproduced this running emacs under mintty, but it took longer for it 
>to happen.
>
>The problem doesn't occur with the 20120815 snapshot.

It's funny how the simple explanation of a problem can trigger a
"Oh #(*&$.  I know what I did."

In this case, I made my standard "reverse the sense of a ? operator"
mistake.

I'm generating a new snapshot which seems to fix the problem.

I meant to run my normal raft of exhaustive tests:

- run bash in console
- run mintty
- run X
- start emacs

but I missed the last two.  Duh.

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: Please test snapshots

[Ken Brown]

On 8/16/2012 3:26 PM, Christopher Faylor wrote:
> On Thu, Aug 16, 2012 at 03:11:34PM -0400, Ken Brown wrote:
>> With the current snapshot (20120816 17:19:27), I have problems with
>> emacs-X11.exe.  When I start it under X (by typing 'emacs&' in an xterm
>> window), its CPU usage goes up to 50% and its window never displays.
>> The attached file gives the result of attaching gdb and giving the
>> command 'thread apply all bt full'.
>>
>> I reproduced this running emacs under mintty, but it took longer for it
>> to happen.
>>
>> The problem doesn't occur with the 20120815 snapshot.
>
> It's funny how the simple explanation of a problem can trigger a
> "Oh #(*&$.  I know what I did."
>
> In this case, I made my standard "reverse the sense of a ? operator"
> mistake.
>
> I'm generating a new snapshot which seems to fix the problem.

Confirmed.  Thanks.

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: Please test snapshots

[Adam Dinwoodie]

Christopher Faylor wrote:
> On Tue, Aug 14, 2012 at 12:48:03PM +0000, Adam Dinwoodie wrote:
>> I'm still using this snapshot (I've had no reason to stop until now), and
>> have hit this issue two out of the last five times running Cygwin ping.  The
>> ping process is still visible in Process Explorer after hitting ^C.  There's
>> no obvious difference between when ^C terminates the process and when it
>> doesn't.
>
> I managed to duplicate this once a couple of days ago in a mintty/tcsh
> process but I had a very hard time consistently hitting it.  So I wrote a
> test case which ran ping repeatedly in a loop under mintty while another
> process killed it.  Eventually, I could duplicate the problem in a few
> minutes.  There were two problems, one illustrated by the "sigwaitinfo"
> mentioned in another thread and another caused by a race.

I'm seeing this much more regularly than that; it's pretty readily
reproducible for me.

I've found leaving a couple of seconds between starting ping and trying to kill
it, and leaving a couple of seconds between invocations, both help. I've not
tested that thoroughly, though; it might be something to play with for trying
to build a test case, but certainly not something I'd rely on as a symptom for
debugging without further verification.

> After making some changes to signal handling, I ran the test case for an
> afternoon without issue.
>
> The current snapshot has these changes.
>
> I'd appreciate feedback on whether or not this fixes this problem.

I'm still seeing exactly the same issue having taken the 20120816 snapshot. If
anything, I've been hitting the problem more.

--
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: Please test snapshots

[Achim Gratz]

Achim Gratz <Stromeko <at> NexGo.DE> writes:
> With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS
> entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to
> wait until it finally times out.
> 
> #  ping deadbeef
> PING deadbeef (xx.xx.xx.xx): 56 data bytes

This is still happening with the 2012-08-16 19:31:57 UTC snapshot.  The dead
machine cannot be in the same local network or the fail is not happening.  After
Ctrl-C in the tcsh for ping, nothing happens and ps still shows ping as a
running process.  Killing that process ID from another shell kills the shell
ping was started from along with the mintty it was running in.  Trying to attach
to the ping process with gdb recognizes it as "tcsh" rather than ping, which
might explain why killing "ping" actually kills "tcsh".


Regards,
Achim.


--
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: Please test snapshots

[Achim Gratz]

Achim Gratz <Stromeko <at> NexGo.DE> writes:
> This is still happening with the 2012-08-16 19:31:57 UTC snapshot.

And now I see that all that killing business has left some "tcsh" processes in
task manager with a size of 60k (much too small for both tcsh and ping) that ps
in Cygwin doesn't show.  I could terminate these from the task manger.


Regards,
Achim.




--
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: Please test snapshots

[Christopher Faylor]

On Fri, Aug 17, 2012 at 09:07:30AM +0000, Adam Dinwoodie wrote:
>Christopher Faylor wrote:
>> On Tue, Aug 14, 2012 at 12:48:03PM +0000, Adam Dinwoodie wrote:
>>> I'm still using this snapshot (I've had no reason to stop until now), and
>>> have hit this issue two out of the last five times running Cygwin ping.  The
>>> ping process is still visible in Process Explorer after hitting ^C.  There's
>>> no obvious difference between when ^C terminates the process and when it
>>> doesn't.
>>
>> I managed to duplicate this once a couple of days ago in a mintty/tcsh
>> process but I had a very hard time consistently hitting it.  So I wrote a
>> test case which ran ping repeatedly in a loop under mintty while another
>> process killed it.  Eventually, I could duplicate the problem in a few
>> minutes.  There were two problems, one illustrated by the "sigwaitinfo"
>> mentioned in another thread and another caused by a race.
>
>I'm seeing this much more regularly than that; it's pretty readily
>reproducible for me.

Yes, I got the fact that other people were able to duplicate the problem
easily.

>I've found leaving a couple of seconds between starting ping and trying
>to kill it, and leaving a couple of seconds between invocations, both
>help.  I've not tested that thoroughly, though; it might be something
>to play with for trying to build a test case, but certainly not
>something I'd rely on as a symptom for debugging without further
>verification.
>
>> After making some changes to signal handling, I ran the test case for an
>> afternoon without issue.
>>
>> The current snapshot has these changes.
>>
>> I'd appreciate feedback on whether or not this fixes this problem.
>
>I'm still seeing exactly the same issue having taken the 20120816 snapshot. If
>anything, I've been hitting the problem more.

I should have asked this before:  I don't think anyone has made it clear if they
are running the cygwin ping or the Windows one.  I've been assuming Cygwin.  Is
that correct?

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: Please test snapshots

[Adam Dinwoodie]

Christopher Faylor wrote
> On Fri, Aug 17, 2012 at 09:07:30AM +0000, Adam Dinwoodie wrote:
>> I'm still seeing exactly the same issue having taken the 20120816 snapshot.
>> If anything, I've been hitting the problem more.
>
> I should have asked this before:  I don't think anyone has made it clear if
> they are running the cygwin ping or the Windows one.  I've been assuming
> Cygwin.  Is that correct?

Yes, Cygwin ping. For paranoia's sake, you can check the output I pasted in my
previous email, which should look like Cygwin ping rather than Windows ping
output. Also:

    $ cygcheck -c ping
    Cygwin Package Information
    Package              Version        Status
    ping                 1.0-1          OK

    $ cygcheck -f $(which ping)
    ping-1.0-1

    $ which ping
    /usr/bin/ping

    $ cygcheck ping
    Found: C:\cygwin\bin\ping.exe
    Found: C:\Windows\system32\ping.exe
    C:\cygwin\bin\ping.exe
      C:\cygwin\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
          C:\Windows\system32\ntdll.dll
            ...blah blah blah...

--
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: Please test snapshots

[Christopher Faylor]

On Fri, Aug 17, 2012 at 03:50:05PM +0000, Adam Dinwoodie wrote:
>Christopher Faylor wrote
>> On Fri, Aug 17, 2012 at 09:07:30AM +0000, Adam Dinwoodie wrote:
>>> I'm still seeing exactly the same issue having taken the 20120816 snapshot.
>>> If anything, I've been hitting the problem more.
>>
>> I should have asked this before:  I don't think anyone has made it clear if
>> they are running the cygwin ping or the Windows one.  I've been assuming
>> Cygwin.  Is that correct?
>
>Yes, Cygwin ping. For paranoia's sake, you can check the output I pasted in my
>previous email, which should look like Cygwin ping rather than Windows ping
>output.

That's why I was assuming Cygwin ping.

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: Please test snapshots

[Achim Gratz]

Christopher Faylor writes:
> I should have asked this before: I don't think anyone has made it
> clear if they are running the cygwin ping or the Windows one.  I've
> been assuming Cygwin.  Is that correct?

Cygwin's ping.  I've removed any remnants of Windows' PATH from all
Cygwin startup scripts...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds


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