Fatal error 11: Segmentation Fault

Fatal error 11: Segmentation Fault

[Emanuel Berg]

I can start Emacs25 only one time, after that
I get "Fatal error 11: Segmentation Fault".

It doesn't matter if I kill Emacs or start
another instance.

'emacs -Q' works but byte-compiling doesn't
complain.

I think it has something to do with the
/etc/emacs/site-start.d files as they are
sometimes mentioned in connection with the
error message.

This is the first time I got a C error so this
time I really must'a done something!

Version

    GNU Emacs 25.1.1
    (arm-unknown-linux-gnueabihf, GTK+ Version
    3.22.11) of 2017-09-16, modified by Debian

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

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

> 'emacs -Q' works but byte-compiling
> doesn't complain.

'emacs -q' works.

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

RE: Fatal error 11: Segmentation Fault

[Drew Adams]

 
> > 'emacs -Q' works but byte-compiling
> > doesn't complain.
> 
> 'emacs -q' works.

Haven't been following this thread, but if those
both work then bisect your init file to find the
culprit.

But Emacs shouldn't crash in any case, so you'll
likely want to file a bug report once you get a
minimal recipe to repro the crash.
(`M-x report-emacs-bug'.)

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Drew Adams wrote:

>>> 'emacs -Q' works but byte-compiling
>>> doesn't complain.
>>  'emacs -q' works.
>
> Haven't been following this thread, but if
> those both work then bisect your init file to
> find the culprit.
>
> But Emacs shouldn't crash in any case, so
> you'll likely want to file a bug report once
> you get a minimal recipe to repro the crash.
> (`M-x report-emacs-bug'.)

If it is in my init files, how come it
works once? I type this using Emacs.

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.

Can't I use gdb or something to find it?

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

RE: Fatal error 11: Segmentation Fault

[Drew Adams]

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

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

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.

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Drew Adams wrote:

> 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. [...] Only when you use your
> init file, right? [...] But if you can make
> Emacs crash without your init file, then put
> that recipe in a report

Comments: 0

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

I like to explicitly `require' everything and
anything any and all file need, every time,
then byte compile everything.

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

Again, remove one file, ~10 other files report
errors because they rely on that file.
Remove them, ~10*10 files report errors.
Binary search really is a poor choice for this
kind'a situation. It is not a list of `setq's
that do a bunch of configs independently of
each other. It is a 496 `defun's that rely on
each other to work, in 116 different files,
with 279 `require' and 62 `provide'!

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

The alternative is to *think*. The Elisp
couldn't have done it without some external
part. What is external?


    - my Emacs-zsh-tmux-X stuff

    - Emacs-w3m (3rd party, installed from the
      distros repos)

    - the packs from [M]ELPA - well, they are
      external in one sense, but I always
      thought them just even more Elisp, so I'm
      surprised the solution was the placement
      of `package-initialize' - it might has
      something to do with the byte-compiler as
      well, tho that doesn't make sense (?)
      either. Intuition, as you say.
      Investigating...

    - something else?


And speaking of the byte-compiler, why didn't
it tell me about this?

Also, it could have told me about
"digit-char-p" (which I discovered should be
`cl-digit-char-p' [1], only because there was
a (require 'cl-lib) at the top of the file! [2]


[1] http://lists.gnu.org/archive/html/help-gnu-emacs/2019-04/msg00001.html
[2] http://user.it.uu.se/~embe8573/emacs-init/negative-subtraction.el

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

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Here is presently how I can get the bug
up/down-and-[not]-running with the least
in-between steps.

Step by step:

Move (package-initialize) from ~/.emacs [1] to
elpa.el [2] then byte-compile [3] with 'emake',
which is

    make $@ -s -C ~/.emacs.d/emacs-init # [4]

then

    $ emacs --debug-init # works, but try again...

    $ emacs --debug-init # Fatal error 11: Segmentation fault

reset (package-initialize) from elpa.el to
.emacs, do 'emake', and

    $ emacs # works
    $ emacs # works


[1] http://user.it.uu.se/~embe8573/conf/.emacs

[2] http://user.it.uu.se/~embe8573/emacs-init/elpa.el
    (Yeah, I should change the name of that file...)

[3] http://user.it.uu.se/~embe8573/emacs-init/Makefile

[4] http://user.it.uu.se/~embe8573/conf/.zsh/ide

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 08:47:12 +0200
> 
> Move (package-initialize) from ~/.emacs [1] to
> elpa.el [2] then byte-compile [3] with 'emake',
> which is
> 
>     make $@ -s -C ~/.emacs.d/emacs-init # [4]

What does this do, exactly?

>     $ emacs --debug-init # works, but try again...
> 
>     $ emacs --debug-init # Fatal error 11: Segmentation fault

What happens if you invoke Emacs in the same way the 3rd, 4th,
etc. time?  Does it crash on every invocation except the first, or on
every second invocation, or something else?

> reset (package-initialize) from elpa.el to
> .emacs, do 'emake', and
> 
>     $ emacs # works
>     $ emacs # works

It is possible that some of your customizations write something to the
disk, and that triggers the problem the next time.

If you want to help us find the culprit, run Emacs under GDB (install
Emacs with symbols if needed), and file a bug report with the C
backtrace, using "M-x report-emacs-bug RET".  Continuing the
discussion here is unlikely to find the reason for the crashes.

Another alternative is to upgrade to Emacs 26, perhaps this problem
was already solved during development after Emacs 25.

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

>> Move (package-initialize) from ~/.emacs [1]
>> to elpa.el [2] then byte-compile [3] with
>> 'emake', which is
>> 
>>     make $@ -s -C ~/.emacs.d/emacs-init # [4]
>
> What does this do, exactly?

OK, let's kill and yank some from make(1)...

    $@  all arguments (files), typically not used
    -s  -s, --silent, --quiet (except for error messages)   
    -C dir Change to directory dir (i.e. invoke it from wherever)

It executes the Makefile [1] which turns all
the .el's into .elc's.

>>     $ emacs --debug-init # works, but try again...
>> 
>>     $ emacs --debug-init # Fatal error 11: Segmentation fault
>
> What happens if you invoke Emacs in the same
> way the 3rd, 4th, etc. time? Does it crash on
> every invocation except the first, or on every
> second invocation, or something else?

It crashes every time since the first time.
Even if you do `kill-emacs' and run it again,
it crashes. It crashes until you do
'emake clean' (same Makefile) and byte-compile
again. Then it works one and only one time.

> It is possible that some of your
> customizations write something to the disk,
> and that triggers the problem the next time.

Possible. BTW I upgraded all the [M]ELPA
packages to their latest versions. Same thing.

> If you want to help us find the culprit, run
> Emacs under GDB (install Emacs with symbols
> if needed), and file a bug report with the
> C backtrace, using "M-x report-emacs-bug
> RET".

OK, maybe it will happen...

> Another alternative is to upgrade to Emacs
> 26, perhaps this problem was already solved
> during development after Emacs 25.

Oh, no! I just upgraded the system and
installed Emacs 25 from the repos. Besides it
will be a ton of work to move all the files to
Emacs 26, and I already tried that, back when
I was on Emacs 24. I couldn't get a separate
directory going for the init files and in
particular I couldn't get Emacs-w3m to work.


[1] http://user.it.uu.se/~embe8573/emacs-init/Makefile

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

Re: Fatal error 11: Segmentation Fault

[tomas]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

On Wed, Apr 03, 2019 at 07:30:19AM +0200, Emanuel Berg wrote:

(off a tangent, but interesting, I think)

[...]

> I like to explicitly `require' everything and
> anything any and all file need, every time,
> then byte compile everything.

So far, so good.

> Again, remove one file, ~10 other files report
> errors because they rely on that file.

And here you see the price you pay for your above
decision. If every (module, file, call them how you
want) "taked care" of its dependencies, you'd have
more independency among all those moving parts.

You pay a price for this approach too [1], nothing
comes for free. But this latter approach seems to
be current consensus for more complex systems.

Cheers

[1] If left to evolve without constraints it leads to
   something I once called "the Java Disease". This was
   before node.js and npm -- these days I'd coin another
   term for it, for sure.

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Vegard Vesterheim]

I haven't read all the messages in this thread closely, but it reminded
me of a similar situation.

After upgrading to emacs25 some time ago, I experienced that emacs would
segfault every so often. I have been using emacs for many years, and my
.emacs file is constantly tweaked, so it was difficult to pinpoint what
was causing the crash. I finally discovered a way to reliably reproduce
this segfault. Since I have my .emacs in git, it was simply a matter of
supplying a small script that triggered the error to the 'git bisect
run' command. After running for a while git was able to pinpoint the
change in my .emacs that triggered the bug.

-- 
- Vegard V -

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Vegard Vesterheim <vegard.vesterheim@uninett.no>
> Date: Wed, 3 Apr 2019 10:51:38 +0000
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> After upgrading to emacs25 some time ago, I experienced that emacs would
> segfault every so often. I have been using emacs for many years, and my
> .emacs file is constantly tweaked, so it was difficult to pinpoint what
> was causing the crash. I finally discovered a way to reliably reproduce
> this segfault. Since I have my .emacs in git, it was simply a matter of
> supplying a small script that triggered the error to the 'git bisect
> run' command. After running for a while git was able to pinpoint the
> change in my .emacs that triggered the bug.

FWIW, IME bisection is only helpful when you cannot reproduce the
issue at will or easily enough.  If reproduction is easy, it is much
more useful to debug the failure than to find the change which is to
blame, because finding that change in most cases still doesn't tell
you how to fix the problem, certainly not with a segfault.

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Vegard Vesterheim]

On Wed, 3 Apr 2019 14:14:39 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

> FWIW, IME bisection is only helpful when you cannot reproduce the
> issue at will or easily enough.

I disagree, it was *very* helpful *for me* to be able to get rid of the
segfaults.

> If reproduction is easy, it is much more useful to debug the failure
> than to find the change which is to blame, because finding that change
> in most cases still doesn't tell you how to fix the problem, certainly
> not with a segfault.

This is a valid point. At least for those who have the necessary
knowledge and determination to perform the debugging. I remember having
intentions about reporting this specific bug. I tried to create a
minimal configuration which still triggered the bug, but I gave up when
I was unable to easily do so.

-- 
- Vegard V -

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

> FWIW, IME bisection is only helpful when you
> cannot reproduce the issue at will or easily
> enough. If reproduction is easy, it is much
> more useful to debug the failure than to find
> the change which is to blame, because finding
> that change in most cases still doesn't tell
> you how to fix the problem, certainly not
> with a segfault.

Good point, but still, let's think about
the change.

`package-initialize' is key #1. If it is done
before the packs are refered to (?) or used, it
works once, then crashes.

If package-initialize is used first thing, it
always works.

The byte-compiler is key #2. One can always
remedy the situation by byte-compiling
everything again ... but how come?

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

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Skip Montanaro]

Two small comments:

> After upgrading to emacs25 some time ago, I experienced that emacs would
> segfault every so often.

Back in the early days, Emacs was configured (as I recall now with my
old man's memory) that if you hit C-g twice in quick succession it
would provoke an abort(

> Since I have my .emacs in git, it was simply a matter of
> supplying a small script that triggered the error to the 'git bisect
> run' command.

I have (for the past few years, anyway) stored all my dot files in git
(nothing distributed, just local), mostly as a way to recover from
accidental deletion. You've provided yet another reason to use it.
Thanks for the tip.

Skip Montanaro

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Skip Montanaro <skip.montanaro@gmail.com>
> Date: Wed, 3 Apr 2019 07:14:44 -0500
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> Back in the early days, Emacs was configured (as I recall now with my
> old man's memory) that if you hit C-g twice in quick succession it
> would provoke an abort(

That still happens, although nowadays it's hard to achieve that on a
GUI frame, only on a TTY frame.

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

>> Back in the early days, Emacs was configured
>> (as I recall now with my old man's memory)
>> that if you hit C-g twice in quick
>> succession it would provoke an abort(
>
> That still happens, although nowadays it's
> hard to achieve that on a GUI frame, only on
> a TTY frame.

Is there a way to disable this or to get back
to Emacs which is still run? This happens to me
now and then.

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

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 16:52:31 +0200
> 
> Eli Zaretskii wrote:
> 
> >> Back in the early days, Emacs was configured
> >> (as I recall now with my old man's memory)
> >> that if you hit C-g twice in quick
> >> succession it would provoke an abort(
> >
> > That still happens, although nowadays it's
> > hard to achieve that on a GUI frame, only on
> > a TTY frame.
> 
> Is there a way to disable this or to get back
> to Emacs which is still run?

When that happens, Emacs _asks_ you whether to abort and dump core.
You don't have to answer YES.

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

>> Is there a way to disable this or to get
>> back to Emacs which is still run?
>
> When that happens, Emacs _asks_ you whether
> to abort and dump core. You don't have to
> answer YES.

OK, then what happens to me is something else.
Emacs gets buried as a bg process. I never
cared for that fg and bg stuff anyway, as
I don't see the benefit (maybe I'm blind?).

Perhaps there is an easy way to get back to
Emacs, but because it happens so rarely, so far
I've just killed it and started over.

I doesn't feel like the right thing to do, but
at least I blame my poor uptime on it.


    $ uptime
    17:45:12 up 1 day, 14:33, 14 users,  load average: 0.10, 0.09, 0.03


Oh, wait! That's the system uptime, not ERC
#emacs ditto...

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

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Vegard Vesterheim wrote:

> After upgrading to emacs25 some time ago,
> I experienced that emacs would segfault every
> so often. I have been using emacs for many
> years, and my .emacs file is constantly
> tweaked, so it was difficult to pinpoint what
> was causing the crash. I finally discovered
> a way to reliably reproduce this segfault.
> Since I have my .emacs in git, it was simply
> a matter of supplying a small script that
> triggered the error to the 'git bisect run'
> command. After running for a while git was
> able to pinpoint the change in my .emacs that
> triggered the bug.

Interesting. And what small script was that, if
I may?

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

Re: Using 'git bisect' to pinpoint errors in .emacs. Was: Fatal error 11: Segmentation Fault

[Vegard Vesterheim]

On Wed, 3 Apr 2019 16:35:48 +0200 Emanuel Berg <moasenwood@zoho.eu> wrote:

> Vegard Vesterheim wrote:
>> Since I have my .emacs in git, it was simply
>> a matter of supplying a small script that
>> triggered the error to the 'git bisect run'
>> command. 
>
> Interesting. And what small script was that, if
> I may?

When calling 'git bisect run' you are supposed to supply a script which
exits with code 0 if the source code is good, and exits with a code
between 1 and 127 (inclusive), except 125, if the current source code is
bad/new.

In my specific case, I discovered that simply creating two consecutive
frames caused a segfault. So I created this script:

----- snip - snip -------------------------------------------------
#!/bin/sh
emacs -f make-frame-command -f make-frame-command -f kill-emacs

if [ "$?" -ne '0' ]; then
    exit 127
fi
----- snip - snip -------------------------------------------------

BTW, I compiled the latest emacs source from git, and observed that the
bug is present also there.

I guess I should take another stab at identifying a minimal
configuration which can be supplied with a proper bug report.

-- 
- Vegard V -

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

tomas wrote:

> And here you see the price you pay for your
> above decision. If every (module, file, call
> them how you want) "taked care" of its
> dependencies, you'd have more independency
> among all those moving parts.

Well, maybe - I haven't seen "the alternative"
recently, so I don't know. But even if the
alternative made binary search super-easy and
fast, it is still a matter of principle.
I write code for the case when it works, not
for the case when it doesn't.
Speaking generally, that is...

> You pay a price for this approach too [1],
> nothing comes for free. But this latter
> approach seems to be current consensus for
> more complex systems.

... what approaches are there, again?

I know my approach, it is the
every-file-for-itself then byte-compile.
Does it have a name? If not, let's call it the
bricklayer approach as `require's are piled as
bricks in a wall :)

What pros and cons do the different approaches,
including mine, have?

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

Re: Fatal error 11: Segmentation Fault

[tomas]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Wed, Apr 03, 2019 at 04:34:32PM +0200, Emanuel Berg wrote:
> tomas wrote:
> 
> > And here you see the price you pay for your
> > above decision [...]

> ... what approaches are there, again?

I was talking about every piece of code (conditionally) pulling
in its dependencies (with require, e.g.). This makes it much
easier to skip parts without the whole construction breaking
down. But hey -- it's just an offer. You are not forced to do
it this way :-D

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: Fatal error 11: Segmentation Fault

[Drew Adams]

> > > And here you see the price you pay for your
> > > above decision [...]
> 
> > ... what approaches are there, again?
> 
> I was talking about every piece of code (conditionally) pulling
> in its dependencies (with require, e.g.). This makes it much
> easier to skip parts without the whole construction breaking
> down. But hey -- it's just an offer. You are not forced to do
> it this way :-D

I tried suggesting the same thing.  Imagine...

You're going on vacation.  You make a list
of what you need to bring.  For each thing
you think of you decide to list not only that
thing but also each of its parts.

For your car you list not only "car" but also
tires, engine, transmission, radio...

Why?  Because you think it's easier somehow.
Because you can loop over your checklist...

Your car already requires its tires (at least
it should!).  Leaving your car home should
automatically leave your tires home.

But if you list each bit separately then sure,
if you try to bring your car _without_ the
tires there'll be a problem because it thinks
it needs them (and it does).

This is why we have things like `require' -
they keep track of dependencies for us.

List only the things _you_ need to bring.
Make sure that things that require other
things know that they require them, so
_they_ take care of bringing whatever
_they_ need, saving you the bother.

Then if you leave something home none of
the things you bring with you will holler.

Re: Fatal error 11: Segmentation Fault

[tomas]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On Wed, Apr 03, 2019 at 10:06:41AM -0700, Drew Adams wrote:
> > > > And here you see the price you pay for your
> > > > above decision [...]
> > 
> > > ... what approaches are there, again?
> > 
> > I was talking about every piece of code (conditionally) pulling
> > in its dependencies [...]

> I tried suggesting the same thing.  Imagine...
> 
> You're going on vacation.  You make a list
> of what you need to bring.  For each thing
> you think of you decide to list not only that
> thing but also each of its parts.

[...]

But then, I like to beat my egg whites by hand. Some
people look at me in bewilderment. Whatever :-)

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Fatal error 11: Segmentation Fault

[Robert Thorpe]

<tomas@tuxteam.de> writes:
> On Wed, Apr 03, 2019 at 04:34:32PM +0200, Emanuel Berg wrote:
>> tomas wrote:
>> 
>> > And here you see the price you pay for your
>> > above decision [...]
>
>> ... what approaches are there, again?
>
> I was talking about every piece of code (conditionally) pulling
> in its dependencies (with require, e.g.). This makes it much
> easier to skip parts without the whole construction breaking
> down. But hey -- it's just an offer. You are not forced to do
> it this way :-D
>
> Cheers
> -- t

For what it's worth, this is the approach I use.

If I have a lot of related elisp then I put it into a file by itself.  I
treat it as a self-contained module.  All of the dependencies it needs
are required there.  So, I could hand the file to someone else using
stock Emacs and it would just work.  This method is useful for
debugging.

BR,
Robert Thorpe

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Robert Thorpe wrote:

> If I have a lot of related elisp then I put
> it into a file by itself. I treat it as
> a self-contained module. All of the
> dependencies it needs are required there. So,
> I could hand the file to someone else using
> stock Emacs and it would just work.
> This method is useful for debugging.

It is a module at first alright, but what if
you have a second module later on, and that
second module uses stuff that the first module
already has? Do you kill/yank it into module-2
verbatim?

If so, they are not modules anymore IMO - more
like the opposite of modularity, I'm afraid -
"dinosaurs", perhaps...

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

Re: Fatal error 11: Segmentation Fault

[Robert Thorpe]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Robert Thorpe wrote:
>
>> If I have a lot of related elisp then I put
>> it into a file by itself. I treat it as
>> a self-contained module. All of the
>> dependencies it needs are required there. So,
>> I could hand the file to someone else using
>> stock Emacs and it would just work.
>> This method is useful for debugging.
>
> It is a module at first alright, but what if
> you have a second module later on, and that
> second module uses stuff that the first module
> already has? Do you kill/yank it into module-2
> verbatim?
>
> If so, they are not modules anymore IMO - more
> like the opposite of modularity, I'm afraid -
> "dinosaurs", perhaps...

If the copying is only a few lines then I'd copy them.  If not, I would
put the common parts into a third file.  Then I'd require that third
file from both of the two original modules.

BR,
Robert Thorpe

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Robert Thorpe wrote:

> If the copying is only a few lines then I'd
> copy them. If not, I would put the common
> parts into a third file. Then I'd require
> that third file from both of the two
> original modules.

Yeah, that's what I do. Only I do it in the
"only a few lines" case as well. That way
I don't have to count the lines when in
doubt :)

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

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

tomas wrote:

>> ... what approaches are there, again?
>
> I was talking about every piece of code
> (conditionally) pulling in its dependencies
> (with require, e.g.). This makes it much
> easier to skip parts without the whole
> construction breaking down. But hey -- it's
> just an offer. You are not forced to do it
> this way :-D

I know, but how about posting a small example
how it/they would work?

I can do the same to "lead by example", if
you will :)

;; This file: http://user.it.uu.se/~embe8573/bricklayer-approach.el

;; first do all the `requires's
(require 'a)
(require 'b)
;; ...
(require 'n)

;; now new stuff begins
(defun do-something-brand-new ()
  (do-something-that-involves-something-from-a)
  (do-something-that-involves-something-from-b)
  ;; ...
  (do-something-that-involves-something-from-n) )

;; as soon as the last
;; `do-something-that-involves-something-from-z's
;; dissappear from this file, remove
;; (require 'z) (this can be difficult to keep
;; track of in practice, unless there are
;; tricks that I'm currently unaware of - do
;; tell if you know a method or even tool to do
;; it - not that it matters all that much in
;; practice, I suppose)

;; add this line...
(provide 'bricklayer-approach)
;; only at that time when
;; `do-something-brand-new' is used in another
;; file, which, you guessed it, will
;; (require 'bricklayer-approach)

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

Re: Fatal error 11: Segmentation Fault

[Óscar Fuentes]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Can't I use gdb or something to find it?

For diagnosing crashes the information provided by gdb is key.

On the Help menu click on "How to report a bug" then enter in "Checklist
for Bug Reports" and search for "GDB".

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Óscar Fuentes wrote:

>> Can't I use gdb or something to find it?
>
> For diagnosing crashes the information
> provided by gdb is key.

That's what I thought as well.

> On the Help menu click on "How to report
> a bug" then enter in "Checklist for Bug
> Reports" and search for "GDB".

Now you do me an injustice, obviously I'm not
using menus :)

But I'll look for what you refer to
nonetheless...

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

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

> Now you do me an injustice, obviously I'm not
> using menus :)
>
> But I'll look for what you refer to
> nonetheless...

(info "(emacs) Checklist")

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

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

> (info "(emacs) Checklist")

It says one should execute Emacs in the same
directory as the source, but I have my emacs25
from the Raspbian repos. (I have the
emacs25-src pack but I suspect that isn't what
is refered to.)

The source my Emacs was installed from isn't
still on my computer (with apt-get/aptitude),
right?

Also it isn't clear IMO exactly what to do,
more of a tech discussion and lots of what
_not_ to do.

I don't say there is a silver bullet solution,
more like a paragraph could be "If you have no
clue what's going on, do this as a best-effort
first move..."

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

Re: Fatal error 11: Segmentation Fault

[Óscar Fuentes]

Emanuel Berg <moasenwood@zoho.eu> writes:

>> (info "(emacs) Checklist")
>
> It says one should execute Emacs in the same
> directory as the source, but I have my emacs25
> from the Raspbian repos. (I have the
> emacs25-src pack but I suspect that isn't what
> is refered to.)

emacs25-dbg (if exists in Raspbian) is needed for readable stack traces.

> The source my Emacs was installed from isn't
> still on my computer (with apt-get/aptitude),
> right?

If you have emacs25-src installed, you have the source, I suppose.

> Also it isn't clear IMO exactly what to do,
> more of a tech discussion and lots of what
> _not_ to do.
>
> I don't say there is a silver bullet solution,
> more like a paragraph could be "If you have no
> clue what's going on, do this as a best-effort
> first move..."

Okay, after installing emacs25-dbg, do this:

$ gdb emacs
(gdb) run
<... use emacs until it crashes ...>
(gdb) backtrace
(gdb) xbacktrace

Copy the output of the last two commands and paste them on the buffer
created by M-x report-emacs-bug.

To exit GDB:

(gdb) quit
<... if it asks for a confirmation, say `y'...>

Re: Fatal error 11: Segmentation Fault

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Okay, after installing emacs25-dbg, do this:

Oh, as the instructions on the info node you know say, it is recommended
to `cd' to the `src` directory of emacs source code before starting gdb,
for xbacktrace to work. Or, if you prefer:

> $ gdb emacs
> (gdb) run

(gdb) source /pathtoemacssourcetree/src/.gdbinit

> <... use emacs until it crashes ...>
> (gdb) backtrace
> (gdb) xbacktrace
>
> Copy the output of the last two commands and paste them on the buffer
> created by M-x report-emacs-bug.
>
> To exit GDB:
>
> (gdb) quit
> <... if it asks for a confirmation, say `y'...>

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

It seems the problem arose from not having
this:


    (package-initialize)


(I had it in another file but it wasn't
soon enough.)

I don't know why this made Emacs crash tho.

It worked in Emacs 24 and for the previous
version of Raspbian (Jessie).

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

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

> It seems the problem arose from not having
> this:
>
>     (package-initialize)
>
> (I had it in another file but it wasn't
> soon enough.)
>
> I don't know why this made Emacs crash tho.
>
> It worked in Emacs 24 and for the previous
> version of Raspbian (Jessie).

Half a wonderful night spent on this total
misery. I need to ride my bike NOW before it
gets bright and before I loose my mind any more
than I already did.

Next time on Emacs TV we will examine what
packages are installed and what versions and
we'll try to narrow it down even further,
the Paleo-Techno-Supremacy willing.

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

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Óscar Fuentes wrote:

> emacs25-dbg (if exists in Raspbian) is needed
> for readable stack traces.

Indeed, it is needed and it exists - Raspbian
is Debian for the RPi is the saying (and it is
true).

>> The source my Emacs was installed from isn't
>> still on my computer (with
>> apt-get/aptitude), right?
>
> If you have emacs25-src installed, you have
> the source, I suppose.

Yes, but not the actual source Emacs was
compiled from, right? (But the difference is
perhaps academic.)

> Okay, after installing emacs25-dbg, do this:
>
> $ gdb emacs
> (gdb) run
> <... use emacs until it crashes ...>
> (gdb) backtrace
> (gdb) xbacktrace
>
> Copy the output of the last two commands and
> paste them on the buffer created by M-x
> report-emacs-bug.
>
> To exit GDB:
>
> (gdb) quit
> <... if it asks for a confirmation, say `y'...>

Why don't you put this together and suggest it
as an addition to (info "(emacs) Checklist")

Actually I think there should be a
"How to use GDB when Emacs crashes" node
(child/leaf) from (info "(emacs) Bugs") .

"Checklist" is like a typical thing people
typically don't like to check out! You get the
feeling there is a schoolteacher behind that
door telling you to improve your handwriting,
or something.

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 06:47:06 +0200
> 
> Why don't you put this together and suggest it
> as an addition to (info "(emacs) Checklist")

Because users don't normally debug Emacs, and aren't expected to do
that as part of reporting bugs.  It's a bonus, not a requirement.

> Actually I think there should be a
> "How to use GDB when Emacs crashes" node
> (child/leaf) from (info "(emacs) Bugs") .

There's etc/DEBUG, please take a look.  It is mentioned in the
Checklist section.

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

>> Why don't you put this together and suggest
>> it as an addition to (info "(emacs)
>> Checklist")
>
> Because users don't normally debug Emacs, and
> aren't expected to do that as part of
> reporting bugs. It's a bonus, not
> a requirement.

Well then, do the most to help them provide the
bonus, I say.

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 07:31:45 +0200
> 
> > Because users don't normally debug Emacs, and
> > aren't expected to do that as part of
> > reporting bugs. It's a bonus, not
> > a requirement.
> 
> Well then, do the most to help them provide the
> bonus, I say.

We do, by mentioning etc/DEBUG in that section.

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

>>> Because users don't normally debug Emacs,
>>> and aren't expected to do that as part of
>>> reporting bugs. It's a bonus, not
>>> a requirement.
>> 
>> Well then, do the most to help them provide
>> the bonus, I say.
>
> We do, by mentioning etc/DEBUG in
> that section.

I meant even more, and in particular the way
I suggested it :)

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 08:48:25 +0200
> 
> >> Well then, do the most to help them provide
> >> the bonus, I say.
> >
> > We do, by mentioning etc/DEBUG in
> > that section.
> 
> I meant even more, and in particular the way
> I suggested it :)

If something useful is missing from etc/DEBUG, please point that out.
But including that stuff in the user manual would be a step in the
wrong direction, because there's quite a bit to tell, while
"Checklist" is already more than 350 lines long, and runs a real risk
to lose the reader too early.

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

>> I meant even more, and in particular the way
>> I suggested it :)
>
> If something useful is missing from
> etc/DEBUG, please point that out.
> But including that stuff in the user manual
> would be a step in the wrong direction,
> because there's quite a bit to tell, while
> "Checklist" is already more than 350 lines
> long, and runs a real risk to lose the reader
> too early.

I'm not suggesting adding anything more to the
"Checklist", which is a lousy name as I said.
People won't read it, _especially_ not if it
is long.

My suggestion is add a *new* short, neat,
to-the-point entry, with the title ~"When Emacs
crashes, use GDB like this".

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 09:51:14 +0200
> 
> My suggestion is add a *new* short, neat,
> to-the-point entry, with the title ~"When Emacs
> crashes, use GDB like this".

There is already a section called "When Emacs Crashes".

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

>> My suggestion is add a *new* short, neat,
>> to-the-point entry, with the title ~"When
>> Emacs crashes, use GDB like this".
>
> There is already a section called "When Emacs
> Crashes".

Ah, right, (info "(emacs) Crashing") - that was
the first info entry mentioned in this thread!

Still, not a lot of the useful stuff Óscar
Fuentes posted there, either.

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 16:21:17 +0200
> 
> > There is already a section called "When Emacs
> > Crashes".
> 
> Ah, right, (info "(emacs) Crashing") - that was
> the first info entry mentioned in this thread!
> 
> Still, not a lot of the useful stuff Óscar
> Fuentes posted there, either.

Which brings us right to the beginning: users aren't requested to
debug problems, only report as much useful details as possible.  The
backtrace output by Emacs is such a detail.

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

> Which brings us right to the beginning: users
> aren't requested to debug problems, only
> report as much useful details as possible.
> The backtrace output by Emacs is such
> a detail.

Users are not requested to do anything, they do
exactly what they want, and some of them might
_want_ to do it, and the documentation should
therefore be more clear on how to use GDB in
the most basic way, is what I'm saying.
Mr. Fuentes just provided a good list with
example commands. Why not use it?

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 16:57:25 +0200
> 
> Eli Zaretskii wrote:
> 
> > Which brings us right to the beginning: users
> > aren't requested to debug problems, only
> > report as much useful details as possible.
> > The backtrace output by Emacs is such
> > a detail.
> 
> Users are not requested to do anything, they do
> exactly what they want, and some of them might
> _want_ to do it, and the documentation should
> therefore be more clear on how to use GDB in
> the most basic way, is what I'm saying.
> Mr. Fuentes just provided a good list with
> example commands. Why not use it?

So you insist on another circle, although we've made a full one
already?

Re: Fatal error 11: Segmentation Fault

[Emanuel Berg]

Eli Zaretskii wrote:

> So you insist on another circle, although
> we've made a full one already?

You are such a pleasant guy to talk to!
Only perhaps we could call it a
"vicious circle" instead, as an ironic remark
I mean?

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

Re: Fatal error 11: Segmentation Fault

[Eli Zaretskii]

> From: Emanuel Berg <moasenwood@zoho.eu>
> Date: Wed, 03 Apr 2019 23:05:59 +0200
> 
> Eli Zaretskii wrote:
> 
> > So you insist on another circle, although
> > we've made a full one already?
> 
> You are such a pleasant guy to talk to!

This kind of remark goes both ways, you know.

> Only perhaps we could call it a "vicious circle" instead

I thought by not calling it that I'd appear more pleasant, but it
sounds like I'm damned if I do and damned if I don't.