isplays:
??
3f 3f
The behavior is not reproducible if we run bash from a CMD prompt. I know
this is pretty open-ended but are there any ideas as to what might be
causing this sort of localization issue?
Ernie Coskrey
SIOS Technology Corp.
--
Problem reports: http://cygwin.com/problems.html
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ernie Coskrey
> Sent: Wednesday, August 08, 2007 2:11 PM
> To: cygwin@cygwin.com
> Subject: RE: cygwin 1.5.20-1, spinning pdksh, 100% CPU
>
> > -Original Message-
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ernie Coskrey
> Sent: Tuesday, July 31, 2007 3:40 PM
> To: cygwin@cygwin.com
> Subject: cygwin 1.5.20-1, spinning pdksh, 100% CPU
>
>
> I've run into a proble
> -Original Message-
> From: Igor Peshansky [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 06, 2007 5:59 PM
> To: Ernie Coskrey
> Cc: cygwin@cygwin.com
> Subject: RE: cygwin 1.5.20-1, spinning pdksh, 100% CPU
>
> On Mon, 6 Aug 2007, Ernie Coskrey wrote:
>
&
ound $out
date
done
done
subtest.sh
==
for i in `seq 1 100`
do
f=`awk '{if(NR == i)print}' i=$i tstfile`
m=`/bin/echo $f | grep $1`
if [ ! -z "$m" ]
then
echo $i: $m
fi
done
-
Ernie
0x22c638: 0x00685478 0x610564f7 0x0068ad98
0x006854bc
0x22c648: 0x0001 0x0068ad60 0x0068ad60
0x
0x22c658: 0x00685ae0 0x0001 0x
0x0068b3f0
0x22c668: 0x0022c698 0x0041 0x00685530
0x006854b0
0x22c678: 0
> -Original Message-
> From: Igor Peshansky
>
> On Tue, 31 Jul 2007, Ernie Coskrey wrote:
>
> > I've run into a problem with cygwin 1.5.20-1 and pdksh 5.2.14.
We've
> > got a pdksh.exe process that is spinning, using all the CPU.
> >
> >
We've done some limited
testing with 1.5.24-2 and haven't seen this happen yet, but as I said
the it only happens rarely.
- is there anything I can look at in gdb to help identify what the issue
is?
Any suggestions would be appreciated!
-
Ernie CoskreySteelEye
em. I've redirected this mail to the
> appropriate
> list newlib AT sourceware DOT org.
>
> On Apr 27 15:14, Ernie Coskrey wrote:
> > I ran into the following problem building the latest cygwin
> snapshot:
> >
> > configure: loading cache .././config.
with
if test "`echo $ac_old_val`" != "`echo $ac_new_val`"; then
wherever it appears in any "configure" script (there are 75 configure scripts
that contain this test, BTW). There may be a more elegant way around this, but
I haven't found it. Running &q
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Christopher Faylor
> Sent: Tuesday, April 25, 2006 4:39 PM
> To: cygwin@cygwin.com
> Subject: Re: Call for testing Cygwin snapshot
>
>
> On Tue, Apr 25, 2006 at 04:33:3
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Christopher Faylor
> Sent: Tuesday, April 25, 2006 4:26 PM
> To: cygwin@cygwin.com
> Subject: Re: Call for testing Cygwin snapshot
>
>
> On Tue, Apr 25, 2006 at 03:37:4
.
>
>
I wonder if this might be related to the following:
http://cygwin.com/ml/cygwin/2006-02/msg01062.html
The fix suggested in the original message -
http://www.cygwin.com/ml/cygwin-patches/2003-q2/msg4.html - might help.
Ernie Coskrey
SteelEye Technology, Inc.
--
Unsub
>On Wed, Mar 01, 2006 at 01:01:46PM -0500, Ernie Coskrey wrote:
>>>>Here's a description of a second hang condition we were encountering, along
>>>>with a patch for it.
>>>>
>>>>
>>>>The application (pdksh in this case) does a re
>>Here's a description of a second hang condition we were encountering, along
>>with a patch for it.
>>
>>
>>The application (pdksh in this case) does a read on a pipe, which eventually
>>calls pipe.cc fhandler_pipe::read in Thread 1. This creates a new cygthread
>>with "read_pipe()" as the fun
case WAIT_TIMEOUT:
+ if(!i && __name)
+ i--;
break;
default:
if (!exiting)
> -Original Message-
> From: Ernie Coskrey
> Sent: Friday, February 10, 2006 1:31 PM
> To: Ernie Coskrey; 'cygwi
// it to the sigq) -- flush sigq to be sure
}
}
- if (sig == SIGCHLD)
- clearwait = true;
}
break;
}
> -Original Message-
> From: Ernie Coskrey
> Sent: Friday, February 10, 2006 1:31 PM
> To: E
sigsuspend and never comes
out.
If we execute "kill -CHLD ", the shell resumes its processing.
I'm going to continue to look into this - if anybody has any insight into how
SIGCHLD might be getting lost, please let me know. Thanks!
Ernie Coskrey
-----Original Message-
From:
3.1.5-2
gdb 20041228-3
gdbm 1.8.3-7
grep 2.5.1a-2
groff1.18.1-2
gzip 1.3.5-1
less 381-1
libbz2_1 1.0.3-1
libcharset1 1.9.2-2
libgdbm 1.8.0-5
libgdbm-devel 1.8.
19 matches
Mail list logo