RE: Fatal error 11: Segmentation Fault

[Drew Adams]

> >> 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?"
> 
> 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) !
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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'. 

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.
> 
> 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?
> 
> 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.