RE: Fatal error 11: Segmentation Fault

[Drew Adams <drew.adams@oracle.com>]

> > if those both work then bisect your init file to
> > find the culprit.
> 
> 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.