Re: GNU Emacs CVS HEAD:

[Eli Zaretskii]

> From: Kenichi Handa <address@hidden>
> Date: Fri, 20 Jan 2006 21:58:01 +0900
> Cc: address@hidden
> 
> > 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.