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: Build failure for Emacs master Date: Thu, 14 Apr 2016 19:35:26 +0300 Message-ID: <83oa9cdu7l.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1460651782 17549 80.91.229.3 (14 Apr 2016 16:36:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 16:36:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 18:36:21 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 1aqkFg-0006fO-1w for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 18:36:20 +0200 Original-Received: from localhost ([::1]:42808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkFb-0001NB-N6 for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 12:36:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkFF-0001IK-SP for emacs-devel@gnu.org; Thu, 14 Apr 2016 12:35:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqkFC-0007iy-E4 for emacs-devel@gnu.org; Thu, 14 Apr 2016 12:35:53 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52225) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkFC-0007iu-BS; Thu, 14 Apr 2016 12:35:50 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1201 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aqkFB-0008GS-O2; Thu, 14 Apr 2016 12:35:50 -0400 In-reply-to: <86lh4hm7dd.fsf@gmail.com> (message from Andy Moreton on Thu, 14 Apr 2016 00:11:42 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:202916 Archived-At: > 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? 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.) > 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. > 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. Thanks.