GNU Emacs CVS HEAD: "nmake bootstrap" fails

GNU Emacs CVS HEAD: "nmake bootstrap" fails

[dhruva]

Hello,
 I am trying to build GNU Emacs (from CVS head) on W-XP using MSVC.
The build fails for:

cmd> configure --prefix=C:/GNU/emacs --with-msvc
cmd> nmake bootstrap
....
....
....
Loading language/chinese (source)...
Loading language/cyrillic (source)...
Loading language/indian (source)...
IO error reading c:/tmp/build/emacs/lisp/language/indian.el: Bad file descriptor

NMAKE : fatal error U1077: '"C:\tmp\build\emacs\src/obj-spd/i386/temacs.exe"' :
return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' :
return code '0x2'
Stop.


I am able to open the c:\tmp\build\emacs\lisp\language\indian.el file
in any of the editors and do not see anything wrong.

-dk

--
Dhruva Krishnamurthy
Proud GNU/FSF member: #1935

Re: GNU Emacs CVS HEAD:

[Eric Hanchrow]

dhruva <dklefty <at> gmail.com> writes:

> Loading language/indian (source)...
> IO error reading c:/tmp/build/emacs/lisp/language/indian.el: 
> Bad file descriptor

Thanks for reporting this.  I'm seeing essentially the same problem; the only
difference is that I use the mingw32 tools to build, instead of Microsoft's.

Re: GNU Emacs CVS HEAD:

[Kenichi Handa]

In article <loom.20060119T174907-286@post.gmane.org>, Eric Hanchrow <offby1@blarg.net> writes:

> dhruva <dklefty <at> gmail.com> writes:
>> Loading language/indian (source)...
>> IO error reading c:/tmp/build/emacs/lisp/language/indian.el: 
>> Bad file descriptor

> Thanks for reporting this.  I'm seeing essentially the same problem; the only
> difference is that I use the mingw32 tools to build, instead of Microsoft's.

I've got a report saying that it seems that the recent
changes to autoload-coding-system (mule.el) is the culprit.
He wrote that applying the following patch will fix the
problem.

*** mule.el	16 Jan 2006 21:01:11 +0900	1.229
--- mule.el	20 Jan 2006 21:54:09 +0900	
***************
*** 1147,1153 ****
  				  coding-system-alist))
    (dolist (elt '("-unix" "-dos" "-mac"))
      (let ((name (concat (symbol-name symbol) elt)))
!       (put (intern name) 'coding-system-define-form form)
        (setq coding-system-alist (cons (list name) coding-system-alist)))))
  
  (defun set-buffer-file-coding-system (coding-system &optional force nomodify)
--- 1147,1153 ----
  				  coding-system-alist))
    (dolist (elt '("-unix" "-dos" "-mac"))
      (let ((name (concat (symbol-name symbol) elt)))
!       ;; (put (intern name) 'coding-system-define-form form)
        (setq coding-system-alist (cons (list name) coding-system-alist)))))
  
  (defun set-buffer-file-coding-system (coding-system &optional force nomodify)


But, I have no idea what is wrong with the original code.
Does someone have any adea?

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> From: Eric Hanchrow <offby1@blarg.net>
> Date: Thu, 19 Jan 2006 16:53:38 +0000 (UTC)
> 
> dhruva <dklefty <at> gmail.com> writes:
> 
> > Loading language/indian (source)...
> > IO error reading c:/tmp/build/emacs/lisp/language/indian.el: 
> > Bad file descriptor
> 
> Thanks for reporting this.  I'm seeing essentially the same problem; the only
> difference is that I use the mingw32 tools to build, instead of Microsoft's.

I'm debugging this.  Looks like some Windows-specific bug that raised
its ugly head because of recent changes in code-pages.el.  Stay tuned.

Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Fri, 20 Jan 2006 21:58:01 +0900
> Cc: emacs-devel@gnu.org
> 
> > dhruva <dklefty <at> gmail.com> writes:
> >> Loading language/indian (source)...
> >> IO error reading c:/tmp/build/emacs/lisp/language/indian.el: 
> >> Bad file descriptor
> 
> > Thanks for reporting this.  I'm seeing essentially the same problem; the only
> > difference is that I use the mingw32 tools to build, instead of Microsoft's.
> 
> I've got a report saying that it seems that the recent
> changes to autoload-coding-system (mule.el) is the culprit.
> He wrote that applying the following patch will fix the
> problem.
> 
> *** mule.el	16 Jan 2006 21:01:11 +0900	1.229
> --- mule.el	20 Jan 2006 21:54:09 +0900	
> ***************
> *** 1147,1153 ****
>   				  coding-system-alist))
>     (dolist (elt '("-unix" "-dos" "-mac"))
>       (let ((name (concat (symbol-name symbol) elt)))
> !       (put (intern name) 'coding-system-define-form form)
>         (setq coding-system-alist (cons (list name) coding-system-alist)))))
>   
>   (defun set-buffer-file-coding-system (coding-system &optional force nomodify)
> --- 1147,1153 ----
>   				  coding-system-alist))
>     (dolist (elt '("-unix" "-dos" "-mac"))
>       (let ((name (concat (symbol-name symbol) elt)))
> !       ;; (put (intern name) 'coding-system-define-form form)
>         (setq coding-system-alist (cons (list name) coding-system-alist)))))
>   
>   (defun set-buffer-file-coding-system (coding-system &optional force nomodify)

Since the problem does not happen on GNU/Linux (I just verified it
didn't), the above could be a trigger for a bug, but it's not the bug
itself (or at least not the only bug).

> But, I have no idea what is wrong with the original code.
> Does someone have any adea?

I have some idea.  What I see in the debugger is that, when loadup
comes to load cyrillic.el, the file just before indian.el, it
repeatedly calls `openp' to load code-pages.el, but never closes the
resulting handle.  The reason it doesn't close it is that, after
`openp' returns, Fload checks if we are in recursive load cycle, and
finds that we are! (After the loop which looks at Vloads_in_progress,
`count's value is 4.)  It then calls Fsignal to signal this error, but
since we are in a protected form, Fsignal just unwinds there, and the
load continues (or so it seems).

Eventually, Fload finishes with cyrillic.el, but we leak the file
handles that `openp' returned and that weren't closed.

So when loadup comes to indian.el, the first file handle that is
available is 110.  And the Windows replacements for close/read/write
are prepared to work only with the first 64 handles, so `sys_read'
refuses to deal with handle 110.

I fixed the functions in w32.c to defer to the OS when they see a file
handle that is higher than their internal limit, so now Emacs should
bootstrap again.  (The 64-handle limitation has good reasons, but they
are only relevant to sockets, pipes, and sub-processes.  There's no
need to limit regular file handles, although Emacs shouldn't really
use so many handles at any single moment.)

I will also fix lread.c to close the handle opened by `openp' before
it signals the recursive load error.

This is just part of the riddle, it is still left to be explained why
loading cyrillic.el causes Emacs to load code-pages.el so many times.
Perhaps you can explain that, and maybe that's another bug.

Re: GNU Emacs CVS HEAD:

[Juanma Barranquero]

On 1/20/06, Eli Zaretskii <eliz@gnu.org> wrote:

> I have some idea.  What I see in the debugger is that, when loadup
> comes to load cyrillic.el, the file just before indian.el, it
> repeatedly calls `openp' to load code-pages.el, but never closes the
> resulting handle.  The reason it doesn't close it is that, after
> `openp' returns, Fload checks if we are in recursive load cycle, and
> finds that we are! (After the loop which looks at Vloads_in_progress,
> `count's value is 4.)  It then calls Fsignal to signal this error, but
> since we are in a protected form, Fsignal just unwinds there, and the
> load continues (or so it seems).

FWIW, even after your patches, *Messages* contains:

Error during redisplay: (error Recursive `require' for feature
`code-pages') [126 times]

--
                    /L/e/k/t/u

Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> Date: Sat, 21 Jan 2006 00:48:08 +0100
> From: Juanma Barranquero <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> FWIW, even after your patches, *Messages* contains:
> 
> Error during redisplay: (error Recursive `require' for feature
> `code-pages') [126 times]

Of course! because I did nothing to prevent the recursive load, I just
fixed the bugs that prevented Emacs from building on Windows due to it.

I get a similar message in *Messages* on GNU/Linux:

    Error during redisplay: (error Recursive load ~/emacs.cvs/emacs/lisp/international/code-pages.elc ~/emacs.cvs/emacs/lisp/international/code-pages.elc ~/emacs.cvs/emacs/lisp/international/code-pages.elc ~/emacs.cvs/emacs/lisp/international/code-pages.elc ~/emacs.cvs/emacs/lisp/international/code-pages.elc ~/emacs.cvs/emacs/lisp/language/cyrillic.el) [126 times]

So this problem is not specific to MS-Windows in any way.

Re: GNU Emacs CVS HEAD:

[Richard M. Stallman]

    I have some idea.  What I see in the debugger is that, when loadup
    comes to load cyrillic.el, the file just before indian.el, it
    repeatedly calls `openp' to load code-pages.el, but never closes the
    resulting handle.  The reason it doesn't close it is that, after
    `openp' returns, Fload checks if we are in recursive load cycle, and
    finds that we are! (After the loop which looks at Vloads_in_progress,
    `count's value is 4.)  It then calls Fsignal to signal this error, but
    since we are in a protected form, Fsignal just unwinds there, and the
    load continues (or so it seems).

It seems there are two bugs here.  One is that it recursively
loads one file.  The other is that it doesn't close the handles.
Perhaps that's due to a missing unwind_protect.

Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: handa@m17n.org, offby1@blarg.net, emacs-devel@gnu.org
> Date: Sat, 21 Jan 2006 14:58:13 -0500
> 
>     I have some idea.  What I see in the debugger is that, when loadup
>     comes to load cyrillic.el, the file just before indian.el, it
>     repeatedly calls `openp' to load code-pages.el, but never closes the
>     resulting handle.  The reason it doesn't close it is that, after
>     `openp' returns, Fload checks if we are in recursive load cycle, and
>     finds that we are! (After the loop which looks at Vloads_in_progress,
>     `count's value is 4.)  It then calls Fsignal to signal this error, but
>     since we are in a protected form, Fsignal just unwinds there, and the
>     load continues (or so it seems).
> 
> It seems there are two bugs here.  One is that it recursively
> loads one file.  The other is that it doesn't close the handles.
> Perhaps that's due to a missing unwind_protect.

Meanwhile, I fixed the second problem.  There's no need to
unwind_protect, all we need is close the handle before we call
Fsignal.

Re: GNU Emacs CVS HEAD:

[Richard M. Stallman]

    Of course! because I did nothing to prevent the recursive load, I just
    fixed the bugs that prevented Emacs from building on Windows due to it.

So what is it that causes the recursive load?

Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: lekktu@gmail.com, emacs-devel@gnu.org
> Date: Sat, 21 Jan 2006 22:58:20 -0500
> 
>     Of course! because I did nothing to prevent the recursive load, I just
>     fixed the bugs that prevented Emacs from building on Windows due to it.
> 
> So what is it that causes the recursive load?

I don't know, I never had time to investigate.

Re: GNU Emacs CVS HEAD:

[CHENG Gao]

*On Sat, 21 Jan 2006 10:39:06 +0200
* Eli Zaretskii <eliz@gnu.org> climbed out of the dark hell and cried out:

> So this problem is not specific to MS-Windows in any way.
Yesterday I made a fresh checkout and built successfully under MacOSX
10.4.4 with ./make-package --self-conained. So this is not for all
platforms. Yes I had same problem with Windows build by MinGW for CVS
trunk and unocode-2 branch.

Re: GNU Emacs CVS HEAD:

[Kenichi Handa]

In article <uhd7yr8xc.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> This is just part of the riddle, it is still left to be explained why
> loading cyrillic.el causes Emacs to load code-pages.el so many times.
> Perhaps you can explain that, and maybe that's another bug.

Thank you for tracking down the problem to that stage.  I
think I found why code-pages.el is recursively loaded, and
just installed a fix.  At least, on Debian, that recursive
load is stopped.

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: offby1@blarg.net, emacs-devel@gnu.org
> Date: Sun, 22 Jan 2006 21:33:54 +0900
> 
> Thank you for tracking down the problem to that stage.  I
> think I found why code-pages.el is recursively loaded, and
> just installed a fix.  At least, on Debian, that recursive
> load is stopped.

It stopped on MS-Windows as well.

Thanks.

Re: GNU Emacs CVS HEAD:

[Kenichi Handa]

In article <uacdooysn.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

>> Thank you for tracking down the problem to that stage.  I
>> think I found why code-pages.el is recursively loaded, and
>> just installed a fix.  At least, on Debian, that recursive
>> load is stopped.

> It stopped on MS-Windows as well.

Thank you for confirming that.  How about DOS?   As far as I
remember, DOS port loads codepage.el on dumping Emacs.
Doesn't my recent change break something in that version?

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: offby1@blarg.net, emacs-devel@gnu.org
> Date: Mon, 23 Jan 2006 09:44:23 +0900
> 
> Thank you for confirming that.  How about DOS?   As far as I
> remember, DOS port loads codepage.el on dumping Emacs.
> Doesn't my recent change break something in that version?

I haven't had time to build the DOS version in ages.  I will try to
find some time and look at this.