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 19:40:47 +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> <83k2k0dqtg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1460659300 13523 80.91.229.3 (14 Apr 2016 18:41:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 18:41:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 20:41: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 1aqmCo-0006Mj-E5 for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 20:41:30 +0200 Original-Received: from localhost ([::1]:44690 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqmCn-0000rL-UY for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 14:41:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqmCK-0000k5-QR for emacs-devel@gnu.org; Thu, 14 Apr 2016 14:41:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqmCF-0000jr-Qs for emacs-devel@gnu.org; Thu, 14 Apr 2016 14:41:00 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:40209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqmCF-0000jf-KL for emacs-devel@gnu.org; Thu, 14 Apr 2016 14:40:55 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aqmCE-00062C-F3 for emacs-devel@gnu.org; Thu, 14 Apr 2016 20:40:54 +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 20:40:54 +0200 Original-Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2016 20:40:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 72 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:V9z9bZSm53wLe8YPFONYphTS9qY= 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:202929 Archived-At: On Thu 14 Apr 2016, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Thu, 14 Apr 2016 18:06:02 +0100 >> >> > 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. > > Put breakpoint in Fwrite_region, and when it breaks, type these > commands: > > (gdb) p/x ¤t_buffer->text->beg[0] > (gdb) find /b9 current_buffer->text->beg,current_buffer->text->beg+GPT_BYTE-1,0 > > The first one should display the address of the beginning of buffer > text. The second one should display up to 9 places where there are > nulls in the buffer, I expect them to be consecutive addresses. The > first one of those is the address I'm looking for. Starting from a tree without a loaddefs.el file, the breakpoint is hit twice. The first time is when the skeleton loaddefs.el is written, that contains just the comemnt header and the trailer with the local variable settings. The second time is when it writes the completed autoloads buffer: Thread 1 hit Breakpoint 1, Fwrite_region (start=..., end=..., filename=..., append=..., visit=..., lockname=..., mustbenew=...) at ../../src/fileio.c:4678 4678 return write_region (start, end, filename, append, visit, lockname, mustbenew, (gdb) p/x ¤t_buffer->text->beg[0] $4 = 0x65a0000 (gdb) find /b9 current_buffer->text->beg,current_buffer->text->beg+GPT_BYTE-1,0 0x66c36b4 1 pattern found. (gdb) >> > 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. > > There's no serializing, buffer text is (almost) a linear array of > bytes. (Or do you mean encoding?) I meant any of the processing to get from content in memory to bits on spinning rust. That can include marshalling, encoding, flushing buffers etc. (not all of which apply here). >> 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. > > Are you saying that loaddefs.el is corrupted because the previous > loaddefs.el was already corrupted? If so, the corruption is not > really reproducible, is it? What happens if you manually correct > loaddefs.el (e.g., by bringing a copy from another build), and then > try building without "git clean"? The whole purpose of starting from a clean tree is to ensure that there is no interference from a previous failed build. batch-update-autoloads updates loaddefs.el in place if that file already exists, so if a previous build has left a corrupted version then subsequent builds will fail. My point was that replacing ldefs-boot.el with an up to date copy of loaddefs.el stopped the corruption. The bootstrap-emacs.exe built using the udpated ldefs-boot.exe produced a working loaddefs.el. AndyM