Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Drew Adams wrote:

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

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

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

In principle, that's right. In practice, like
I said, the files are all interconnected with
`provide' and `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.

It can still be done obviously, only it takes
a lot of time and isn't mechanical work.

> 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. [1]


[1] http://www.dailyscript.com/scripts/transformers.html

-- 
underground experts united
http://user.it.uu.se/~embe8573