Failure bootstrapping Emacs (Cygwin)

Failure bootstrapping Emacs (Cygwin)

[Angelo Graziosi]

Current trunk fails in this waY:

[...]
term.o: In function `dissociate_if_controlling_tty':
/work/emacs/src/term.c:3216: undefined reference to `_EMACS_GET_TTY_PGRP'
emacs.o: In function `shut_down_emacs':
/work/emacs/src/emacs.c:2031: undefined reference to `_EMACS_GET_TTY_PGRP'
callproc.o: In function `child_setup':
/work/emacs/src/callproc.c:1257: undefined reference to 
`_EMACS_SET_TTY_PGRP'
collect2: ld returned 1 exit status
make[1]: *** [temacs.exe] Error 1
make[1]: Leaving directory `/work/build/src'
make: *** [src] Error 2

This does not happen with trunk of a few hours before.

Perhaps this changes are the cause:

2008-07-31  Dan Nicolaescu  <xxx@xxx>

	* bitmaps/README:
	* xfns.c:
	* termcap.c:
	* term.c:         <==
	* syswait.h:
	* systty.h:
	* systime.h:
         [...]

Cheers,
    Angelo.

Re: Failure bootstrapping Emacs (Cygwin)

[Angelo Graziosi]

Angelo Graziosi ha scritto:
> Current trunk fails in this waY:
> 
> [...]
> term.o: In function `dissociate_if_controlling_tty':
> /work/emacs/src/term.c:3216: undefined reference to `_EMACS_GET_TTY_PGRP'
> emacs.o: In function `shut_down_emacs':
> /work/emacs/src/emacs.c:2031: undefined reference to `_EMACS_GET_TTY_PGRP'
> callproc.o: In function `child_setup':
> /work/emacs/src/callproc.c:1257: undefined reference to 
> `_EMACS_SET_TTY_PGRP'
> collect2: ld returned 1 exit status
> make[1]: *** [temacs.exe] Error 1
> make[1]: Leaving directory `/work/build/src'
> make: *** [src] Error 2
> 
> This does not happen with trunk of a few hours before.
> 


> Perhaps this changes are the cause:
> 
> 2008-07-31  Dan Nicolaescu  <xxx@xxx>
> 
>     * bitmaps/README:
>     * xfns.c:
>     * termcap.c:
>     * term.c:         <==
>     * syswait.h:
>     * systty.h:
>     * systime.h:
>         [...]
> 
^^^^^^^ wrong ! ^^^^^^^^^^^^^^

This is the cause:

2008-07-30  Dan Nicolaescu  <xxxx@xxxx>

         * systty.h (sensemode): Remove empty #if.  Remove reference to
         BSD_TERMIOS, unused.

Restoring to systty.h:

#if defined (HAVE_TERMIOS) && ! defined (BSD_TERMIOS) 	
	  	
#define EMACS_GET_TTY_PGRP(fd, pgid) (*(pgid) = tcgetpgrp ((fd))) 	
#define EMACS_SET_TTY_PGRP(fd, pgid) (tcsetpgrp ((fd), *(pgid))) 	
	  	
#else
...

#endif /*BSD_TERMIOS*/

works! i.e. applying:

$ cat /tmp/systty.h.diff
--- systty.h.orig       2008-07-31 18:07:05.000000000 +0200
+++ systty.h    2008-07-31 18:16:28.109375000 +0200
@@ -188,12 +188,20 @@

  #ifdef EMACS_HAVE_TTY_PGRP

+#if defined (HAVE_TERMIOS) && ! defined (BSD_TERMIOS)
+
+#define EMACS_GET_TTY_PGRP(fd, pgid) (*(pgid) = tcgetpgrp ((fd)))
+#define EMACS_SET_TTY_PGRP(fd, pgid) (tcsetpgrp ((fd), *(pgid)))
+
+#else
+
  #ifdef TIOCSPGRP

  #define EMACS_GET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCGPGRP, (pgid)))
  #define EMACS_SET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCSPGRP, (pgid)))

  #endif /* TIOCSPGRP */
+#endif /*BSD_TERMIOS*/

  #else /* not EMACS_SET_TTY_PGRP */

> Cheers,
>    Angelo.
> 

Re: Failure bootstrapping Emacs (Cygwin)

[Angelo Graziosi]

Angelo Graziosi ha scritto:

> ...
> This is the cause:
> 
> 2008-07-30  Dan Nicolaescu  <xxxx@xxxx>
> 
>         * systty.h (sensemode): Remove empty #if.  Remove reference to
>         BSD_TERMIOS, unused.
> 
> Restoring to systty.h:
> 
> #if defined (HAVE_TERMIOS) && ! defined (BSD_TERMIOS)    
>          
> #define EMACS_GET_TTY_PGRP(fd, pgid) (*(pgid) = tcgetpgrp ((fd)))    
> #define EMACS_SET_TTY_PGRP(fd, pgid) (tcsetpgrp ((fd), *(pgid)))    
>          
> #else
> ...
> 
> #endif /*BSD_TERMIOS*/
> 
> works! i.e. applying:
> 
> $ cat /tmp/systty.h.diff
> --- systty.h.orig       2008-07-31 18:07:05.000000000 +0200
> +++ systty.h    2008-07-31 18:16:28.109375000 +0200
> @@ -188,12 +188,20 @@
> 
>  #ifdef EMACS_HAVE_TTY_PGRP
> 
> +#if defined (HAVE_TERMIOS) && ! defined (BSD_TERMIOS)
> +
> +#define EMACS_GET_TTY_PGRP(fd, pgid) (*(pgid) = tcgetpgrp ((fd)))
> +#define EMACS_SET_TTY_PGRP(fd, pgid) (tcsetpgrp ((fd), *(pgid)))
> +
> +#else
> +
>  #ifdef TIOCSPGRP
> 
>  #define EMACS_GET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCGPGRP, (pgid)))
>  #define EMACS_SET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCSPGRP, (pgid)))
> 
>  #endif /* TIOCSPGRP */
> +#endif /*BSD_TERMIOS*/
> 
>  #else /* not EMACS_SET_TTY_PGRP */
> 

or:

$ cat /work/systty.h.diff
--- systty.h.orig       2008-07-31 16:13:42.000000000 +0200
+++ systty.h    2008-07-31 18:43:08.625000000 +0200
@@ -151,12 +151,20 @@

  #ifdef EMACS_HAVE_TTY_PGRP

+#if defined (HAVE_TERMIOS)
+
+#define EMACS_GET_TTY_PGRP(fd, pgid) (*(pgid) = tcgetpgrp ((fd)))
+#define EMACS_SET_TTY_PGRP(fd, pgid) (tcsetpgrp ((fd), *(pgid)))
+
+#else
+
  #ifdef TIOCSPGRP

  #define EMACS_GET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCGPGRP, (pgid)))
  #define EMACS_SET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCSPGRP, (pgid)))

  #endif /* TIOCSPGRP */
+#endif /* HAVE_TERMIOS */

  #else /* not EMACS_SET_TTY_PGRP */


>> Cheers,
>>    Angelo.
>>
> 
> 

Re: Failure bootstrapping Emacs (Cygwin)

[Dan Nicolaescu]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

  > Angelo Graziosi ha scritto:
  > > Current trunk fails in this waY:
  > >
  > > [...]
  > > term.o: In function `dissociate_if_controlling_tty':
  > > /work/emacs/src/term.c:3216: undefined reference to `_EMACS_GET_TTY_PGRP'
  > > emacs.o: In function `shut_down_emacs':
  > > /work/emacs/src/emacs.c:2031: undefined reference to `_EMACS_GET_TTY_PGRP'
  > > callproc.o: In function `child_setup':
  > > /work/emacs/src/callproc.c:1257: undefined reference to
  > > _EMACS_SET_TTY_PGRP'
  > > collect2: ld returned 1 exit status
  > > make[1]: *** [temacs.exe] Error 1
  > > make[1]: Leaving directory `/work/build/src'
  > > make: *** [src] Error 2
  > >
  > > This does not happen with trunk of a few hours before.
  > >
  > 
  > 
  > > Perhaps this changes are the cause:
  > >
  > > 2008-07-31  Dan Nicolaescu  <xxx@xxx>
  > >
  > >     * bitmaps/README:
  > >     * xfns.c:
  > >     * termcap.c:
  > >     * term.c:         <==
  > >     * syswait.h:
  > >     * systty.h:
  > >     * systime.h:
  > >         [...]
  > >
  > ^^^^^^^ wrong ! ^^^^^^^^^^^^^^
  > 
  > This is the cause:
  > 
  > 2008-07-30  Dan Nicolaescu  <xxxx@xxxx>
  > 
  >         * systty.h (sensemode): Remove empty #if.  Remove reference to
  >         BSD_TERMIOS, unused.
  > 
  > Restoring to systty.h:
  > 
  > #if defined (HAVE_TERMIOS) && ! defined (BSD_TERMIOS) 	
  > 	  	

This looks plausible, and the change had a logic error:
&& ! defined (BSD_TERMIOS) when BSD_TERMIOS is never defined is
equivalent to
#if defined (HAVE_TERMIOS)

not to #if 0 as the change assumed.

I'll check in a fix later today if nobody beats me to it.

Warning starting Emacs (was Re: Failure bootstrapping Emacs (Cygwin))

[Angelo Graziosi]

Dan Nicolaescu ha scritto:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>   > Angelo Graziosi ha scritto:
>   > > Current trunk fails in this waY:
>   > >
>   > > [...]
>   > > term.o: In function `dissociate_if_controlling_tty':
>   > > /work/emacs/src/term.c:3216: undefined reference to `_EMACS_GET_TTY_PGRP'
>   > > emacs.o: In function `shut_down_emacs':
>   > > /work/emacs/src/emacs.c:2031: undefined reference to `_EMACS_GET_TTY_PGRP'
>   > > callproc.o: In function `child_setup':
>   > > /work/emacs/src/callproc.c:1257: undefined reference to
>   > > _EMACS_SET_TTY_PGRP'
>   > > collect2: ld returned 1 exit status
>   > > make[1]: *** [temacs.exe] Error 1
>   > > make[1]: Leaving directory `/work/build/src'
>   > > make: *** [src] Error 2
>   > >
>   > > This does not happen with trunk of a few hours before.
>   > >
>   > 
>   > 
>   > > Perhaps this changes are the cause:
>   > >
>   > > 2008-07-31  Dan Nicolaescu  <xxx@xxx>
>   > >
>   > >     * bitmaps/README:
>   > >     * xfns.c:
>   > >     * termcap.c:
>   > >     * term.c:         <==
>   > >     * syswait.h:
>   > >     * systty.h:
>   > >     * systime.h:
>   > >         [...]
>   > >
>   > ^^^^^^^ wrong ! ^^^^^^^^^^^^^^
>   > 
>   > This is the cause:
>   > 
>   > 2008-07-30  Dan Nicolaescu  <xxxx@xxxx>
>   > 
>   >         * systty.h (sensemode): Remove empty #if.  Remove reference to
>   >         BSD_TERMIOS, unused.
>   > 
>   > Restoring to systty.h:
>   > 
>   > #if defined (HAVE_TERMIOS) && ! defined (BSD_TERMIOS) 	
>   > 	  	
> 
> This looks plausible, and the change had a logic error:
> && ! defined (BSD_TERMIOS) when BSD_TERMIOS is never defined is
> equivalent to
> #if defined (HAVE_TERMIOS)
> 
> not to #if 0 as the change assumed.
> 
> I'll check in a fix later today if nobody beats me to it.

For the sake of completeness, I have applied this:

$ cat downloads/emacs.ports/systty.h.diff
--- systty.h.orig       2008-07-31 16:13:42.000000000 +0200
+++ systty.h    2008-07-31 18:43:08.625000000 +0200
@@ -151,12 +151,20 @@

  #ifdef EMACS_HAVE_TTY_PGRP

+#if defined (HAVE_TERMIOS)
+
+#define EMACS_GET_TTY_PGRP(fd, pgid) (*(pgid) = tcgetpgrp ((fd)))
+#define EMACS_SET_TTY_PGRP(fd, pgid) (tcsetpgrp ((fd), *(pgid)))
+
+#else
+
  #ifdef TIOCSPGRP

  #define EMACS_GET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCGPGRP, (pgid)))
  #define EMACS_SET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCSPGRP, (pgid)))

  #endif /* TIOCSPGRP */
+#endif /* HAVE_TERMIOS */

  #else /* not EMACS_SET_TTY_PGRP */

with which current trunk bootstraps, but starting Emacs it opens a 
buffer called Warnings in which it prints:

<beep>
Emergency (alloc): Warning: past 95% of memory limit

Perhaps, here, we have some other problems...

    Angelo.

Re: Warning starting Emacs (Cygwin)

[Angelo Graziosi]

I wrote:

> starting Emacs it opens a buffer called Warnings in which it prints:
> 
> <beep>
> Emergency (alloc): Warning: past 95% of memory limit


I think there is some new problem.

Downloading cvs-trunk with -D "20080730 17:14" bootstraps and works 
without warning.

Instead -D "20080730 17:15" fails to bootstrap, but it is solved with 
the patch discussed here [1] or using systty.h from "20080730 17:14".

After solving the bootstrap problem the warning shows up.

Below [2] there are the differences between "20080730 17:14" and 
"20080730 17:15" and it seem hard to think that the patch is the cause 
of the warning.

Perhaps the new handling (in 20080730 17:15) of getrlimit?

Cheers,
    Angelo.

---
[1] http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00014.html

[2] differences:

diff -Naur emacs-20080730-1714/ChangeLog emacs-20080730-1715/ChangeLog
--- emacs-20080730-1714/ChangeLog	2008-08-01 13:59:35.000000000 +0200
+++ emacs-20080730-1715/ChangeLog	2008-08-01 14:03:00.000000000 +0200
@@ -1,3 +1,7 @@
+2008-07-30  Dan Nicolaescu  <dann@ics.uci.edu>
+
+	* configure.in (DO_BLOCK_INPUT): Remove, unused.
+
  2008-07-29  Chong Yidong  <cyd@stupidchicken.com>

  	* info/dir (File): Add mairix-el.
diff -Naur emacs-20080730-1714/configure.in emacs-20080730-1715/configure.in
--- emacs-20080730-1714/configure.in	2008-08-01 13:59:36.000000000 +0200
+++ emacs-20080730-1715/configure.in	2008-08-01 14:03:00.000000000 +0200
@@ -2561,9 +2561,6 @@
  /* Turned on June 1996 supposing nobody will mind it.  */
  #define AMPERSAND_FULL_NAME

-/* We have blockinput.h.  */
-#define DO_BLOCK_INPUT
-
  /* Define HAVE_SOUND if we have sound support.  We know it works
     and compiles only on the specified platforms.   For others,
     it probably doesn't make sense to try.  */
diff -Naur emacs-20080730-1714/src/ChangeLog 
emacs-20080730-1715/src/ChangeLog
--- emacs-20080730-1714/src/ChangeLog	2008-08-01 13:59:56.000000000 +0200
+++ emacs-20080730-1715/src/ChangeLog	2008-08-01 14:03:12.000000000 +0200
@@ -1,3 +1,13 @@
+2008-07-30  Dan Nicolaescu  <dann@ics.uci.edu>
+
+	* systty.h (sensemode): Remove empty #if.  Remove reference to
+	BSD_TERMIOS, unused.
+
+	* sysdep.c: Remove reference to DGUX.
+	(closedir): Remove reference to BROKEN_CLOSEDIR, unused.
+
+	* config.in: Regenerate.
+
  2008-07-30  Jason Rumney  <jasonr@gnu.org>

          * w32uniscribe.c (uniscribe_encode_char): Fix glyph buffer size.
diff -Naur emacs-20080730-1714/src/config.in 
emacs-20080730-1715/src/config.in
--- emacs-20080730-1714/src/config.in	2008-08-01 13:59:57.000000000 +0200
+++ emacs-20080730-1715/src/config.in	2008-08-01 14:03:12.000000000 +0200
@@ -221,6 +221,9 @@
  /* Define to 1 if you have the `getpt' function. */
  #undef HAVE_GETPT

+/* Define to 1 if you have the `getrlimit' function. */
+#undef HAVE_GETRLIMIT
+
  /* Define to 1 if you have the `getrusage' function. */
  #undef HAVE_GETRUSAGE

@@ -996,9 +999,6 @@
  /* Turned on June 1996 supposing nobody will mind it.  */
  #define AMPERSAND_FULL_NAME

-/* We have blockinput.h.  */
-#define DO_BLOCK_INPUT
-
  /* Define HAVE_SOUND if we have sound support.  We know it works
     and compiles only on the specified platforms.   For others,
     it probably doesn't make sense to try.  */
diff -Naur emacs-20080730-1714/src/sysdep.c emacs-20080730-1715/src/sysdep.c
--- emacs-20080730-1714/src/sysdep.c	2008-08-01 14:00:01.000000000 +0200
+++ emacs-20080730-1715/src/sysdep.c	2008-08-01 14:03:12.000000000 +0200
@@ -1213,7 +1213,7 @@
     but if so, this does no harm,
     and using the same name avoids wasting the other one's space.  */

-#if defined (USG) || defined (DGUX)
+#if defined (USG)
  unsigned char _sobuf[BUFSIZ+8];
  #else
  char _sobuf[BUFSIZ];
@@ -3273,11 +3273,10 @@

  #include <dirent.h>

-#if defined (BROKEN_CLOSEDIR) || !defined (HAVE_CLOSEDIR)
+#if !defined (HAVE_CLOSEDIR)

  int
-closedir (dirp)
-     register DIR *dirp;              /* stream from opendir */
+closedir (DIR *dirp /* stream from opendir */)
  {
    int rtnval;

@@ -3293,7 +3292,7 @@

    return rtnval;
  }
-#endif /* BROKEN_CLOSEDIR or not HAVE_CLOSEDIR */
+#endif /* not HAVE_CLOSEDIR */
  #endif /* SYSV_SYSTEM_DIR */

  #ifdef NONSYSTEM_DIR_LIBRARY
diff -Naur emacs-20080730-1714/src/systty.h emacs-20080730-1715/src/systty.h
--- emacs-20080730-1714/src/systty.h	2008-08-01 14:00:01.000000000 +0200
+++ emacs-20080730-1715/src/systty.h	2008-08-01 14:03:13.000000000 +0200
@@ -174,42 +174,34 @@
     EMACS_SET_TTY_PGRP(int FD, int *PGID) sets the terminal FD's
     current process group to *PGID.  Return -1 if there is an error.  */

-#ifdef HPUX
  /* HPUX tty process group stuff doesn't work, says the anonymous voice
     from the past.  */
-#else
+#ifndef HPUX
  #ifdef TIOCGPGRP
  #define EMACS_HAVE_TTY_PGRP
  #else
  #ifdef HAVE_TERMIOS
  #define EMACS_HAVE_TTY_PGRP
-#endif
-#endif
-#endif
+#endif /* HAVE_TERMIOS */
+#endif /* TIOCGPGRP */
+#endif /* not HPUX */

  #ifdef EMACS_HAVE_TTY_PGRP

-#if defined (HAVE_TERMIOS) && ! defined (BSD_TERMIOS)
-
-#define EMACS_GET_TTY_PGRP(fd, pgid) (*(pgid) = tcgetpgrp ((fd)))
-#define EMACS_SET_TTY_PGRP(fd, pgid) (tcsetpgrp ((fd), *(pgid)))
-
-#else
  #ifdef TIOCSPGRP

  #define EMACS_GET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCGPGRP, (pgid)))
  #define EMACS_SET_TTY_PGRP(fd, pgid) (ioctl ((fd), TIOCSPGRP, (pgid)))

-#endif
-#endif
+#endif /* TIOCSPGRP */

-#else
+#else /* not EMACS_SET_TTY_PGRP */

  /* Just ignore this for now and hope for the best */
  #define EMACS_GET_TTY_PGRP(fd, pgid) 0
  #define EMACS_SET_TTY_PGRP(fd, pgif) 0

-#endif
+#endif /* not EMACS_SET_TTY_PGRP */

  /* EMACS_GETPGRP (arg) returns the process group of the process.  */

Re: Warning starting Emacs (Cygwin)

[Dan Nicolaescu]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

  > I wrote:
  > 
  > > starting Emacs it opens a buffer called Warnings in which it prints:
  > >
  > > <beep>
  > > Emergency (alloc): Warning: past 95% of memory limit
  > 
  > 
  > I think there is some new problem.
  > 
  > Downloading cvs-trunk with -D "20080730 17:14" bootstraps and works
  > without warning.
  > 
  > Instead -D "20080730 17:15" fails to bootstrap, but it is solved with
  > the patch discussed here [1] or using systty.h from "20080730 17:14".
  > 
  > After solving the bootstrap problem the warning shows up.
  > 
  > Below [2] there are the differences between "20080730 17:14" and
  > "20080730 17:15" and it seem hard to think that the patch is the cause
  > of the warning.
  > 
  > Perhaps the new handling (in 20080730 17:15) of getrlimit?

Can you please try to verify that?  
Doing a "cvs update" and removing #undef HAVE_GETRLIMIT from
config.in should be enough.

Re: Warning starting Emacs (Cygwin)

[Angelo Graziosi]

Dan Nicolaescu ha scritto:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>   > I wrote:
>   > 
>   > > starting Emacs it opens a buffer called Warnings in which it prints:
>   > >
>   > > <beep>
>   > > Emergency (alloc): Warning: past 95% of memory limit
>   > 
>   > 
>   > I think there is some new problem.
>   > 
>   > Downloading cvs-trunk with -D "20080730 17:14" bootstraps and works
>   > without warning.
>   > 
>   > Instead -D "20080730 17:15" fails to bootstrap, but it is solved with
>   > the patch discussed here [1] or using systty.h from "20080730 17:14".
>   > 
>   > After solving the bootstrap problem the warning shows up.
>   > 
>   > Below [2] there are the differences between "20080730 17:14" and
>   > "20080730 17:15" and it seem hard to think that the patch is the cause
>   > of the warning.
>   > 
>   > Perhaps the new handling (in 20080730 17:15) of getrlimit?
> 
> Can you please try to verify that?  
> Doing a "cvs update" and removing #undef HAVE_GETRLIMIT from
> config.in should be enough.

Indeed! That workaround fixes the warning. Now Emacs starts normally.

Perhaps, now, the fix should be applied to trunk...


Thanks,
    Angelo.

Re: Warning starting Emacs (Cygwin)

[Dan Nicolaescu]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

  > Dan Nicolaescu ha scritto:
  > > Angelo Graziosi <angelo.graziosi@alice.it> writes:
  > >
  > >   > I wrote:
  > >   >   > > starting Emacs it opens a buffer called Warnings in which
  > > it prints:
  > >   > >
  > >   > > <beep>
  > >   > > Emergency (alloc): Warning: past 95% of memory limit
  > >   >   >   > I think there is some new problem.
  > >   >   > Downloading cvs-trunk with -D "20080730 17:14" bootstraps
  > > and works
  > >   > without warning.
  > >   >   > Instead -D "20080730 17:15" fails to bootstrap, but it is
  > > solved with
  > >   > the patch discussed here [1] or using systty.h from "20080730 17:14".
  > >   >   > After solving the bootstrap problem the warning shows up.
  > >   >   > Below [2] there are the differences between "20080730 17:14"
  > > and
  > >   > "20080730 17:15" and it seem hard to think that the patch is the cause
  > >   > of the warning.
  > >   >   > Perhaps the new handling (in 20080730 17:15) of getrlimit?
  > >
  > > Can you please try to verify that?  Doing a "cvs update" and
  > > removing #undef HAVE_GETRLIMIT from
  > > config.in should be enough.
  > 
  > Indeed! That workaround fixes the warning. Now Emacs starts normally.

Good, thanks for checking.

  > Perhaps, now, the fix should be applied to trunk...

Well, that would not be a good idea.  The HAVE_GETRLIMIT check was added
for a reason, and it's very likely correct.  It seems that it has some
side effect on Cygwin.  It would be great if you could debug that.

Re: Warning starting Emacs (Cygwin)

[Angelo Graziosi]

Dan Nicolaescu ha scritto:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>   > Dan Nicolaescu ha scritto:
>   > > Angelo Graziosi <angelo.graziosi@alice.it> writes:
>   > >
>   > >   > I wrote:
>   > >   >   > > starting Emacs it opens a buffer called Warnings in which
>   > > it prints:
>   > >   > >
>   > >   > > <beep>
>   > >   > > Emergency (alloc): Warning: past 95% of memory limit
>   > >   >   >   > I think there is some new problem.
>   > >   >   > Downloading cvs-trunk with -D "20080730 17:14" bootstraps
>   > > and works
>   > >   > without warning.
>   > >   >   > Instead -D "20080730 17:15" fails to bootstrap, but it is
>   > > solved with
>   > >   > the patch discussed here [1] or using systty.h from "20080730 17:14".
>   > >   >   > After solving the bootstrap problem the warning shows up.
>   > >   >   > Below [2] there are the differences between "20080730 17:14"
>   > > and
>   > >   > "20080730 17:15" and it seem hard to think that the patch is the cause
>   > >   > of the warning.
>   > >   >   > Perhaps the new handling (in 20080730 17:15) of getrlimit?
>   > >
>   > > Can you please try to verify that?  Doing a "cvs update" and
>   > > removing #undef HAVE_GETRLIMIT from
>   > > config.in should be enough.
>   > 
>   > Indeed! That workaround fixes the warning. Now Emacs starts normally.
> 
> Good, thanks for checking.
> 
>   > Perhaps, now, the fix should be applied to trunk...
> 
> Well, that would not be a good idea.  The HAVE_GETRLIMIT check was added
> for a reason, and it's very likely correct.  It seems that it has some
> side effect on Cygwin.  It would be great if you could debug that.

You should consider that, as I pointed out many times on this list, I am 
not very able to use GDB... and I do not know almost anything on Emacs 
code etc...

So if you have simple suggestions I will try.


Cheers,
    Angelo.

Re: Warning starting Emacs (Cygwin)

[Dan Nicolaescu]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

  > So if you have simple suggestions I will try.

Thanks.

I don't know anything about the code in question, and it looks like it
hasn't been touched in a while...

But please look at src/vm-limit.c:check_memory_limits and see why it
prints that memory full message.  It's not too many lines of code.

Re: Warning starting Emacs (Cygwin)

[Angelo Graziosi]

Dan Nicolaescu ha scritto:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>   > So if you have simple suggestions I will try.
> 
> Thanks.
> 
> I don't know anything about the code in question, and it looks like it
> hasn't been touched in a while...
> 
> But please look at src/vm-limit.c:check_memory_limits and see why it
> prints that memory full message.  It's not too many lines of code.

This is what I have done.

The first thing has been to verify what code is executed in
'check_memory_limits'.

Using

#ifdef HAVE_GETRLIMIT
   ...
   dataa_size = rlimit.rlim_cur; /* instead of data_size */

#else /* not HAVE_GETRLIMIT */

   ...
   dataaa_size = (char *) cp - (char *) data_space_start;

#endif /* not HAVE_GETRLIMIT */


the compiler fails on:

1) 'dataa_size', when src/config.in has #undef HAVE_GETRLIMIT (in
    current CVS trunk) and Emacs warns starting;

2) 'dataaa_size', when I remove #undef HAVE_GETRLIMIT (previous CVS)
     and Emacs starts normally.

So the warning results when this code is executed:

#ifdef HAVE_GETRLIMIT
   struct rlimit rlimit;

   getrlimit (RLIMIT_AS, &rlimit);

   if (RLIM_INFINITY == rlimit.rlim_max)
     return;

   /* This is a nonsensical case, but it happens -- rms.  */
   if (rlimit.rlim_cur > rlimit.rlim_max)
     return;

   five_percent = rlimit.rlim_max / 20;
   data_size = rlimit.rlim_cur;
#else /* not HAVE_GETRLIMIT */
...
#endif /* not HAVE_GETRLIMIT */

...
if (data_size > five_percent * 19)
     new_warnlevel = warned_95;

with 'data_size > five_percent * 19' (note 5%*19 == 95%).

Since the code is very simple, the only thing I can think is that
'getrlimit' returns wrong values in struct 'rlimit'

The obvious thing to do is to know the values of:

data_size, five_percent, rlimit.rlim_cur, rlimit.rlim_max

so I have tried to add

...
five_percent = rlimit.rlim_max / 20;
data_size = rlimit.rlim_cur;

printf("have getrlimit %lu, %lu %lu %lu\n",
           data_size,five_percent,rlimit.rlim_cur,rlimit.rlim_max);

and rebuild... but 'temacs' stack dumps...; perhaps a known problem
since unicode branch was merged to trunk and solved in 'sheap.c 'with

-#define STATIC_HEAP_SIZE       (12 * 1024 * 1024)
+#define STATIC_HEAP_SIZE       (25 * 1024 * 1024)

In this case I have tried up to (45 * 1024 * 1024) without success.

Then I have tried with GDB:

------------------------------------------
$ gdb build/src/emacs.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) break check_memory_limits
Breakpoint 1 at 0x56db96: file /work/emacs/src/vm-limit.c, line 159.
(gdb) run -Q
Starting program: /work/build/src/emacs.exe -Q
[New thread 556.0xa0c]
[New thread 556.0xcc4]
[New thread 556.0x8d8]
[New thread 556.0xdac]
[New thread 556.0xb80]
[New thread 556.0xe00]
[New thread 556.0x1b4]
<blinking cursor>
------------------------------------------

GDB does not stop on 'check_memory_limits' which is executed with the
warning, and it does not return the prompt '(gdb)'.

At the end I have tried this simple test case, which is 'out context'
(so it could be not meaningful), but it seems to return wrong values:

-----------------------------------------------
$ cat test_printf.c
#include <stdio.h>
#include <sys/resource.h>

int main()
{
    struct rlimit rlimit;

    unsigned long five_percent;
    unsigned long data_size;

    getrlimit (RLIMIT_AS, &rlimit);

    if (RLIM_INFINITY == rlimit.rlim_max)
       return 1;

    /* This is a nonsensical case, but it happens -- rms.  */
    if (rlimit.rlim_cur > rlimit.rlim_max)
       return 2;

    five_percent = rlimit.rlim_max / 20;
    data_size = rlimit.rlim_cur;

    printf("have getrlimit %lu, %lu %lu %lu\n",
           data_size,five_percent,rlimit.rlim_cur,rlimit.rlim_max);

    if (data_size > five_percent * 19)
       printf("past 95 percent of memory limit\n");

    return 0;
}

$ gcc -o test_printf test_printf.c

$ ./test_printf
have getrlimit 2147483648, 107374182 2147483648 2147483648
past 95 percent of memory limit

-----------------------------------------------


Cheers,
    Angelo.

---
... e la terra ritornata alla forma di nebulosa errerà nei cieli priva
di parassiti e di malattie.
.
                          Italo SVEVO, "La coscienza di Zeno"

Re: Warning starting Emacs (Cygwin)

[Angelo Graziosi]

Angelo Graziosi ha scritto:

> 
> At the end I have tried this simple test case, which is 'out context'
> (so it could be not meaningful), but it seems to return wrong values:
> 
> -----------------------------------------------
> $ cat test_printf.c
> #include <stdio.h>
> #include <sys/resource.h>
> 
> int main()
> {
>    struct rlimit rlimit;
> 
>    unsigned long five_percent;
>    unsigned long data_size;
> 
>    getrlimit (RLIMIT_AS, &rlimit);
> 
>    if (RLIM_INFINITY == rlimit.rlim_max)
>       return 1;
> 
>    /* This is a nonsensical case, but it happens -- rms.  */
>    if (rlimit.rlim_cur > rlimit.rlim_max)
>       return 2;
> 
>    five_percent = rlimit.rlim_max / 20;
>    data_size = rlimit.rlim_cur;
> 
>    printf("have getrlimit %lu, %lu %lu %lu\n",
>           data_size,five_percent,rlimit.rlim_cur,rlimit.rlim_max);
> 
>    if (data_size > five_percent * 19)
>       printf("past 95 percent of memory limit\n");
> 
>    return 0;
> }
> 
> $ gcc -o test_printf test_printf.c
> 
> $ ./test_printf
> have getrlimit 2147483648, 107374182 2147483648 2147483648
> past 95 percent of memory limit
> 
> -----------------------------------------------
> 

On GNU/Linux (on which there is NOT warning) the test case retruns 1, 
i.e. it executes


if (RLIM_INFINITY == rlimit.rlim_max)
        return 1;

with RLIM_INFINITY == rlimit.rlim_max == 4294967295

Instead on Cygwin

RLIM_INFINITY == 4294967295

rlimit.rlim_max == 2147483648


> 
> Cheers,
>    Angelo.
> 
> ---
> ... e la terra ritornata alla forma di nebulosa errerà nei cieli priva
> di parassiti e di malattie.
> .
>                          Italo SVEVO, "La coscienza di Zeno"
> 

Re: Warning starting Emacs (Cygwin)

[Dan Nicolaescu]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

  > Dan Nicolaescu ha scritto:
  > > Angelo Graziosi <angelo.graziosi@alice.it> writes:
  > >
  > >   > So if you have simple suggestions I will try.
  > >
  > > Thanks.
  > >
  > > I don't know anything about the code in question, and it looks like it
  > > hasn't been touched in a while...
  > >
  > > But please look at src/vm-limit.c:check_memory_limits and see why it
  > > prints that memory full message.  It's not too many lines of code.
  > 
  > This is what I have done.

Thanks for doing this!

  > The first thing has been to verify what code is executed in
  > 'check_memory_limits'.
  > 
  > Using
  > 
  > #ifdef HAVE_GETRLIMIT
  >   ...
  >   dataa_size = rlimit.rlim_cur; /* instead of data_size */
  > 
  > #else /* not HAVE_GETRLIMIT */
  > 
  >   ...
  >   dataaa_size = (char *) cp - (char *) data_space_start;
  > 
  > #endif /* not HAVE_GETRLIMIT */
  > 
  > 
  > the compiler fails on:

In the future you might want to consider adding -save-temps to the gcc
command line, it keeps a copy of the preprocessed source in vc-limit.i,
and you can do a diff between the two preprocessed versions.  This avoids
the need to edit the file.


  > So the warning results when this code is executed:
  > 
  > #ifdef HAVE_GETRLIMIT
  >   struct rlimit rlimit;
  > 
  >   getrlimit (RLIMIT_AS, &rlimit);
  > 
  >   if (RLIM_INFINITY == rlimit.rlim_max)
  >     return;
  > 
  >   /* This is a nonsensical case, but it happens -- rms.  */
  >   if (rlimit.rlim_cur > rlimit.rlim_max)
  >     return;
  > 
  >   five_percent = rlimit.rlim_max / 20;
  >   data_size = rlimit.rlim_cur;
  > #else /* not HAVE_GETRLIMIT */
  > ...
  > #endif /* not HAVE_GETRLIMIT */
  > 
  > ...
  > if (data_size > five_percent * 19)
  >     new_warnlevel = warned_95;
  > 
  > with 'data_size > five_percent * 19' (note 5%*19 == 95%).
  > 
  > Since the code is very simple, the only thing I can think is that
  > 'getrlimit' returns wrong values in struct 'rlimit'
  > 
  > The obvious thing to do is to know the values of:
  > 
  > data_size, five_percent, rlimit.rlim_cur, rlimit.rlim_max
  > 
  > so I have tried to add

Unfortunately none of these ring a bell to me.  Yidong I assume this
code is the reason you added the HAVE_GETRLIMIT autoconf check, can you
guess what can be wrong here?

Re: Warning starting Emacs (Cygwin)

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Unfortunately none of these ring a bell to me.  Yidong I assume this
> code is the reason you added the HAVE_GETRLIMIT autoconf check, can you
> guess what can be wrong here?

The reason I added the getrlimit check was because of the bug reported
here (bug#86):

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=86

>  src/vm-limit.c has #ifdef HAVE_GETRLIMIT...#else...#endif sections
>  (i.e. line 36 onwards and line 158 onwards) and yet the configure
>  script never tests for getrlimit() and hence config.h never has any
>  HAVE_GETRLIMIT definition. Yes, configure does test for setrlimit()
>  and sets HAVE_SETRLIMIT though!

Apparently, due to an oversight in the configure script, the
HAVE_GETRLIMIT code was always turned off, even though the code had
already been written.

Could it be that getrlimit is buggy on Cygwin?  Maybe we could work
around this by turning off HAVE_GETRLIMIT on that platform :-P

Re: Warning starting Emacs (Cygwin)

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Unfortunately none of these ring a bell to me.  Yidong I assume this
  > > code is the reason you added the HAVE_GETRLIMIT autoconf check, can you
  > > guess what can be wrong here?
  > 
  > The reason I added the getrlimit check was because of the bug reported
  > here (bug#86):

The check is very likely fine, I was hoping you understand the code the
macro guards...  Please see Angelo's messages, he gives a lot of details
that might ring a bell.

Re: Warning starting Emacs (Cygwin)

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sat, 02 Aug 2008 12:30:29 -0700
> Cc: emacs-devel@gnu.org, Angelo Graziosi <angelo.graziosi@alice.it>
> 
> Chong Yidong <cyd@stupidchicken.com> writes:
> 
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > Unfortunately none of these ring a bell to me.  Yidong I assume this
>   > > code is the reason you added the HAVE_GETRLIMIT autoconf check, can you
>   > > guess what can be wrong here?
>   > 
>   > The reason I added the getrlimit check was because of the bug reported
>   > here (bug#86):
> 
> The check is very likely fine, I was hoping you understand the code the
> macro guards...  Please see Angelo's messages, he gives a lot of details
> that might ring a bell.

It's quite clear from what Angelo wrote that Cygwin's getrlimit is not
a fully functional emulation.  Just to be sure, I looked into the
Cygwin sources and found this gem:

    extern "C" int
    getrlimit (int resource, struct rlimit *rlp)
    {

      [...]

      switch (resource)
	{
	[...]
	case RLIMIT_AS:
	  rlp->rlim_cur = 0x80000000UL;
	  rlp->rlim_max = 0x80000000UL;
	  break;

This obviously cannot work with vm-limit.c.

I think the test in configure should compare rlim_cur with rlim_max,
and if they are identical, deduce that getrlimit is non-functional and
not set HAVE_GETRLIMIT.

Re: Warning starting Emacs (Cygwin)

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> The check is very likely fine, I was hoping you understand the code
> the macro guards...  Please see Angelo's messages, he gives a lot of
> details that might ring a bell.

I don't understand the code in check_memory_limits is trying to do.
rlim_cur and rlim_max are the "soft limit" and "hard limit" for the
amount of memory the Emacs process can possibly occupy; so why are we
interested in comparing the two?  There's no guarantee that this has
anything to do with the amount of memory Emacs actually consumes.

(There's also a separate bug: the `cp' variable isn't initialized if
HAVE_GETRLIMIT is defined, even though it is used.)

In short, I think the code is simply based on a misunderstanding of
getrlimit.  The following patch should fix this confusion, by setting
data_size using morecore instead of rlimit.rlim_cur.

However, this raises the separate issue of bug#86, which is that the
real_morecore/__morecore hack causes crashes on HP/UX.  I think this
whole function should be wrapped in a `#if GNU_MALLOC ', at the very
least.  If we're using some unknown malloc implementation, just make it
a no-op.


*** trunk/src/vm-limit.c.~1.23.~	2008-05-14 03:49:59.000000000 -0400
--- trunk/src/vm-limit.c	2008-08-02 16:15:22.000000000 -0400
***************
*** 166,172 ****
      return;
  
    five_percent = rlimit.rlim_max / 20;
-   data_size = rlimit.rlim_cur;
  
  #else /* not HAVE_GETRLIMIT */
  
--- 166,171 ----
***************
*** 174,179 ****
--- 173,180 ----
      get_lim_data ();
    five_percent = lim_data / 20;
  
+ #endif /* not HAVE_GETRLIMIT */
+ 
    /* Find current end of memory and issue warning if getting near max */
  #ifdef REL_ALLOC
    if (real_morecore)
***************
*** 183,190 ****
    cp = (char *) (*__morecore) (0);
    data_size = (char *) cp - (char *) data_space_start;
  
- #endif /* not HAVE_GETRLIMIT */
- 
    if (!warn_function)
      return;
  
--- 184,189 ----

Re: Warning starting Emacs (Cygwin)

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> I don't understand the code in check_memory_limits is trying to do.
> rlim_cur and rlim_max are the "soft limit" and "hard limit" for the
> amount of memory the Emacs process can possibly occupy; so why are we
> interested in comparing the two?  There's no guarantee that this has
> anything to do with the amount of memory Emacs actually consumes.

Never mind, I take that back.  This was based on a misreading of the
getrlimit manpage.

So yeah, who Eli said.  (Though it might be easier to simply use a
cygwin conditional than what he suggested.)

Re: Warning starting Emacs (Cygwin)

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 02 Aug 2008 16:24:27 -0400
> Cc: Angelo Graziosi <angelo.graziosi@alice.it>, emacs-devel@gnu.org
> 
> So yeah, who Eli said.  (Though it might be easier to simply use a
> cygwin conditional than what he suggested.)

My suggestion has an advantage that if in the future the Cygwin
implementation changes for the better, Emacs will automatically turn
on usage of getrlimit for it.  But since I'm not going to do the job,
it's just a suggestion; whoever does it can choose to do it your way.

Re: Warning starting Emacs (Cygwin)

[Andreas Vögele]

Chong Yidong <cyd@stupidchicken.com> writes:

> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>> Unfortunately none of these ring a bell to me.  Yidong I assume this
>> code is the reason you added the HAVE_GETRLIMIT autoconf check, can you
>> guess what can be wrong here?
>
> The reason I added the getrlimit check was because of the bug reported
> here (bug#86):
>
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=86
>
>>  src/vm-limit.c has #ifdef HAVE_GETRLIMIT...#else...#endif sections
>>  (i.e. line 36 onwards and line 158 onwards) and yet the configure
>>  script never tests for getrlimit() and hence config.h never has any
>>  HAVE_GETRLIMIT definition. Yes, configure does test for setrlimit()
>>  and sets HAVE_SETRLIMIT though!
>
> Apparently, due to an oversight in the configure script, the
> HAVE_GETRLIMIT code was always turned off, even though the code had
> already been written.
>
> Could it be that getrlimit is buggy on Cygwin?  Maybe we could work
> around this by turning off HAVE_GETRLIMIT on that platform :-P

BTW, NetBSD, OpenBSD and DragonFly BSD do not define RLIMIT_AS, which is
used in the #ifdef HAVE_GETRLIMIT...#else...#endif section.

DragonFLY BSD defines RLIMIT_VMEM in sys/resource.h, but doesn't mention
this limit in the getrlimit manual page.

Re: Warning starting Emacs (Cygwin)

[Chong Yidong]

Does the latest CVS trunk, with Andreas Schwab's changes to vm-limit.c,
fix the problem on all these platforms?

Re: Warning starting Emacs (Cygwin)

[Angelo Graziosi]

Chong Yidong ha scritto:
> Does the latest CVS trunk, with Andreas Schwab's changes to vm-limit.c,
> fix the problem on all these platforms?

On Cygwin it seems to fix the problem. Emacs starts without warnings.

At the moment, I can't say if there are some other 'collateral' effects.


Thanks,
    Angelo.


---
E quindi uscimmo a riveder le stelle.
.
                   DANTE, Inferno, xxxiv 139

Re: Warning starting Emacs (Cygwin)

[Andreas Vögele]

Angelo Graziosi writes:

> Chong Yidong ha scritto:
>> Does the latest CVS trunk, with Andreas Schwab's changes to vm-limit.c,
>> fix the problem on all these platforms?
>
> On Cygwin it seems to fix the problem. Emacs starts without warnings.
>
> At the moment, I can't say if there are some other 'collateral' effects.

The latest CVS trunk builds and runs fine on OpenBSD.

Regards,
Andreas