From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Fatal error 11: Segmentation Fault Date: Tue, 2 Apr 2019 09:27:40 -0700 (PDT) Message-ID: References: <86imvx5gyz.fsf@zoho.eu> <86ef6l5dwk.fsf@zoho.eu> <86a7h85ru5.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="241204"; mail-complaints-to="usenet@blaine.gmane.org" To: Emanuel Berg , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Apr 02 18:43:17 2019 Return-path: 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 ) id 1hBMVH-0010dc-7R for geh-help-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 18:43:15 +0200 Original-Received: from localhost ([127.0.0.1]:54943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBMVG-0001z7-5D for geh-help-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 12:43:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBMPk-0006HL-2H for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 12:37:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBMIF-0003Qt-Ie for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 12:29:48 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:47098) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hBMIF-0003Qe-7b for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 12:29:47 -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 x32GTVP8086228; Tue, 2 Apr 2019 16:29:44 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=z2KwaJwvt2fCAE/KbOIqfsIUX/Q5LxChTiHWZNZe7S0=; b=FikDiBzQAY6dFaKJpNcGsi9pWkRPa6os9XjGdNpgf10W3az8EQMSUM/8f54nVC3ELejJ xa+R4ghGvIlq0krPSPn0vGjj0FhVCN+vkSH5OnxMYUDcmbPu+tYw9FFbKrvXwuuSj/uL oNweGEWxooKNkvTJAY3A4callNu242j8UwxlJfcD2qYRH5r95FUztNjAadPg1L8AHs/N 3ZxQfIOwtKDGXI4FvQPx2Pe5pllMcpDRTO7xW1mAJWd1e1TCvlq5OshElj5BRg7bzJQf EOw97iNbLnM6ztW9aUK6G8sFyNJRnqYRrXGMqIlBaZlUmtEvwipmAV5Qt8IG22o3VLas 4g== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2rj0dnhuer-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 02 Apr 2019 16:29:44 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x32GTH9r044302; Tue, 2 Apr 2019 16:29:44 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2rm8f4utqq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 02 Apr 2019 16:29:44 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x32GTexo025227; Tue, 2 Apr 2019 16:29:43 GMT In-Reply-To: <86a7h85ru5.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-1904020110 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-1904020110 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:119832 Archived-At: > > if those both work then bisect your init file to > > find the culprit. >=20 > 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?" 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. > 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. 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. I use this, bound to `C-x C-;`, to comment out or (with plain `C-u`) uncomment a set of contiguous lines. It works also for nested commenting. (defun comment-region-lines (beg end &optional arg) "Like `comment-region', but comment/uncomment whole lines." (interactive "*r\nP") (when (> beg end) (setq beg (prog1 end (setq end beg)))) (let ((bol (save-excursion (goto-char beg) (line-beginning-position))) (eol (save-excursion (goto-char end) (if (bolp) (point) (line-end-position))))) (comment-region bol eol arg))) Yes, if a binary search by commenting out 1/2, 3/4, 7/8... of my init file indicates that the problem is in some file that that file loads, then I do the same thing to that file. Not immediate, but pretty quick. Of course it won't be all that quick if you don't get a crash quickly or each time. > Can't I use gdb or something to find it? No doubt you can. Someone else can help with that. I doubt that it will be quicker than narrowing your init file. But it will have the advantage of indicating just what the problem is. I'd suggest first narrow the code to debug, then use gdb etc. on that narrowed code. The worst way to test/debug something is typically to try to just run a giant sack of stuff. It's almost always beneficial to narrow the test space to a small sack.