Re: numerous bugs i've found in cygwin while developing XEmacs

Re: numerous bugs i've found in cygwin while developing XEmacs

[Michael Potter]

> On Mon, Jun 03, 2002 at 03:59:45PM -0500, Michael Potter wrote:
> >>You should resubmit as an mmap only bug.  Cygipc's shmat support uses
> >>mmap, and cygwins 'native' shmat support is in development.  Chances
> >>are, any shmat bug reports will (unfortunately) end up in /dev/null.
> >
> >Just did.
> 
> And, I believe that this was a problem which was reported back in April.
> If so, it's been fixed in snapshots for a while. cgf 

I did my home work :).

The examples from April work on my machine, the example I
submitted is different from the april examples in that
it has two forks.  Without the first fork(), my example
works fine.

-- 
Michael Potter

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Mon, Jun 03, 2002 at 04:19:00PM -0500, Michael Potter wrote:
>> On Mon, Jun 03, 2002 at 03:59:45PM -0500, Michael Potter wrote:
>> >>You should resubmit as an mmap only bug.  Cygipc's shmat support uses
>> >>mmap, and cygwins 'native' shmat support is in development.  Chances
>> >>are, any shmat bug reports will (unfortunately) end up in /dev/null.
>> >
>> >Just did.
>> 
>> And, I believe that this was a problem which was reported back in April.
>> If so, it's been fixed in snapshots for a while. cgf 
>
>I did my home work :).

So, you're saying that you you actually tried a cygwin snapshot?

If so, that would have been useful information to have.  I haven't been
paying attention to your cygipc bug reports so if you mentioned this
there, then I missed it.

>The examples from April work on my machine, the example I submitted is
>different from the april examples in that it has two forks.  Without
>the first fork(), my example works fine.

The examples from April worked on 1.3.10 for many people, too.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Mon, Jun 03, 2002 at 05:57:15PM -0400, Christopher Faylor wrote:
>On Mon, Jun 03, 2002 at 04:19:00PM -0500, Michael Potter wrote:
>>> On Mon, Jun 03, 2002 at 03:59:45PM -0500, Michael Potter wrote:
>>> >>You should resubmit as an mmap only bug.  Cygipc's shmat support uses
>>> >>mmap, and cygwins 'native' shmat support is in development.  Chances
>>> >>are, any shmat bug reports will (unfortunately) end up in /dev/null.
>>> >
>>> >Just did.
>>> 
>>> And, I believe that this was a problem which was reported back in April.
>>> If so, it's been fixed in snapshots for a while. cgf 
>>
>>I did my home work :).
>
>So, you're saying that you you actually tried a cygwin snapshot?

Ping?  Did you try a snapshot?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Nicholas Wourms]

> when someone puts "1.3.11(CVS) in the subject line, are they
> refering to cygwin 1.3.11?
> or cvs 1.3.11 compiled under cygwin?
> or the latest snapshot of cygwin, that when stablized will be cygwin
> 1.3.11?
The faq says that we should submit bug reports with the name of the
application + version in the subject line.  My intention was to address an
issue with the latest version of the cygwin core that I compiled from cvs
sources.  I'm sorry for any confusion this caused, should I use a
different naming schema in the future?

Cheers,


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Michael Potter]

> I don't recommend anything except that I do recommend that if you have a
> problem and someone says "Fixed in the latest snapshot" you can
> 1) try the snapshot or
> 2) not try the snapshot, but don't keep describing a bug
> that may be fixed in the snapshot.
> 
> In other words if I say "I fixed it, go here to try it".  The
> correct response from you is not "It is not fixed" unless you've
> actually tried what I told you to try.

You did not say, "I fixed it, go here to try it".
You said :"And, I believe that this was a problem which was reported
           back in April. If so, it's been fixed in snapshots for a while."

the key difference between those two statements is the word "believe".

My response was that my sample was different because my sample program
has two forks, where the april samples had one fork.  the april
samples work on my sytem, my sample does not work on my system,
indicating that i had the code that fixed the april problem.

I also explained why it was difficult for me to try the new snapshots
hoping someone would have pity on my situation and try my example code on
the latest snapshot. (thanks corinna)  I also reposted after someone
suggested I remove the depedency on ipc.  I am not lazy as demonstrated
by the fact that I have _many_ hours
investing in isolating the problem from the 30,000 line program
to the 100 or so lines I posted.

I am a believer in the cygwin project and I am going to be working
my butt to help and promote cygwin.

As we speak, my sys admin is downloading and trying the latest
snapshot.  We are currently dependent on cygipc, and it is my
understanding that cygipc is deprecated.  This limits my ability
to test the latest snapshot with our full source code.

-- 
potter

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Tue, Jun 04, 2002 at 10:39:56AM -0500, Michael Potter wrote:
>Reply-to: cygwin at cygwin dot com
>On Mon, Jun 03, 2002 at 04:19:00PM -0500, Michael Potter wrote:
>>>> On Mon, Jun 03, 2002 at 03:59:45PM -0500, Michael Potter wrote:
>>>> >>You should resubmit as an mmap only bug.  Cygipc's shmat support uses
>>>> >>mmap, and cygwins 'native' shmat support is in development.  Chances
>>>> >>are, any shmat bug reports will (unfortunately) end up in /dev/null.
>>>> >
>>>> >Just did.
>>>>
>>>> And, I believe that this was a problem which was reported back in April.
>>>> If so, it's been fixed in snapshots for a while. cgf
>>
>>I did my home work :).
>>
>>So, you're saying that you you actually tried a cygwin snapshot?
>
>No.  It is not very easy for me to try snapshots.  We are a UNIX shop
>and we only have one win2k box, and it is not controlled by me.  
>It is actually shared by many people using terminal services and
>some slick little linux boxes from a company called neoware.
>
>I have asked the sysadmin to install the lastest snap shot.
>
>> If so, that would have been useful information to have.  I haven't been
>> paying attention to your cygipc bug reports so if you mentioned this
>> there, then I missed it.
>
>I put the version of cygwin (1.3.10) in the subject line.  It was
>my impression that it was the latest "stable" release.  How often
>do you recommend that I ask my system administrator to download
>and install the lastest release?

I don't recommend anything except that I do recommend that if you have a
problem and someone says "Fixed in the latest snapshot" you can 1) try
the snapshot or 2) not try the snapshot, but don't keep describing a bug
that may be fixed in the snapshot.

In other words if I say "I fixed it, go here to try it".  The correct
response from you is not "It is not fixed" unless you've actually tried
what I told you to try.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Michael Potter]

Reply-to: cygwin at cygwin dot com
On Mon, Jun 03, 2002 at 04:19:00PM -0500, Michael Potter wrote:
>>> On Mon, Jun 03, 2002 at 03:59:45PM -0500, Michael Potter wrote:
>>> >>You should resubmit as an mmap only bug.  Cygipc's shmat support uses
>>> >>mmap, and cygwins 'native' shmat support is in development.  Chances
>>> >>are, any shmat bug reports will (unfortunately) end up in /dev/null.
>>> >
>>> >Just did.
>>>
>>> And, I believe that this was a problem which was reported back in April.
>>> If so, it's been fixed in snapshots for a while. cgf
>
>I did my home work :).
>
>So, you're saying that you you actually tried a cygwin snapshot?

No.  It is not very easy for me to try snapshots.  We are a UNIX shop
and we only have one win2k box, and it is not controlled by me.  
It is actually shared by many people using terminal services and
some slick little linux boxes from a company called neoware.

I have asked the sysadmin to install the lastest snap shot.

> If so, that would have been useful information to have.  I haven't been
> paying attention to your cygipc bug reports so if you mentioned this
> there, then I missed it.

I put the version of cygwin (1.3.10) in the subject line.  It was
my impression that it was the latest "stable" release.  How often
do you recommend that I ask my system administrator to download
and install the lastest release?

when someone puts "1.3.11(CVS) in the subject line, are they
refering to cygwin 1.3.11?
or cvs 1.3.11 compiled under cygwin?
or the latest snapshot of cygwin, that when stablized will be cygwin 1.3.11?

I actually have about 150,000 lines of C compiled under cygwin.
About every problem that I had compiling the C code could be
tracked back to my code not being posix compliant.  I was very
happy to correct my code where it was not posix compliant.
If it ever comes up to make cygwin less picky about being posix
compliant, my vote is "keep it posix compliant with as few
extensions as possible".  I like cygipc, but had it not
existed I would not have complained a bit; i had already
started to convert to posix ipc anyway.

Keep up the good work.

> 
> >The examples from April work on my machine, the example I submitted is
> >different from the april examples in that it has two forks.  Without
> >the first fork(), my example works fine.
> 
> The examples from April worked on 1.3.10 for many people, too.
> 
> cgf

-- 
potter

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Mon, Jun 03, 2002 at 03:59:45PM -0500, Michael Potter wrote:
>>You should resubmit as an mmap only bug.  Cygipc's shmat support uses
>>mmap, and cygwins 'native' shmat support is in development.  Chances
>>are, any shmat bug reports will (unfortunately) end up in /dev/null.
>
>Just did.

And, I believe that this was a problem which was reported back in April.
If so, it's been fixed in snapshots for a while.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: numerous bugs i've found in cygwin while developing XEmacs

[Michael Potter]

> > > >[1] mmap[] and fork[].  The "pdump" [portable dumper] method of
> > > > implementing undumping for XEmacs writes out all the data into
> > > > a large file during building, and then reads it in when the
> > > > program starts.  the file looks like this:
> > > >-rw-r--r--    1 Ben Wing None      3280684 Jun  2 02:58 xemacs.dmp
> > > >
> > > >if mmap support exists, it's loaded using mmap[].  This fails
> > > > miserably when a fork[] happens, as the child evidently doesn't
> > > > get the mmap[]ed data visible in it and thus seg faults occur.
> > >
> > > This is obviously not supposed to be the way things work.  It
> > > can't be as simple as "mmap doesn't work across forks".
> >
> > It could be as simple as the example I submitted last night.
> > That submission includes a sample program.
> >
> > June 02, 2002 20:32
> > cygwin 1.3.10 fork+sockets+shmat/mmap=recreate_mmaps_after_fork_failed
> >
> > The sample uses shmat, but if someone is willing to work on it,
> > I would be happy to submit the example using mmap.
> 
> 
> You should resubmit as an mmap only bug. Cygipc's shmat support uses
> mmap, and cygwins 'native' shmat support is in development. Chances are,
> any shmat bug reports will (unfortunately) end up in /dev/null.
> 
> Rob

Just did.

-- 
Michael Potter
pottmi@lidp.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: numerous bugs i've found in cygwin while developing XEmacs

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Michael Potter
> Sent: Tuesday, 4 June 2002 4:22 AM
> To: cygwin@cygwin.com
> Subject: Re: numerous bugs i've found in cygwin while 
> developing XEmacs
> 
> 
> > >[1] mmap[] and fork[].  The "pdump" [portable dumper] method of
> > > implementing undumping for XEmacs writes out all the data into
> > > a large file during building, and then reads it in when the
> > > program starts.  the file looks like this:
> > >-rw-r--r--    1 Ben Wing None      3280684 Jun  2 02:58 xemacs.dmp
> > >
> > >if mmap support exists, it's loaded using mmap[].  This fails
> > > miserably when a fork[] happens, as the child evidently doesn't
> > > get the mmap[]ed data visible in it and thus seg faults occur.
> >
> > This is obviously not supposed to be the way things work.  It
> > can't be as simple as "mmap doesn't work across forks".
> 
> It could be as simple as the example I submitted last night.
> That submission includes a sample program.
> 
> June 02, 2002 20:32
> cygwin 1.3.10 fork+sockets+shmat/mmap=recreate_mmaps_after_fork_failed
> 
> The sample uses shmat, but if someone is willing to work on it,
> I would be happy to submit the example using mmap.

You should resubmit as an mmap only bug. Cygipc's shmat support uses
mmap, and cygwins 'native' shmat support is in development. Chances are,
any shmat bug reports will (unfortunately) end up in /dev/null.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Mon, Jun 03, 2002 at 08:15:40PM +0100, Conrad Scott wrote:
>"Christopher Faylor" <cgf@redhat.com> wrote:
>> On Mon, Jun 03, 2002 at 07:06:44PM +0100, Conrad Scott wrote:
>> >I needed to download the (currently experimental) gdb 20020411-1 version
>> >to be able to attach to processes, so there might be an easy fix for that
>> >particular issue :-)
>>
>> gdb has been able to attach to a process for several years.
>
>Well, I'm not going to re-install the previous version to check this, but I
>recall that I had to upgrade to get something pretty major to work; like, if
>it wasn't attaching to processes it was using core files --- something on
>that scale. But maybe it was just a phase of the moon error (or, gulp, pilot
>error).

This really isn't worth arguing about.  I used the gdb from 2001/04 just a couple
of days ago to attach to a running process.

I believe I added the capability sometime in the 1998 timeframe.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Mon, Jun 03, 2002 at 01:21:30PM -0500, Michael Potter wrote:
>> >[1] mmap[] and fork[].  The "pdump" [portable dumper] method of
>> > implementing undumping for XEmacs writes out all the data into
>> > a large file during building, and then reads it in when the
>> > program starts.  the file looks like this:
>> >-rw-r--r--    1 Ben Wing None      3280684 Jun  2 02:58 xemacs.dmp
>> >
>> >if mmap support exists, it's loaded using mmap[].  This fails
>> > miserably when a fork[] happens, as the child evidently doesn't
>> > get the mmap[]ed data visible in it and thus seg faults occur.
>>
>> This is obviously not supposed to be the way things work.  It
>> can't be as simple as "mmap doesn't work across forks".
>
>It could be as simple as the example I submitted last night.
>That submission includes a sample program.
>
>June 02, 2002 20:32
>cygwin 1.3.10 fork+sockets+shmat/mmap=recreate_mmaps_after_fork_failed
>
>The sample uses shmat, but if someone is willing to work on it,
>I would be happy to submit the example using mmap.

If you are using the sysv shared memory in cygwin then that is a
work in progress.

If you're using the cygipc libarry, then it is presumably a bug in
that library, not cygwin.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Conrad Scott]

"Christopher Faylor" <cgf@redhat.com> wrote:
> On Mon, Jun 03, 2002 at 07:06:44PM +0100, Conrad Scott wrote:
> >I needed to download the (currently experimental) gdb 20020411-1 version
> >to be able to attach to processes, so there might be an easy fix for that
> >particular issue :-)
>
> gdb has been able to attach to a process for several years.

Well, I'm not going to re-install the previous version to check this, but I
recall that I had to upgrade to get something pretty major to work; like, if
it wasn't attaching to processes it was using core files --- something on
that scale. But maybe it was just a phase of the moon error (or, gulp, pilot
error).

// Conrad



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Mon, Jun 03, 2002 at 07:06:44PM +0100, Conrad Scott wrote:
>"Christopher Faylor" <cgf-cygwin@cygwin.com> wrote:
>> On Mon, Jun 03, 2002 at 08:21:08AM -0700, Ben Wing wrote:
>> >[3] problems with the debugger.
>> >   [b] can't attach to a running process.
>
>> Yep.  gdb has problems.  Attaching to a running process isn't one of them,
>> though.
>> The other ones are annoying but they are known.
>
>I needed to download the (currently experimental) gdb 20020411-1 version to
>be able to attach to processes, so there might be an easy fix for that
>particular issue :-)

gdb has been able to attach to a process for several years.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Michael Potter]

> >[1] mmap[] and fork[].  The "pdump" [portable dumper] method of
> > implementing undumping for XEmacs writes out all the data into
> > a large file during building, and then reads it in when the
> > program starts.  the file looks like this:
> >-rw-r--r--    1 Ben Wing None      3280684 Jun  2 02:58 xemacs.dmp
> >
> >if mmap support exists, it's loaded using mmap[].  This fails
> > miserably when a fork[] happens, as the child evidently doesn't
> > get the mmap[]ed data visible in it and thus seg faults occur.
>
> This is obviously not supposed to be the way things work.  It
> can't be as simple as "mmap doesn't work across forks".

It could be as simple as the example I submitted last night.
That submission includes a sample program.

June 02, 2002 20:32
cygwin 1.3.10 fork+sockets+shmat/mmap=recreate_mmaps_after_fork_failed

The sample uses shmat, but if someone is willing to work on it,
I would be happy to submit the example using mmap.

-- 
Michael Potter
LIDP Consulting Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Conrad Scott]

"Christopher Faylor" <cgf-cygwin@cygwin.com> wrote:
> On Mon, Jun 03, 2002 at 08:21:08AM -0700, Ben Wing wrote:
> >[3] problems with the debugger.
> >   [b] can't attach to a running process.

> Yep.  gdb has problems.  Attaching to a running process isn't one of them,
> though.
> The other ones are annoying but they are known.

I needed to download the (currently experimental) gdb 20020411-1 version to
be able to attach to processes, so there might be an easy fix for that
particular issue :-)

// Conrad



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor]

On Mon, Jun 03, 2002 at 08:21:08AM -0700, Ben Wing wrote:
>it would be nice if there were a "known bug" list posted somewhere so I had a
>sense if I'm just duplicating stuff already known about.

Would you like to maintain a "known bug" list?  I'll set you up with cvs web
page access, if so.

>[1] mmap[] and fork[].  The "pdump" [portable dumper] method of implementing
>undumping for XEmacs writes out all the data into a large file during building,
>and then reads it in when the program starts.  the file looks like this:
>
>-rw-r--r--    1 Ben Wing None      3280684 Jun  2 02:58 xemacs.dmp
>
>if mmap support exists, it's loaded using mmap[].  This fails miserably when a
>fork[] happens, as the child evidently doesn't get the mmap[]ed data visible in
>it and thus seg faults occur.

This is obviously not supposed to be the way things work.  It can't be as
simple as "mmap doesn't work across forks".

>[2] race conditions with pty's.  XEmacs implements "process" objects, which
>allow I/O to/from a subprocess.  This can be implemented either with pty's or
>pipes.  I recently rewrote the synchronous "call-process" command (which runs a
>command and waits to completion) using the asynchronous process objects.  first,
>note that the process's stdin descriptor has been set to non-blocking.  now,
>when the process has input, we go into a tight loop sending as much data as we
>can, until it blocks.  at that point, we "accept process output" by waiting up
>to 1 second, using select() to check for output from the process and grab it --
>this may allow the process to start reading more input.  the tight loop exits as
>soon as the system has accepted all data.  next thing, we send an "EOF" to the
>process -- for pipes, this means to close the descriptors, but for pty's this
>means to send the ^D character.  at that point, we go into a loop, doing "accept
>process output" until we get a SIGCHLD signal indicating the process has
>terminated.
>
>now, if i create a simple program that echoes its input to output, and run the
>above code using a few lines as input [usually, in fact, this:
>
>;; This buffer is for notes you don't want to save, and for Lisp evaluation.
>;; If you want to create a file, first visit that file with C-x C-f,
>;; then enter the text in that file's own buffer. (C-x is the standard
>;; XEmacs abbreviation for `Control+x', i.e. hold down the Control key
>;; while hitting the x key.)
>;;
>;; For Lisp evaluation, type an expression, move to the end and hit C-j.
>
>], then if i've chosen to use pipes, all is well.  however, with pty's, things
>get messed up.  first of all, the output from the process consists not only of
>the process's actual output, but, before its output is most of the first line of
>input [60 chars or so, it varies].  secondly, the process never terminates.  it
>appears that the ^D is not getting sent synchronously to the PTY, but is sent
>more like a signal, leapfrogging over any pending input -- thus, it must be that
>when we sent the ^D, about 60 chars have made it to the PTY and the rest are
>being buffered.  the PTY then reechoes the first line [like it should], and of
>course never closes the input.  evidently you need to make ^D synchronous.

^D is no sent asynchronously, AFAIK.  Since ptys are working relatively well
with things like ssh and rxvt, I don't think they can be quite that broken.
You never know, of course.

>[3] problems with the debugger.
>
>   [a] The "STOP" button never ever works for me.  It does not stop XEmacs from
>running, and after 2 seconds asks if you want to unattach from the process.  if
>you do, things get majorly wedged -- gdb hangs, and if you try to kill it from
>the Task Manager, that hangs, too.  Rebooting your system in an orderly way
>doesn't work because there's simply no way to kill gdb.  You have to hit the
>front-panel reset button.  BTW XEmacs is a window process, not a console
>process; i dunno if this matters.
>   [b] can't attach to a running process.
>   [c] can't ^C a running process from the console [related to [a], certainly].
>   [d] periodic crashes and hangs, can't duplicate; in general, it seems buggy
>and not very reliable.

Yep.  gdb has problems.  Attaching to a running process isn't one of them, though.
The other ones are annoying but they are known.

>[4] interference between Cygwin and MS DevStudio
>
>If I'm running a Cygwin compile [i.e. using make/gcc/etc] in the background, MS
>DevStudio is *waaaaaaaaaaaaaaaaaaaaay* slow when loading.  In particular, when
>it gets to the "loading workspace" phase, which normally takes a few seconds, it
>may take 2 minutes or more.  It seems like Cygwin is locking some resources in
>an anti-social fashion.  I've seen other similar problems, e.g. I'm sure that
>running two compiles in the background at once is far slower than running them
>in series, but I can't be so specific.

Cygwin doesn't lock any resource that I'm aware of.

>[5] Cygwin's non-standard way of allocating processes causes problems
>
>From bash, if you execute five subshells one right after the other, and do echo
>$$ in each one, you get a weird sequence like this:
>
>1036 1492 2036 1412 1560
>
>this is clearly echoing the Win32 process numbers, which are perhaps assigned at
>random so as to increase security (remember the C.1 Windows NT compliance?).
>However, this can screw up Unix programs, which expect the numbers to be
>assigned sequentially.

Cygwin uses windows pids.  Any UNIX program which expects pids to be sequential
is completely, totally, irretrievably broken.

>Particularly, if I'm running two cvs updates at once, chances are that
>one of them will abort at a random point saying "cannot create
>temporary file" or something of that sort.  It appears that cvs update
>runs at least one subprocess per file, and that subprocess creates a
>temporary file based on the process number.  it seems that what's
>happening is that, with process numbers being assigned at random, it's
>inevitable that eventually two subprocesses running one right after the
>other, one called by the each update process, will get the same process
>number, and they will interfere.  obvious solution is to not directly
>use the Win32 process, but to create special Cygwin process numbers
>that increment by 1 in an orderly fashion.

It may seem obvious but cygwin does go out its way to ensure that the
same pid is not used twice in succession.

>[6] Slowness
>
>-- An opendir() loop with a stat() to get directory status, etc.  is
>somewhere around 10-50x as slow as without the stat().  This probably
>accounts for much of the slowness in ls, find, cp, etc.  Given that
>most or all of the information needed for the stat() is available as
>part of the underlying FindNextFile call, and in the case of a symlink,
>it's easy to use that same info to determine whether the expensive
>symlink check needs to be done [system file or ends with .lnk], some
>simple caching could cause quite dramatic speed improvements.

There is nothing simple about caching filesystem information.  We have
been trying to speed up stat operations, however.  See the recent
discussions in this and the cygwin-developers mailing list.

>[7] "mv does a copy when you didn't ask it to"
>
>This is a personal pet peeve of mine.  Evidently this is by design, but
>the fact that if you accidentally have a shell cd'd to a directory in
>the middle of a tree you'd like to move, then mv tries to do the move
>by copying the *WHOLE DAMN THING*, is just very wrong and certainly
>counter to the "don't do weird and potentially dangerous magic unless
>the user said so" principle.  mv should just report an `Access Denied'
>error in this case; if you want the copy-then-erase behavior, use `mv
>-r' [granted, it doesn't currently exist, but a flag exactly like this
>did and maybe does exist in BSD].

'mv' comes from 'fileutils'.  It is apparently working as designed.

>[9] Cygwin setup program does not register itself in the control panel
>list of apps or provide an uninstall routine.  [We at XEmacs have a
>personal interest in this one since we use the Cygwin setup program to
>construct our own setup program.]

If you have a personal interest in it, why doesn't someone submit a patch?
Why are you relying on us to drive setup.exe development if it is so crucial
to your plans?

Hmm.  Now that I think of it, I don't recall ever seeing any setup patches
from Xemacs.

Anyway, thanks for your report.  I'll try to keep this in mind if I happen
to be working on the sections of code that you mention.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

numerous bugs i've found in Cygwin while developing XEmacs

[Ben Wing]

it would be nice if there were a "known bug" list posted somewhere so I had a
sense if I'm just duplicating stuff already known about.  it's true, the mailing
list archives are there, but it's often hard to figure out if the bug has been
reported or whether it ought to be fixed already but isn't, etc:

I am using:

~/school/post-college/art256/final/shrunk 2032$ uname -a
CYGWIN_NT-5.0 NEEEEEEE 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown

[1] mmap[] and fork[].  The "pdump" [portable dumper] method of implementing
undumping for XEmacs writes out all the data into a large file during building,
and then reads it in when the program starts.  the file looks like this:

-rw-r--r--    1 Ben Wing None      3280684 Jun  2 02:58 xemacs.dmp

if mmap support exists, it's loaded using mmap[].  This fails miserably when a
fork[] happens, as the child evidently doesn't get the mmap[]ed data visible in
it and thus seg faults occur.

[2] race conditions with pty's.  XEmacs implements "process" objects, which
allow I/O to/from a subprocess.  This can be implemented either with pty's or
pipes.  I recently rewrote the synchronous "call-process" command (which runs a
command and waits to completion) using the asynchronous process objects.  first,
note that the process's stdin descriptor has been set to non-blocking.  now,
when the process has input, we go into a tight loop sending as much data as we
can, until it blocks.  at that point, we "accept process output" by waiting up
to 1 second, using select() to check for output from the process and grab it --
this may allow the process to start reading more input.  the tight loop exits as
soon as the system has accepted all data.  next thing, we send an "EOF" to the
process -- for pipes, this means to close the descriptors, but for pty's this
means to send the ^D character.  at that point, we go into a loop, doing "accept
process output" until we get a SIGCHLD signal indicating the process has
terminated.

now, if i create a simple program that echoes its input to output, and run the
above code using a few lines as input [usually, in fact, this:

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, first visit that file with C-x C-f,
;; then enter the text in that file's own buffer. (C-x is the standard
;; XEmacs abbreviation for `Control+x', i.e. hold down the Control key
;; while hitting the x key.)
;;
;; For Lisp evaluation, type an expression, move to the end and hit C-j.

], then if i've chosen to use pipes, all is well.  however, with pty's, things
get messed up.  first of all, the output from the process consists not only of
the process's actual output, but, before its output is most of the first line of
input [60 chars or so, it varies].  secondly, the process never terminates.  it
appears that the ^D is not getting sent synchronously to the PTY, but is sent
more like a signal, leapfrogging over any pending input -- thus, it must be that
when we sent the ^D, about 60 chars have made it to the PTY and the rest are
being buffered.  the PTY then reechoes the first line [like it should], and of
course never closes the input.  evidently you need to make ^D synchronous.

[3] problems with the debugger.

   [a] The "STOP" button never ever works for me.  It does not stop XEmacs from
running, and after 2 seconds asks if you want to unattach from the process.  if
you do, things get majorly wedged -- gdb hangs, and if you try to kill it from
the Task Manager, that hangs, too.  Rebooting your system in an orderly way
doesn't work because there's simply no way to kill gdb.  You have to hit the
front-panel reset button.  BTW XEmacs is a window process, not a console
process; i dunno if this matters.
   [b] can't attach to a running process.
   [c] can't ^C a running process from the console [related to [a], certainly].
   [d] periodic crashes and hangs, can't duplicate; in general, it seems buggy
and not very reliable.

[4] interference between Cygwin and MS DevStudio

If I'm running a Cygwin compile [i.e. using make/gcc/etc] in the background, MS
DevStudio is *waaaaaaaaaaaaaaaaaaaaay* slow when loading.  In particular, when
it gets to the "loading workspace" phase, which normally takes a few seconds, it
may take 2 minutes or more.  It seems like Cygwin is locking some resources in
an anti-social fashion.  I've seen other similar problems, e.g. I'm sure that
running two compiles in the background at once is far slower than running them
in series, but I can't be so specific.

[5] Cygwin's non-standard way of allocating processes causes problems

From bash, if you execute five subshells one right after the other, and do echo
$$ in each one, you get a weird sequence like this:

1036 1492 2036 1412 1560

this is clearly echoing the Win32 process numbers, which are perhaps assigned at
random so as to increase security (remember the C.1 Windows NT compliance?).
However, this can screw up Unix programs, which expect the numbers to be
assigned sequentially. Particularly, if I'm running two cvs updates at once,
chances are that one of them will abort at a random point saying "cannot create
temporary file" or something of that sort.  It appears that cvs update runs at
least one subprocess per file, and that subprocess creates a temporary file
based on the process number.  it seems that what's happening is that, with
process numbers being assigned at random, it's inevitable that eventually two
subprocesses running one right after the other, one called by the each update
process, will get the same process number, and they will interfere.  obvious
solution is to not directly use the Win32 process, but to create special Cygwin
process numbers that increment by 1 in an orderly fashion.

[6] Slowness

-- An opendir() loop with a stat() to get directory status, etc. is somewhere
around 10-50x as slow as without the stat().  This probably accounts for much of
the slowness in ls, find, cp, etc.  Given that most or all of the information
needed for the stat() is available as part of the underlying FindNextFile call,
and in the case of a symlink, it's easy to use that same info to determine
whether the expensive symlink check needs to be done [system file or ends with
.lnk], some simple caching could cause quite dramatic speed improvements.

-- XEmacs `configure', which for the most part runs gcc repeatedly to check for
the presence and absence of various features, is *DOG* slow.  It takes upwards
of 10 minutes on my Pentium III 700Mhz -- compared to maybe 3 minutes on my old
Pentium 90Mhz running Linux from 8 years ago!  Compilation in general is way
slow, too.  The obvious culprit is process spawning.  gcc spawns a number of
sub-processes -- has it been rewritten to use spawn() instead of fork()?  This
should happen to all basic cygwin tools, if possible. (If gcc has already been
rewritten this way, I have no idea what's going on.  But the apparent antisocial
behavior mentioned above w.r.t. DevStudio could well be the tricky locking and
such that goes on in order to implement fork().)

[7] "mv does a copy when you didn't ask it to"

This is a personal pet peeve of mine.  Evidently this is by design, but the fact
that if you accidentally have a shell cd'd to
a directory in the middle of a tree you'd like to move, then mv tries to do the
move by copying the *WHOLE DAMN THING*, is just very wrong and certainly counter
to the "don't do weird and potentially dangerous magic unless the user said so"
principle.  mv should just report an `Access Denied' error in this case; if you
want the copy-then-erase behavior, use `mv -r' [granted, it doesn't currently
exist, but a flag exactly like this did and maybe does exist in BSD].

[8] Cygwin bash doesn't let you exit the console automatically when you shut
down

This can be controlled using SetConsoleCtrlHandler and
SetProcessShutdownParameters.  Particularly if bash is just sitting there idle,
it should allow itself to be shut down automatically and do the equivalent of
calling `exit'.

[9] Cygwin setup program does not register itself in the control panel list of
apps or provide an uninstall routine. [We at XEmacs have a personal interest in
this one since we use the Cygwin setup program to construct our own setup
program.]



ben






--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/