public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: numerous bugs i've found in cygwin while developing XEmacs
@ 2002-06-04 13:08 Michael Potter
  0 siblings, 0 replies; 18+ messages in thread
From: Michael Potter @ 2002-06-04 13:08 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: numerous bugs i've found in cygwin while developing XEmacs
@ 2002-06-04  8:45 Michael Potter
  2002-06-04 11:07 ` Christopher Faylor
  2002-06-04 16:26 ` Nicholas Wourms
  0 siblings, 2 replies; 18+ messages in thread
From: Michael Potter @ 2002-06-04  8:45 UTC (permalink / raw)
  To: cygwin

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/

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: numerous bugs i've found in cygwin while developing XEmacs
@ 2002-06-03 14:19 Michael Potter
  2002-06-03 14:57 ` Christopher Faylor
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Potter @ 2002-06-03 14:19 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* RE: numerous bugs i've found in cygwin while developing XEmacs
@ 2002-06-03 13:59 Michael Potter
  2002-06-03 14:06 ` Christopher Faylor
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Potter @ 2002-06-03 13:59 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: numerous bugs i've found in cygwin while developing XEmacs
@ 2002-06-03 11:21 Michael Potter
  2002-06-03 12:24 ` Christopher Faylor
  2002-06-03 12:51 ` Robert Collins
  0 siblings, 2 replies; 18+ messages in thread
From: Michael Potter @ 2002-06-03 11:21 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* numerous bugs i've found in Cygwin while developing XEmacs
@ 2002-06-03  8:20 Ben Wing
  2002-06-03  9:33 ` numerous bugs i've found in cygwin " Christopher Faylor
  0 siblings, 1 reply; 18+ messages in thread
From: Ben Wing @ 2002-06-03  8:20 UTC (permalink / raw)
  To: cygwin

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/

^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2002-06-04 23:17 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-04 13:08 numerous bugs i've found in cygwin while developing XEmacs Michael Potter
  -- strict thread matches above, loose matches on Subject: below --
2002-06-04  8:45 Michael Potter
2002-06-04 11:07 ` Christopher Faylor
2002-06-04 16:26 ` Nicholas Wourms
2002-06-03 14:19 Michael Potter
2002-06-03 14:57 ` Christopher Faylor
2002-06-04  9:23   ` Christopher Faylor
2002-06-03 13:59 Michael Potter
2002-06-03 14:06 ` Christopher Faylor
2002-06-03 11:21 Michael Potter
2002-06-03 12:24 ` Christopher Faylor
2002-06-03 12:51 ` Robert Collins
2002-06-03  8:20 numerous bugs i've found in Cygwin " Ben Wing
2002-06-03  9:33 ` numerous bugs i've found in cygwin " Christopher Faylor
2002-06-03 11:05   ` Conrad Scott
2002-06-03 11:52     ` Christopher Faylor
2002-06-03 12:14       ` Conrad Scott
2002-06-03 12:26         ` Christopher Faylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).