From: Eli Zaretskii <eliz@gnu.org>
Cc: offby1@blarg.net, emacs-devel@gnu.org
Subject: Re: GNU Emacs CVS HEAD:
Date: Fri, 20 Jan 2006 21:33:35 +0200 [thread overview]
Message-ID: <uhd7yr8xc.fsf@gnu.org> (raw)
In-Reply-To: <E1Ezvq5-0004n9-00@etlken> (message from Kenichi Handa on Fri, 20 Jan 2006 21:58:01 +0900)
> 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.
next prev parent reply other threads:[~2006-01-20 19:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-19 6:07 GNU Emacs CVS HEAD: "nmake bootstrap" fails dhruva
2006-01-19 16:53 ` GNU Emacs CVS HEAD: Eric Hanchrow
2006-01-20 12:58 ` Kenichi Handa
2006-01-20 19:33 ` Eli Zaretskii [this message]
2006-01-20 23:48 ` Juanma Barranquero
2006-01-21 8:39 ` Eli Zaretskii
2006-01-22 3:58 ` Richard M. Stallman
2006-01-22 4:33 ` Eli Zaretskii
2006-01-22 6:27 ` CHENG Gao
2006-01-21 19:58 ` Richard M. Stallman
2006-01-21 20:12 ` Eli Zaretskii
2006-01-22 12:33 ` Kenichi Handa
2006-01-22 19:19 ` Eli Zaretskii
2006-01-23 0:44 ` Kenichi Handa
2006-01-23 5:02 ` Eli Zaretskii
2006-01-20 16:37 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=uhd7yr8xc.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=offby1@blarg.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).