On 6/12/2013 11:44 AM, Christopher Faylor wrote:
> On Wed, Jun 12, 2013 at 11:06:15AM -0700, Daniel Colascione wrote:
>> On 6/12/2013 2:46 AM, Corinna Vinschen wrote:
>>> On Jun 11 17:53, Daniel Colascione wrote:
g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem
/u
On Wed, Jun 12, 2013 at 11:06:15AM -0700, Daniel Colascione wrote:
>On 6/12/2013 2:46 AM, Corinna Vinschen wrote:
>> On Jun 11 17:53, Daniel Colascione wrote:
>>> g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem
>>> /users/dancol/software/cygwin/winsup/cygwin/include
>>> -B
On 6/12/2013 2:46 AM, Corinna Vinschen wrote:
> On Jun 11 17:53, Daniel Colascione wrote:
>> g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem
>> /users/dancol/software/cygwin/winsup/cygwin/include
>> -B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem
>> /users/
On Jun 11 17:53, Daniel Colascione wrote:
> g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem
> /users/dancol/software/cygwin/winsup/cygwin/include
> -B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem
> /users/dancol/software/cygwin/i686-pc-cygwin/newlib/targ-in
g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem
/users/dancol/software/cygwin/winsup/cygwin/include
-B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem
/users/dancol/software/cygwin/i686-pc-cygwin/newlib/targ-include -isystem
/users/dancol/software/cygwin/newli
I've rebuilt the Cygwin dll from CVS sources today and all programs using
pseudo terminals hang. I've tried sshd, in.telnetd (via inetd), rxvt and
MC and all of them hang. If I start MC without subshell support (i.e. pty
support is not used) it will work flawlessly. in.telnetd manages to
execute lo
Hello,
On Thu, 10 Mar 2005, Pavel Tsekov wrote:
> With cygwin1.dll built from like 1 hour ago trying to connect to my Cygwin
> machine from a linux machine always fail like this:
>
> ssh_exchange_identification: read: Connection reset by peer
Just for the record - I've just refreshed my local so
I just tried the feb 14th snapshot on my XP(HT) machine, and the my test
ran over 5100 iterations before finnaly exhausting my disk space with
strace output, but there were NO FAILURES!! I'm going to let it run
with strace turned off just to see how far it will go, but this looks
very good.
R
Volker Quetschke wrote:
Just FYI, I build a cygwin dll from current cvs (last
winsup/cygwin/ChangeLog entry 2004-02-09 Ralf H.)
with debugging enabled and rerun this script. It didn't freeze, I
stopped it after 1588 iterations, but it produced one stackdump
and wrote some errors from make to stderr
On Sun, Feb 08, 2004 at 11:26:54PM -0500, Pierre A. Humblet wrote:
>~: uname -a
>CYGWIN_ME-4.90 hpn5170x 1.5.8(0.110/4/2) 2004-02-08 21:39 i686 unknown
>unknown Cygwin
>
>With the latest cvs on WinME, the famous popup is back, at least in
>processes running under make.
Here
~: uname -a
CYGWIN_ME-4.90 hpn5170x 1.5.8(0.110/4/2) 2004-02-08 21:39 i686 unknown
unknown Cygwin
With the latest cvs on WinME, the famous popup is back, at least in
processes running under make.
I have also mentioned previously that since 1.5.7 hitting ^C during make
(building cygwin) causes
Brian Ford wrote:
Incidentally, is there a way to reliably compare two CVS built DLLs from
the cygcheck or uname -a output?
I don't think so, since both just include the date the DLL was built.
FWIW, this problem appears to be fixed by:
http://www.cygwin.com/ml/cygwin/2004-01/msg01160.html
Concu
On Mon, 26 Jan 2004, David Rothenberger wrote:
> Brian Ford wrote:
> > Are you sure this is the latest CVS? It looks like the same problem fixed
> > here to me:
> >
> > http://www.cygwin.com/ml/cygwin/2004-01/msg01140.html
> >
> Yes, I'm sure it is the l
Brian Ford wrote:
Are you sure this is the latest CVS? It looks like the same problem fixed
here to me:
http://www.cygwin.com/ml/cygwin/2004-01/msg01140.html
Yes, I'm sure it is the latest CVS. The problem above is fixed in my
build, but not the problem I reported. It looks the same, bu
On Mon, 26 Jan 2004, David Rothenberger wrote:
> I'm having a problem with signals with the latest CVS DLL and ash.
>
> I have a script tst.sh:
>
> #!/bin/sh
> while true; do
> date
> sleep 20
> done
>
>
> >
I'm having a problem with signals with the latest CVS DLL and ash.
I have a script tst.sh:
#!/bin/sh
while true; do
date
sleep 20
done
>From a cmd.exe prompt, if I do "bash tst.sh" and then press Ctrl-C,
the script terminates.
If
I'm running the attached sh script from WinXP "Scheduled Tasks" and see
that curl launch defunct sh (or bash if used instead of sh).
curl can be replace by : ls, ... to see the same problem.
Command in the task sheduler (Same effect from the run program dialog) :
D:\cygwin\bin\bash.exe -c "/cygd
Yitzchak Scott-Thoennes wrote:
On Thu, Dec 18, 2003 at 06:09:54PM -0500, Christopher Faylor <[EMAIL PROTECTED]> wrote:
On Fri, Dec 19, 2003 at 12:04:02AM +0100, Philippe Torche wrote:
I've tested the CVS source 20031217 10:00AM (GMT+1) to see if fork/spawn
works on Multi CPU (4 Xeon) with Windo
Christopher Faylor wrote:
On Fri, Dec 19, 2003 at 12:32:10AM +0100, Philippe Torche wrote:
Sorry, but why would your urgency have any bearing on a community,
volunteer project?
Sorry too, We have been surprised by our first test on a multi CPU
engine, after one year of development without big prob
On Fri, Dec 19, 2003 at 12:32:10AM +0100, Philippe Torche wrote:
>>Sorry, but why would your urgency have any bearing on a community,
>>volunteer project?
>
>Sorry too, We have been surprised by our first test on a multi CPU
>engine, after one year of development without big problem (only a tee
>pr
On Thu, Dec 18, 2003 at 06:09:54PM -0500, Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 19, 2003 at 12:04:02AM +0100, Philippe Torche wrote:
> >I've tested the CVS source 20031217 10:00AM (GMT+1) to see if fork/spawn
> >works on Multi CPU (4 Xeon) with Windows 2003 Server (see old me
Christopher Faylor wrote:
On Fri, Dec 19, 2003 at 12:04:02AM +0100, Philippe Torche wrote:
I've tested the CVS source 20031217 10:00AM (GMT+1) to see if fork/spawn
works on Multi CPU (4 Xeon) with Windows 2003 Server (see old message
about it in the mailing list). Unfortunatly It doesn't !
Belo
On Fri, Dec 19, 2003 at 12:04:02AM +0100, Philippe Torche wrote:
>I've tested the CVS source 20031217 10:00AM (GMT+1) to see if fork/spawn
>works on Multi CPU (4 Xeon) with Windows 2003 Server (see old message
>about it in the mailing list). Unfortunatly It doesn't !
>
>Below a test script, use i
I've tested the CVS source 20031217 10:00AM (GMT+1) to see if fork/spawn
works on Multi CPU (4 Xeon) with Windows 2003 Server (see old message
about it in the mailing list). Unfortunatly It doesn't !
Below a test script, use it by running run_t.sh. After some time (< 1
minute) one or more of th
I had forgotten to include cygcheck.out, here it is.
Pierre
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Thu Apr 03 00:00:29 2003
Windows ME Ver 4.90 Build 3000
Path: c:\HOME\Pierre\bin\share
c:\HOME\Pierre\bin\cygwin
c:\progra~1\cygwin\usr\local\bin
With the latest cygwin from CVS on WinME I experience strange problems
in bash, both in rxvt and cygwin.bat. I noticed it first yesterday,
first time I rebuilt in about a week.
>From time to time it looks like bash is running again before a
command completes. Below, note the prompt *before* the
This is a heads up so that hopefully this issue can be resolved before
1.3.19. I just updated from CVS this morning and noticed that symlink
handling is different in at least one context:
$ rxvt -e slogin localhost # fails unless pwd = /usr/bin
$ rxvt -e /usr/bin/slogin localhost
Christopher Faylor wrote:
> On Mon, Oct 21, 2002 at 03:03:13PM -0400, Norman Vine wrote:
> >Christopher Faylor writes:
> >
> >> I was able to duplicate Jason's mmap problem with his version of exim
> >> and, so, I think I was also able to fix it.
>
> >> So, try a snapshot. Collect them all. Win
Chris,
On Tue, Oct 22, 2002 at 10:23:26AM +0400, Roman Belenov wrote:
> I tried 20021020 snapshot (I experienced this fork problem too); now
> cygwin fails on the second fork level :
I'm seeing a second level fork problem with my exim too. However,
unlike the original problem which occurred "all
I tried 20021020 snapshot (I experienced this fork problem too); now
cygwin fails on the second fork level :
E:\>bash
bash-2.05b$ bash
bash-2.05b$ bash
1076 [main] bash 3612 fhandler_disk_file::fixup_mmap_after_fork: requested 0x
9C != 0x0 mem alloc base 0x9C, state 0x2000, size 2088960
> On Mon, Oct 21, 2002 at 10:42:45PM -0500, Gary R. Van Sickle wrote:
> >>I was able to duplicate Jason's mmap problem with his version of exim
> >>and, so, I think I was also able to fix it.
> >>
> >>The latest snapshot should solve this problem. The hanging problem
> >>that I mentioned previousl
On Mon, Oct 21, 2002 at 10:42:45PM -0500, Gary R. Van Sickle wrote:
>>I was able to duplicate Jason's mmap problem with his version of exim
>>and, so, I think I was also able to fix it.
>>
>>The latest snapshot should solve this problem. The hanging problem
>>that I mentioned previously seems to b
> I was able to duplicate Jason's mmap problem with his version of exim
> and, so, I think I was also able to fix it.
>
> The latest snapshot should solve this problem. The hanging problem that
> I mentioned previously seems to be gone, too... or, more likely, it
> will manifest itself 10 seconds
Norman Vine wrote:
> Christopher Faylor writes:
> > The signal 11 is a problem. There should
> > be a stackdump file. Please decode the addresses with addr2line and
report
> > them here.
$ addr2line -e /bin/cygwin1.dll -f 0x61088F0F 0x61088ED7 0x61034584
0x61077A1F 0x61007A61 0x61007C47 0x
6
Try setting the heap_chunk_size back down to 256M.
The stack dump is just the result of the abort in fork.cc which was
caused by the memory error so it isn't very useful. Thanks for decoding
it, though.
cgf
On Mon, Oct 21, 2002 at 09:41:17PM -0400, Pierre A. Humblet wrote:
>WinMe, dll built fro
WinMe, dll built from cvs last night.
/obj: uname -a
CYGWIN_ME-4.90 HPN5170X 1.3.14(0.62/3/2) 2002-10-20 21:59 i686 unknown
3 crashes observed, first two under rxvt, windows went away too fast to
read message. Last one was in console.
/obj: make
C:\PROGRAM FILES\CYGWIN\BIN\SH.EXE: *** 1. unable
Christopher Faylor writes:
> On Mon, Oct 21, 2002 at 03:03:13PM -0400, Norman Vine wrote:
> >Christopher Faylor writes:
> >
> >> I was able to duplicate Jason's mmap problem with his version of exim
> >> and, so, I think I was also able to fix it.
> >>
> >> The latest snapshot should solve this pr
On Mon, Oct 21, 2002 at 03:03:13PM -0400, Norman Vine wrote:
>Christopher Faylor writes:
>
>> I was able to duplicate Jason's mmap problem with his version of exim
>> and, so, I think I was also able to fix it.
>>
>> The latest snapshot should solve this problem. The hanging problem that
>> I ment
Christopher Faylor writes:
> I was able to duplicate Jason's mmap problem with his version of exim
> and, so, I think I was also able to fix it.
>
> The latest snapshot should solve this problem. The hanging problem that
> I mentioned previously seems to be gone, too... or, more likely, it
> wil
I was able to duplicate Jason's mmap problem with his version of exim
and, so, I think I was also able to fix it.
The latest snapshot should solve this problem. The hanging problem that
I mentioned previously seems to be gone, too... or, more likely, it
will manifest itself 10 seconds after I se
Jason Tishler wrote
$ tail -1 /var/spool/exim/log/mainlog
2002-10-18 16:18:23 daemon: fork of queue-runner process failed: Resource
temporarily unavailable
$ ps -ef
exim 6481096 ? 16:18:22 /usr/local/bin/exim-4.10-1
That's probably a privately compiled exim.
Does it use special l
On Fri, Oct 18, 2002 at 08:09:44PM -0400, Christopher Faylor wrote:
>On Fri, Oct 18, 2002 at 04:27:46PM -0400, Jason Tishler wrote:
>>On Fri, Oct 18, 2002 at 03:34:39PM -0400, Christopher Faylor wrote:
>>>Are you running something like cygserver that would be using shared
>>>memory?
>>
>>No.
>
>Ok.
On Fri, Oct 18, 2002 at 04:27:46PM -0400, Jason Tishler wrote:
>On Fri, Oct 18, 2002 at 03:34:39PM -0400, Christopher Faylor wrote:
>>Are you running something like cygserver that would be using shared
>>memory?
>
>No.
Ok. Do you have an exim config file, then? I don't see it doing anything
with
Chris,
On Fri, Oct 18, 2002 at 03:34:39PM -0400, Christopher Faylor wrote:
> Are you running something like cygserver that would be using shared
> memory?
No.
> I don't see why shared memory would be a problem running bash.
$ uname -a
CYGWIN_NT-5.0 TISHLERJASON 1.3.14s(0.62/3/2) 20021015 13:13:
On Fri, Oct 18, 2002 at 11:13:19AM -0400, Jason Tishler wrote:
>Chris,
>
>On Fri, Oct 18, 2002 at 10:23:40AM -0400, Christopher Faylor wrote:
>> Can you send cygcheck output as an attachment?
>
>See attached.
Are you running something like cygserver that would be using shared memory?
I don't see w
Chris,
On Fri, Oct 18, 2002 at 10:23:40AM -0400, Christopher Faylor wrote:
> I still can't duplicate this.
A binary search of the recent snapshots indicates that 2002-Oct-14 is OK
but 2002-Oct-15 is not. So, I think that we can conclude that one of
the following changes is the culprit:
http
Chris,
On Fri, Oct 18, 2002 at 10:23:40AM -0400, Christopher Faylor wrote:
> Can you send cygcheck output as an attachment?
See attached.
Jason
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Fri Oct 18 11:05:16 2002
Windows 2000 Professional Ver 5.0 Build 2195 Service Pack
* recreate_mmaps_after_fork_failed
>> >[snip]
>>
>> Is there some reason you're refusing to try a snapshot?
>
>I get the following when running under the latest CVS (as of about 7:30
>AM EST today):
>
>$ exim -bdf -q15m
>803 [main]
:\cygwin\bin\bash
> >bash-2.05b$ ls
> > 8 [main] bash 3952 fixup_mmaps_after_fork: base address fails to match
>requested address 0xBD
> >c:\cygwin\bin\bash.exe: *** recreate_mmaps_after_fork_failed
> >[snip]
>
> Is there some reason you're refusing
the project web page for details:
>http://www.cygwin.com/lists.html (#5.7.2)
>>
>>Hi,
>>I was trying to get the latest cygwin CVS working and ran into some
>>difficulties. An strace of rxvt hangs as it forks:
>
>Are you sure you're using the *latest* CVS?
Pin
ranquil. Maybe even inviting!
Egads, That almost sounds serious! Anyone know of a good course on humor?
;-)
Larry
Original Message:
-
From: Christopher Faylor [EMAIL PROTECTED]
Date: Thu, 17 Oct 2002 14:29:52 -0400
To: [EMAIL PROTECTED]
Subject: Re: latest cvs fork problems
On
On Thu, Oct 17, 2002 at 02:12:18PM -0400, Rob Napier wrote:
>Just another datapoint. On XP SP1 + Cygwin 1.3.13-2, here's what I get
>whenever something tries to fork:
>
>O:\>c:\cygwin\bin\bash
>bash-2.05b$ ls
> 8 [main] bash 3952 fixup_mmaps_after_fork: base address fails to match req
>uested
Just another datapoint. On XP SP1 + Cygwin 1.3.13-2, here's what I get
whenever something tries to fork:
O:\>c:\cygwin\bin\bash
bash-2.05b$ ls
8 [main] bash 3952 fixup_mmaps_after_fork: base address fails to match req
uested address 0xBD
c:\cygwin\bin\bash.exe: *** recreate_mmaps_after_f
On Mon, Oct 14, 2002 at 02:28:42PM +0400, Roman Belenov wrote:
>Same here with 1.3.13-2; it seems that all programs are affected (e.g.
>I can't run anything from bash since bash can't fork). I'm using
>WIndows XP SP1.
cygcheck output would confirm if this is really 1.3.13-2 that you're running.
;
>Hi,
>I was trying to get the latest cygwin CVS working and ran into some
>difficulties. An strace of rxvt hangs as it forks:
Are you sure you're using the *latest* CVS?
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.
Same here with 1.3.13-2; it seems that all programs are affected (e.g. I can't run
anything from bash since bash can't fork). I'm using WIndows XP SP1.
Steve O <[EMAIL PROTECTED]> writes:
> On Mon, Oct 14, 2002 at 03:09:50AM -, [EMAIL PROTECTED] wrote:
>> <[EMAIL PROTECTED]>:
>> Sorry, only
On Mon, Oct 14, 2002 at 03:09:50AM -, [EMAIL PROTECTED] wrote:
> <[EMAIL PROTECTED]>:
> Sorry, only subscribers may post. See the project web page for details:
>http://www.cygwin.com/lists.html (#5.7.2)
Hi,
I was trying to get the latest cygwin CVS working and ran into some
difficulties.
On Wed, Apr 17, 2002 at 11:25:53AM -0400, Jason Tishler wrote:
> After some more digging, I believe that I have found the root cause to
> the above problem. The new way, via NetGetDCName(), causes two extra
> backslashes to be prepended to the PDC name as demonstrated by the
> attached test progr
On Fri, Apr 12, 2002 at 11:21:32AM -0400, Jason Tishler wrote:
> Using the latest CVS, I am getting the following Event Log error messages:
>
> o fatal: setuid 19695: Operation not permitted
> o (CRON) error (can't switch user context)
>
> with sshd and cron, re
Using the latest CVS, I am getting the following Event Log error messages:
o fatal: setuid 19695: Operation not permitted
o (CRON) error (can't switch user context)
with sshd and cron, respectively. After some debugging, I determined
that the following patch is causing the pr
60 matches
Mail list logo
