Outstanding issues with current DLL?

[Christopher Faylor]

On Sun, Mar 11, 2001 at 09:58:47PM +0930, Trevor Forbes wrote:
>Well, I went round and round in circles until I realised that going back
>though the patches by doing a cvs co -D XXX winsup was just not going to
>work, at least not in my life time.

"cvs update -D" should work ok and may be a little less comprehensive.

>My computer is just not fast enough and it "seems" like the old dll is
>persistent in memory after I copy a new one to /bin and run it - Is
>this possible?  Is there a way to eject the old dll other than reboot?

???  If using newer dlls required rebooting, we'd still be at B16.  I do
this all of the time without rebooting.  Usually, if you can copy the
DLL to "/bin", there is no previous version of /bin/cygwin1.dll running.

Check out the task manager, however, and see if there are cygwin processes
running.

>Anyway, I updated my cvs and removed tty from environment which seems to
>help alot.  I built the latest cvs using 1.1.8 dll and the following error
>was found by the test suite

Minor nit:  the cvs version is 1.3.0.

>devzero.c test fails at approx line 75 (mmap) with "address out of bounds"
>
> fd = open("/dev/zero", O_RDWR);
>  v = (char *)mmap(0, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
>  if (v == (char *)-1)
>    {
>      fprintf(stderr, "mmap r/w /dev/zero failed\n");
>      perror("The error was");
>      exit(1);
>    }
>
>I tried to tracing it but Gdb just "spat the dummy" and used up all 500M of
>my pagefile.

IMO, if you are going to be doing cygwin development you really do need
to have a working gdb.  One thing that I do is copy a known working DLL
built with "configure --enable-debugging" into a directory with a known
working gdb.  I use that to debug any suspect cygwin problems.  It
sounds like your DLL just isn't working right for some reason.  I avoid
using the tcl/tk stuff and always invoke gdb with -nw, to minimize the
amount of overhead and potential for problems.

Anyone who is serious about debugging cygwin should spend some time setting
up a debug environment that works.  Commands that you'll probably need are:

run
bt
info threads
thread
bp
display
print

You can, of course, type "help blah" to get help on the blah command in gdb.

Btw, the reason for the --enable-debugging switch is to build a cygwin1.dll
which timestamps all of its shared memory stuff.  This allows two versions
of cygwin to be running on the system at the same time.  Maybe this will
also solve your "persistent dll" problem as well.  The --enable-debugging
also turns on lots of internal consistency checks in cygwin.

cgf