From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bruno Haible Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: [master b3cf281] Unbreak the MinGW build Date: Sat, 17 Dec 2016 00:17:31 +0100 Message-ID: <3331192.fdZnPqnNIH@linuix.haible.de> References: <83eg1887q4.fsf@gnu.org> <10588713.4sEyyCWImg@linuix.haible.de> <83y3zf7f6k.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: blaine.gmane.org 1481930290 27280 195.159.176.226 (16 Dec 2016 23:18:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 23:18:10 +0000 (UTC) User-Agent: KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; ) Cc: bug-gnulib@gnu.org To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Sat Dec 17 00:18:05 2016 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cI1lM-0006aW-Uy for gnu-bug-gnulib@m.gmane.org; Sat, 17 Dec 2016 00:18:05 +0100 Original-Received: from localhost ([::1]:34670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI1lR-0006Bz-82 for gnu-bug-gnulib@m.gmane.org; Fri, 16 Dec 2016 18:18:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI1l6-0006Al-B8 for bug-gnulib@gnu.org; Fri, 16 Dec 2016 18:17:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cI1l3-0004Cc-50 for bug-gnulib@gnu.org; Fri, 16 Dec 2016 18:17:48 -0500 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::6]:27376) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cI1l2-0004AT-UC for bug-gnulib@gnu.org; Fri, 16 Dec 2016 18:17:45 -0500 X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRavU46kji X-RZG-CLASS-ID: mo00 Original-Received: from bruno.haible.de (dslb-088-068-033-080.088.068.pools.vodafone-ip.de [88.68.33.80]) by smtp.strato.de (RZmta 39.11 DYNA|AUTH) with ESMTPSA id R0703esBGNHeQHe (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 17 Dec 2016 00:17:40 +0100 (CET) In-Reply-To: <83y3zf7f6k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2a01:238:20a:202:5300::6 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Original-Sender: "bug-gnulib" Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:36539 gmane.emacs.devel:210555 Archived-At: Eli Zaretskii wrote: > > - How often have you tried to temacs+dump with and without the change? > > Once each? Twice each? 10 times each? If it's a small number, you may > > be seeing a random result and not realize it was random. > > I did it in two separate branches, 3 times in each one. The results > are consistent. This crash isn't random. > > > - Did you run temacs in the same directory in both cases, or in different > > directories? Different directories could lead to a different memory > > layout in temacs, due to different filename lengths. > > Same directory. > > > - After determining that disabling the include would fix the crash, did > > you test whether reenable the include would reenable the crash? > > Yes. OK, that much for our "conventional" wisdom... Since, as you say, the crash occurs during dumping, this is what I would turn to now. Do you have a systematic approach for debugging crashes during dump? If dump is based on malloc, does it help to set MALLOC_PERTURB_? Can you use tools such as valgrind to debug it? > Having > uncommitted/unpushed changes in master means I need to jump through > hoops each time I need to push a change upstream. Yes, having to do $ git rebase -i HEAD~2 $ git push origin HEAD~1:master each time is extra work. > > I wouldn't have applied this patch, as the cause of the crash is obviously > > somewhere else. > > I know. Actually gnulib has a way to keep in your project changes relative to gnulib that should not be pushed upstream: It's gnulib-tool's --local-dir option. You would have had to create a small lib/stdio-impl.h.diff file that gets applied on the fly each time you invoke gnulib-tool for emacs. Bruno