From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: Build failure for Emacs master Date: Thu, 14 Apr 2016 18:06:02 +0100 Message-ID: References: <56CCD91E.6070507@alice.it> <83egc2ixji.fsf@gnu.org> <56CD798D.7060102@alice.it> <56CD8408.1000701@alice.it> <83wppuggb4.fsf@gnu.org> <56CE2CA7.5050906@alice.it> <83io1cg2pt.fsf@gnu.org> <56DA0327.2030009@alice.it> <83oaatxu72.fsf@gnu.org> <570C4307.6050907@alice.it> <83k2k2g82s.fsf@gnu.org> <86egaa7b0z.fsf@gmail.com> <83a8kyfd38.fsf@gnu.org> <86lh4hm7dd.fsf@gmail.com> <83oa9cdu7l.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1460653597 15923 80.91.229.3 (14 Apr 2016 17:06:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 17:06:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 19:06:31 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aqkir-0006dW-Em for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 19:06:29 +0200 Original-Received: from localhost ([::1]:43263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkiq-00041g-KU for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 13:06:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkic-0003w4-UF for emacs-devel@gnu.org; Thu, 14 Apr 2016 13:06:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqkiY-0003s8-QN for emacs-devel@gnu.org; Thu, 14 Apr 2016 13:06:14 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:34282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkiY-0003ro-KD for emacs-devel@gnu.org; Thu, 14 Apr 2016 13:06:10 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aqkiW-0006TM-SX for emacs-devel@gnu.org; Thu, 14 Apr 2016 19:06:08 +0200 Original-Received: from uk.solarflare.com ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2016 19:06:08 +0200 Original-Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2016 19:06:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 60 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: uk.solarflare.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt) Cancel-Lock: sha1:2OZuVJktqdLVnUR3ezLWwXJYVlw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:202924 Archived-At: On Thu 14 Apr 2016, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Thu, 14 Apr 2016 00:11:42 +0100 >> >> The corrupted loaddefs.el file seems to be the right size, but the last >> 768 bytes are zero instead of the expected content. > > What is the total size of the loaddefs.el's text, in bytes? For emacs-25 commit 24b87a1d4aadbdeafbc0db17e3a760cc9a7e21ef, the corrupted loaddefs.el was 1192529 bytes, with the last 768 bytes zeroed. Changing the files scanned for autoloads produces a loaddefs file of different size (e.g. changed doc strings or different autoloads), and can change the size of the zeroed portion at the end of the file. e.g. with local changes, loaddefs.el 1192680 bytes, last 918 bytes zeroed loaddefs.el 1193247 bytes, last 918 bytes zeroed > Also, can you look in GDB at the buffer text, before it is written to > disk, and tell how far, in bytes, is the first null from the beginning > of buffer text? (Let me know if you need advice for how to do that > with GDB commands.) Please give precise instructions as I have no idea how to do that. >> Running that command using "bootstrap-emacs -Q" (i.e. interactively) >> shows that the *autoload-file* buffer contains the 768 zero characters >> at end, so it appears that the corruption occurs before the buffer is >> written to disk. > > Yes, of course. The corruption is caused by inserting and deleting > text into/from the buffer, as part as producing the autoload forms. That wasn't at all obvious to me without some testing: it could easily have been caused by problems serialising the buffer to disk. >> Any hints on how to debug `batch-update-autoloads' to diagnose this >> further would be welcome. > > The bug is unlikely to be on the Lisp level, it's something very deep > in managing buffer memory. Perhaps even on the level of mmap_alloc > and mmap_realloc, as they are implemented in w32heap.c (since the only > people who complain about this are building Emacs on Windows). > > If you can somehow establish where exactly in processing of the > autoloads the corruption happens (i.e. what file is Emacs processing > and what is the contents of the *autoload-file* buffer at that point), > that would be a step forward, I think. Any ideas to help do that are welcome. I've tried running the steps used to build loaddefs.el from "bootstrap-emacs.exe -Q" and stepping though it with edebug - that produces a working loaddefs.el :-( If I start from a completely clean tree (after "git clean -Xdf") and then copy the working loaddefs.el (produced above) to ldefs-boot.el, then a full bootstrap succeeds, and the resulting loaddefs.el is good. AndyM