From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams <drew.adams@oracle.com> Newsgroups: gmane.emacs.help Subject: RE: Fatal error 11: Segmentation Fault Date: Tue, 2 Apr 2019 18:37:35 -0700 (PDT) Message-ID: <5e7fb661-c090-4893-bcab-24ee4d96bea3@default> References: <86imvx5gyz.fsf@zoho.eu> <86ef6l5dwk.fsf@zoho.eu> <fa8afb1f-948c-481c-805a-c3161e0eafff@default> <86a7h85ru5.fsf@zoho.eu> <b6fed635-1d2d-42f5-8c6c-add29cbec84b@default> <865zrw55gm.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="183249"; mail-complaints-to="usenet@blaine.gmane.org" To: Emanuel Berg <moasenwood@zoho.eu>, help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Apr 03 03:37:59 2019 Return-path: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org> Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>) id 1hBUql-000lZS-8x for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 03:37:59 +0200 Original-Received: from localhost ([127.0.0.1]:42198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>) id 1hBUqk-0007bd-AJ for geh-help-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 21:37:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <drew.adams@oracle.com>) id 1hBUqY-0007bL-VS for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 21:37:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <drew.adams@oracle.com>) id 1hBUqX-0002R7-Dh for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 21:37:46 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:56132) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <drew.adams@oracle.com>) id 1hBUqW-0002QF-Ug for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 21:37:45 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x331SxH4014676; Wed, 3 Apr 2019 01:37:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=sddTh3wG5i/Jb6ravj5ku4F36V1WANHjZPfwToxYpuM=; b=5FHgCsrojnrlyuo6jnQsaGnTTjn0gnvsPNi+6G0xIYjPeTswPRNHT0vtA58EeX0Oo2en VywqmU+HjLHkm9Nm0UK4L6Y57usADwtNlQEf3BM67j025rzgR2CxyMDRIGfvGSQ0u3eF JzZttGz8fPCe5KqVMDqCVZoXOXdvLMyqhKOKzHPA8JSKNYV5sByPHV2qNgx9ZVPXl9/D 2LmuXe5imm/qtLmdP0hhHZ7hms8L2mMCy05NqBTvknPkNp9s5eTKNWalnBrLVdtbFVW/ Hulte1isVtDCLNC3OiP7CSUtKK8TX8A77FEJKC/e9hrVU1q/l9TV1gkcPkZqhO5PqVHG dQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2rj0dnn7v8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 03 Apr 2019 01:37:41 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x331bZ0M032605; Wed, 3 Apr 2019 01:37:40 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 2rm8f5treb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 03 Apr 2019 01:37:40 +0000 Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x331baVZ001653; Wed, 3 Apr 2019 01:37:39 GMT In-Reply-To: <865zrw55gm.fsf@zoho.eu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4822.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9215 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904030006 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9215 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904030006 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.78 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor <help-gnu-emacs.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/help-gnu-emacs>, <mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe> List-Archive: <http://lists.gnu.org/archive/html/help-gnu-emacs/> List-Post: <mailto:help-gnu-emacs@gnu.org> List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/help-gnu-emacs>, <mailto:help-gnu-emacs-request@gnu.org?subject=subscribe> Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org> Xref: news.gmane.org gmane.emacs.help:119845 Archived-At: <http://permalink.gmane.org/gmane.emacs.help/119845> > >> If it is in my init files, how come it works > >> once? I type this using Emacs. > > > > Wrong question, I think. The right question > > is this: "If it _doesn't_ happen when > > I _don't_ use my init file then what part of > > my init file makes it happen?" >=20 > My init should by definition not be able to > cause this, because Elisp shouldn't be able to > crash Emacs C style - or correct me if I'm > wrong, by supplying an example which I'll > evaluate immediately! (crash-emacs) ! >=20 > So it is rather some binary module which can > only be initiated once. This could be a clue as > to get there faster. Just thought someone might > know or think of something... If Emacs never crashes when you don't load your init file then something in your init file leads to it crashing. There's no way around that. That something could be as simple as loading other code that causes the problem. And yes, ultimately it is C code that has the bug. But your init file is (apparently) doing something that leads to that. The crash is ultimately due to Emacs C code. But who knows? It could be something in your setup or your OS or whatever that exposes the Emacs problem. > > It doesn't matter, for this, whether "it > > works once". What matters is that it > > (apparently) _always_ works if you don't load > > your init file and it (apparently) sometimes > > does not work if you do load your init file. >=20 > It works once. (kill-emacs), then 'emacs', or > don't (kill-emacs), then 'emacs' (i.e. > another Emacs instance) causes the crash > every time. Only when you use your init file, right? What I've said is based on that understanding, at least. But if you can make Emacs crash without your init file, then put that recipe in a report: `M-x report-emacs-bug'. So much the better. In that case you've narrowed down your init file to nothing. ;-) > >> Besides, doing a "binary search" isn't so > >> easy. Many files are interconnected. To mot > >> load one file does mean commenting out > >> `require's in lots'a others, as well as > >> functions who uses their stuff, then > >> functions that uses those functions, and > >> so on. > > > > Not sure I understand your description there. >=20 > I have all my Elisp in different files, > a.el, b.el, ..., n.el, tho they are not named > thus, of course. All those are in a directory > (with subdirs), called "emacs-init". > In ~/.emacs, there is a loop that checks for > files in that directory tree, which then loads > 'em all. So if I add n-plus-one.el, which > happens all the time, I don't edit ~/.emacs, it > loads the new file along with everything else > automatically. Ain't it cool stuff? >=20 > Well, in cases when binary search is called > for, like this one, it is still sort'a cool in > theory. Because I can just make a copy of the > "emacs-init" directory, move the original one > OOA, and then start removing files from the > test directory. Right? Removing files from your `load-path' only works without raising an error if you only soft-require them: (require 'foo nil t). If you hard-require a library that you've removed: (require 'foo) then Emacs raises an error. If you're looping and loading files in the loop then try only half a loop, then 1/4, 1/8,... > In principle, that's right. In practice, like > I said, the files are all interconnected with > `provide' and `require'.=20 You do not need to explicitly require/load files that are required by other files that you load, as I'm sure you know. So presumably you loop only over the files you need to explicitly load. They will load the files they require. > If I remove one file, > all files which require that file will have to > be removed as well. Those, in turn, provide > to other files which require THEM, and so on. See above. "Remove" (comment out or don't include in your loading loop) only files that you need explicitly to load, not files that get loaded by those files. Your loop should do that anyway. E.g., if a.el requires b.el and nothing requires a.el then your loop should load a, not both a and b. Removing something from your loop should not cause a problem. > It can still be done obviously, only it takes > a lot of time and isn't mechanical work. Maybe so. It should be _somewhat_ mechanical, but yes, it requires some thought too. Believe me, I know it can be less simple than its abstract description. And it can definitely seem slow in the beginning - especially because you have to start Emacs anew at each iteration, and those first iterations can be long (loading and initializing lots of stuff). But just remember that guy who negotiated the deal to double the number of rice grains on consecutive chessboard squares... Payoff comes big and quick after several iterations. What's the alternative? Trying to reason about all of your code at once? Trying to guess what you might have changed recently that introduced a new problem? Tweaking this or that, based on some intuition? You can use a debugger (e.g. gdb), of course. But it can make sense to first narrow things down a bit, _before_ jumping into a debugger. > > My init file and the many files it loads are > > likely more ugly and convoluted than yours > > (and no, I'm not proud/bragging about that). > > But binary search still helps and is not > > that hard. >=20 > If by "convoluted" you mean interconnected > (provide/require) then do tell how you do it. > Commenting out stuff until many files are > virtually empty but still provide/require > each other? >=20 > Anyway I start this now... Now, all we need is > a little Energon and a lot of luck. Good luck. And thanks for contributing your bug report (when it comes), to improve Emacs.