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.