bug#27115: Infinite loop created by fixing 26097

bug#27115: Infinite loop created by fixing 26097

[Codrut Gusoi]

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

Hello,

After bug 26097 was fixed I started using emacs built from soruce from
the master branch. There I encountered a but that only recently I
traced back to 8275687bb908174b84021ee15ecd959733cecb9d with a git
bisect.

Here are some high level details:

1) I am using Spacemacs
(https://github.com/sdwolf/spacemacs/tree/develop) with evil and helm.
2) I have linum active.
3) I press "M-x" which is bound to (helm-M-x). This opens helm and
triggers something called "Auto Evilification". Somewhere in this
process the following message is displayed:

```
Auto-evilification could not remap these functions in map ‘edebug-mode-map’:
   - ‘edebug-Go-nonstop-mode’ originally mapped on ‘G’
```

This is a single string with multiple "\n" inside it that can be
generated by the following code (extracted from Spacemacs):

```
(setq my-map-symbol 'edebug-mode-map)
(setq my-pending-funcs '((edebug-Go-nonstop-mode . 71)))
(message (concat (format (concat "Auto-evilification could not remap
these " "functions in map `%s': \n") my-map-symbol) (mapconcat (lambda
(x) (format " - `%s' originally mapped on `%s'" (car x)
(single-key-description (cdr x)))) my-pending-funcs "\n")))
```

4) After the above message is displayed emacs freezes.
5) If i do a "pkill -USR2 emacs" I get a backtrace that looks like the
attached file. I can not paste it because it contains some nulls (^@)
and it gets truncated.

6) I did a git bisect and it led me to this commit:
8275687bb908174b84021ee15ecd959733cecb9d, the first attempt at fixing
26097, later edited by a749b55d8ee530797ccff693ad302541257d0415.

7) If I remove the "\n" from the message, making it a single line, the
problem no longer appears. Also if I disable linum in the currently
open buffer then there is no problem with the multi line message.

Here is a reference to the github issue in which I, and a few more
people discuss about this bug.

I can provide a VM for you to ssh into and reproduce the bug with my
setup. Just email me privately so I can give you the ssh details. Also
let me know if you need any more details from me. I will try to answer
as quickly as possible.

Thank you,
Codrut

[-- Attachment #2: debug --]
[-- Type: application/octet-stream, Size: 85964 bytes --]

bug#27115: Infinite loop created by fixing 26097

[Eli Zaretskii]

> From: Codrut Gusoi <codrut.gusoi@gmail.com>
> Date: Sun, 28 May 2017 14:39:42 +0300
> 
> After bug 26097 was fixed I started using emacs built from soruce from
> the master branch. There I encountered a but that only recently I
> traced back to 8275687bb908174b84021ee15ecd959733cecb9d with a git
> bisect.
> 
> Here are some high level details:
> 
> 1) I am using Spacemacs
> (https://github.com/sdwolf/spacemacs/tree/develop) with evil and helm.
> 2) I have linum active.
> 3) I press "M-x" which is bound to (helm-M-x). This opens helm and
> triggers something called "Auto Evilification". Somewhere in this
> process the following message is displayed:
> 
> ```
> Auto-evilification could not remap these functions in map ‘edebug-mode-map’:
>    - ‘edebug-Go-nonstop-mode’ originally mapped on ‘G’
> ```
> 
> This is a single string with multiple "\n" inside it that can be
> generated by the following code (extracted from Spacemacs):
> 
> ```
> (setq my-map-symbol 'edebug-mode-map)
> (setq my-pending-funcs '((edebug-Go-nonstop-mode . 71)))
> (message (concat (format (concat "Auto-evilification could not remap
> these " "functions in map `%s': \n") my-map-symbol) (mapconcat (lambda
> (x) (format " - `%s' originally mapped on `%s'" (car x)
> (single-key-description (cdr x)))) my-pending-funcs "\n")))
> ```
> 
> 4) After the above message is displayed emacs freezes.

Is this in a GUI frame or a text-mode frame?

> Here is a reference to the github issue in which I, and a few more
> people discuss about this bug.

I think you forgot to include the reference.

Thanks.

bug#27115: Fwd: bug#27115: Infinite loop created by fixing 26097

[Codrut Gusoi]

Ups, sorry about that, the reference is:
https://github.com/syl20bnr/spacemacs/issues/8654

This is in text mode (inside a terminal emulator).

On Sun, May 28, 2017 at 6:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Codrut Gusoi <codrut.gusoi@gmail.com>
>> Date: Sun, 28 May 2017 14:39:42 +0300
>>
>> After bug 26097 was fixed I started using emacs built from soruce from
>> the master branch. There I encountered a but that only recently I
>> traced back to 8275687bb908174b84021ee15ecd959733cecb9d with a git
>> bisect.
>>
>> Here are some high level details:
>>
>> 1) I am using Spacemacs
>> (https://github.com/sdwolf/spacemacs/tree/develop) with evil and helm.
>> 2) I have linum active.
>> 3) I press "M-x" which is bound to (helm-M-x). This opens helm and
>> triggers something called "Auto Evilification". Somewhere in this
>> process the following message is displayed:
>>
>> ```
>> Auto-evilification could not remap these functions in map ‘edebug-mode-map’:
>>    - ‘edebug-Go-nonstop-mode’ originally mapped on ‘G’
>> ```
>>
>> This is a single string with multiple "\n" inside it that can be
>> generated by the following code (extracted from Spacemacs):
>>
>> ```
>> (setq my-map-symbol 'edebug-mode-map)
>> (setq my-pending-funcs '((edebug-Go-nonstop-mode . 71)))
>> (message (concat (format (concat "Auto-evilification could not remap
>> these " "functions in map `%s': \n") my-map-symbol) (mapconcat (lambda
>> (x) (format " - `%s' originally mapped on `%s'" (car x)
>> (single-key-description (cdr x)))) my-pending-funcs "\n")))
>> ```
>>
>> 4) After the above message is displayed emacs freezes.
>
> Is this in a GUI frame or a text-mode frame?
>
>> Here is a reference to the github issue in which I, and a few more
>> people discuss about this bug.
>
> I think you forgot to include the reference.
>
> Thanks.

bug#27115: Infinite loop created by fixing 26097

[Eli Zaretskii]

> From: Codrut Gusoi <codrut.gusoi@gmail.com>
> Date: Sun, 28 May 2017 14:39:42 +0300
> 
> 1) I am using Spacemacs
> (https://github.com/sdwolf/spacemacs/tree/develop) with evil and helm.
> 2) I have linum active.
> 3) I press "M-x" which is bound to (helm-M-x). This opens helm and
> triggers something called "Auto Evilification". Somewhere in this
> process the following message is displayed:
> 
> ```
> Auto-evilification could not remap these functions in map ‘edebug-mode-map’:
>    - ‘edebug-Go-nonstop-mode’ originally mapped on ‘G’
> ```
> 
> This is a single string with multiple "\n" inside it that can be
> generated by the following code (extracted from Spacemacs):
> 
> ```
> (setq my-map-symbol 'edebug-mode-map)
> (setq my-pending-funcs '((edebug-Go-nonstop-mode . 71)))
> (message (concat (format (concat "Auto-evilification could not remap
> these " "functions in map `%s': \n") my-map-symbol) (mapconcat (lambda
> (x) (format " - `%s' originally mapped on `%s'" (car x)
> (single-key-description (cdr x)))) my-pending-funcs "\n")))
> ```
> 
> 4) After the above message is displayed emacs freezes.

This seems to be due to a bug in Spacemacs's customization of
linum-mode.  The details are below, but first 2 possible workarounds:

Workaround #1: set resize-mini-windows to nil.
Workaround #2: Remove the after-advice from linum-update-window:

  M-: (advice-remove 'linum-update-window 'spacemacs//linum-update-window-scale-fix) RET

Details:

The problem starts with linum's linum-after-scroll function, which is
installed in the window-scroll-functions hook, called by redisplay.
linum-after-scroll calls linum-update, which calls
linum-update-window, which decides, in the above scenario, to set the
window's left margin width to 3.  On a TTY, this requires adjustment
of the frame's glyph matrices, which causes the frame's garbaged flag
to become set.

This alone would not have caused redisplay to infloop, because the
next redisplay retry would find the window's margins already set to the
correct value, and would not require adjustment of frame's glyph
matrices.  However, Spacemacs installs an after-advice for
linum-update-window, which in this scenario resets the margin width
back to 1.  So, the next redisplay retry will again try to enlarge the
margin width to 3, which will cause the frame's garbaged flag to be
set, etc. etc., ad nauseam.

I think the bug is in Spacemacs's advice function, but I have no clear
understanding what it tries to do, and why in this case it decides to
reset the margin width to 1.

So I installed a band-aid, which will discontinue the retries after a
few attempts, just so Emacs remains usable.  Note that in the above
scenario this causes the frame's display to be slightly incorrect: the
mode line of one of the windows is not redrawn.  I'm deliberately not
going to try to fix this, because I think the underlying bug is in
Spacemacs, and should be fixed there.

Last, but not least: thank you for giving me a login on your system
and arranging for a very easy reproduction of the problem.  This made
debugging very easy.

I'll leave this bug open, in case followup discussions bring up
additional issues or better ideas for fixing this scenario.

bug#27115: Infinite loop created by fixing 26097

[Eli Zaretskii]

> Date: Wed, 31 May 2017 12:26:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 27115@debbugs.gnu.org
> 
> I'll leave this bug open, in case followup discussions bring up
> additional issues or better ideas for fixing this scenario.

Given the conclusions in the discussion of the Spacemacs issue at
https://github.com/syl20bnr/spacemacs/issues/8654, I understand that
the bug was identified and fixed, so I'm closing this bug report.