From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs CVS HEAD: Date: Fri, 20 Jan 2006 21:33:35 +0200 Message-ID: References: <6d66855c0601182207t76b8bd41qb3cc4eba0ad5c8ed@mail.gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1137796925 28173 80.91.229.2 (20 Jan 2006 22:42:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2006 22:42:05 +0000 (UTC) Cc: offby1@blarg.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 20 23:42:04 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F04x1-0003JQ-3r for ged-emacs-devel@m.gmane.org; Fri, 20 Jan 2006 23:41:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F04zV-00072N-7d for ged-emacs-devel@m.gmane.org; Fri, 20 Jan 2006 17:44:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F023Q-0007Iq-M3 for emacs-devel@gnu.org; Fri, 20 Jan 2006 14:36:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F023O-0007I0-Do for emacs-devel@gnu.org; Fri, 20 Jan 2006 14:36:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F023O-0007Hk-0t for emacs-devel@gnu.org; Fri, 20 Jan 2006 14:36:10 -0500 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1F027d-00081g-WD for emacs-devel@gnu.org; Fri, 20 Jan 2006 14:40:34 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-64-251.inter.net.il [80.230.64.251]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DKE52567 (AUTH halo1); Fri, 20 Jan 2006 21:33:30 +0200 (IST) Original-To: Kenichi Handa In-reply-to: (message from Kenichi Handa on Fri, 20 Jan 2006 21:58:01 +0900) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49333 Archived-At: > From: Kenichi Handa > Date: Fri, 20 Jan 2006 21:58:01 +0900 > Cc: emacs-devel@gnu.org > > > dhruva 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.