bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Dmitry Gutov]

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

Possibly as a result of some recent ivy-mode update, Emacs crashes quite
promptly when I use it. I've tried going back a couple of days in Emacs
revisions, and the problem is also there.

Here are a few xbacktrace-s (I think 3-5 are from an earlier revision,
but 1-2 should be from this one). Let me know if 'bt full' is needed.
I'll be doing 'git bisect' next.

highlight-tail-mode features in some of them, too, but it's fairly
stable when not in conjunction with ivy-mode. E.g., it's currently
enabled in this email buffer.


[-- Attachment #2: crash1.log --]
[-- Type: text/plain, Size: 1185 bytes --]

Starting program: /home/gutov/vc/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe6848700 (LWP 13562)]
[New Thread 0x7fffe5a21700 (LWP 13563)]
[New Thread 0x7fffe4fed700 (LWP 13564)]
*** Error in `/home/gutov/vc/emacs/src/emacs': corrupted double-linked list: 0x0000000003024c40 ***

Program received signal SIGABRT, Aborted.
0x00007ffff14a5267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
55	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) xbacktrace
"make-hash-table" (0xffff5c20)
"flx-score" (0xffff6478)
0x2d03460 PVEC_COMPILED
"mapcar" (0xffff7218)
"ivy--flx-sort" (0xffff7a80)
"ivy--sort" (0xffff82e0)
"ivy--filter" (0xffff8b30)
"ivy--exhibit" (0xffff9348)
"read-from-minibuffer" (0xffff9c18)
"ivy-read" (0xffffa4f0)
"ivy-completing-read" (0xffffadb0)
"projectile-completing-read" (0xffffb608)
"projectile-find-file" (0xffffbf40)
"funcall-interactively" (0xffffbf38)
0xd3d1f8 PVEC_SUBR
"ad-Advice-call-interactively" (0xffffcb18)
"apply" (0xffffcce8)
"call-interactively" (0xffffd540)
"command-execute" (0xffffdd98)
(gdb)

[-- Attachment #3: crash2.log --]
[-- Type: text/plain, Size: 1178 bytes --]

Starting program: /home/gutov/vc/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe6848700 (LWP 3219)]
[New Thread 0x7fffe5a21700 (LWP 3220)]
[New Thread 0x7fffe4db2700 (LWP 3221)]
emacs: malloc.c:3689: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff14a5267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
55	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) xbacktrace
"make-hash-table" (0xffff5c20)
"flx-score" (0xffff6478)
0x10c20c0 PVEC_COMPILED
"mapcar" (0xffff7218)
"ivy--flx-sort" (0xffff7a80)
"ivy--sort" (0xffff82e0)
"ivy--filter" (0xffff8b30)
"ivy--exhibit" (0xffff9348)
"read-from-minibuffer" (0xffff9c18)
"ivy-read" (0xffffa4f0)
"ivy-completing-read" (0xffffadb0)
"projectile-completing-read" (0xffffb608)
"projectile-find-file" (0xffffbf40)
"funcall-interactively" (0xffffbf38)
0xd3d1f8 PVEC_SUBR
"ad-Advice-call-interactively" (0xffffcb18)
"apply" (0xffffcce8)
"call-interactively" (0xffffd540)
"command-execute" (0xffffdd98)

[-- Attachment #4: crash3.log --]
[-- Type: text/plain, Size: 1040 bytes --]

Starting program: /home/gutov/vc/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe6848700 (LWP 3547)]
[New Thread 0x7fffe5a21700 (LWP 3548)]
[New Thread 0x7fffe4db2700 (LWP 3549)]

dispnew.c:4040: Emacs fatal error: assertion failed: entry || verify_row_hash (row)

Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
370	{
(gdb) xbacktrace
"redisplay_internal (C function)" (0x0)
"redisplay" (0xffff7838)
"sit-for" (0xffff7f80)
"highlight-tail-fade-out-step" (0xffff84a8)
"apply" (0xffff84a0)
"timer-event-handler" (0xffff8cf8)
"read-from-minibuffer" (0xffff9c18)
"ivy-read" (0xffffa4f0)
"ivy-completing-read" (0xffffadb0)
"projectile-completing-read" (0xffffb608)
"projectile-find-file" (0xffffbf40)
"funcall-interactively" (0xffffbf38)
0xd3d1f8 PVEC_SUBR
"ad-Advice-call-interactively" (0xffffcb18)
"apply" (0xffffcce8)
"call-interactively" (0xffffd540)
"command-execute" (0xffffdd98)
(gdb) 

[-- Attachment #5: crash4.log --]
[-- Type: text/plain, Size: 972 bytes --]

Starting program: /home/gutov/vc/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe6848700 (LWP 3999)]
[New Thread 0x7fffe5a21700 (LWP 4000)]
[New Thread 0x7fffe4db2700 (LWP 4001)]
*** Error in `/home/gutov/vc/emacs/src/emacs': realloc(): invalid next size: 0x0000000002ebe520 ***

Program received signal SIGABRT, Aborted.
0x00007ffff14a5267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
55	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) xbacktrace
"read-from-minibuffer" (0xffff9c18)
"ivy-read" (0xffffa4f0)
"ivy-completing-read" (0xffffadb0)
"projectile-completing-read" (0xffffb608)
"projectile-find-file" (0xffffbf40)
"funcall-interactively" (0xffffbf38)
0xd3d1f8 PVEC_SUBR
"ad-Advice-call-interactively" (0xffffcb18)
"apply" (0xffffcce8)
"call-interactively" (0xffffd540)
"command-execute" (0xffffdd98)
(gdb) 

[-- Attachment #6: crash5.log --]
[-- Type: text/plain, Size: 1029 bytes --]

Starting program: /home/gutov/vc/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe6848700 (LWP 5084)]
[New Thread 0x7fffe5a21700 (LWP 5085)]
[New Thread 0x7fffe5220700 (LWP 5086)]

dispnew.c:1204: Emacs fatal error: assertion failed: verify_row_hash (a)

Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
370	{
(gdb) xbacktrace
"redisplay_internal (C function)" (0x0)
"redisplay" (0xffff7838)
"sit-for" (0xffff7f80)
"highlight-tail-fade-out-step" (0xffff84a8)
"apply" (0xffff84a0)
"timer-event-handler" (0xffff8cf8)
"read-from-minibuffer" (0xffff9c18)
"ivy-read" (0xffffa4f0)
"ivy-completing-read" (0xffffadb0)
"projectile-completing-read" (0xffffb608)
"projectile-find-file" (0xffffbf40)
"funcall-interactively" (0xffffbf38)
0xd3d1f8 PVEC_SUBR
"ad-Advice-call-interactively" (0xffffcb18)
"apply" (0xffffcce8)
"call-interactively" (0xffffd540)
"command-execute" (0xffffdd98)
(gdb) 

[-- Attachment #7: Type: text/plain, Size: 773 bytes --]


In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7)
 of 2016-01-12 built on axl
Repository revision: 1f6898d0510cd15455f665c0f38451755a374243
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	Ubuntu 15.10

Configured using:
 'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

bug#22356: Acknowledgement (25.0.50; emacs-25 very crashy with ivy-mode)

[Dmitry Gutov]

Another thing: unlike what one might expect from a crashing Emacs, its 
window does not disappear, but just sits there, until I kill it 
forcibly. So it looks like a freeze.

bug#22356: Acknowledgement (25.0.50; emacs-25 very crashy with ivy-mode)

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 Jan 2016 16:04:26 +0300
> 
> Another thing: unlike what one might expect from a crashing Emacs, its 
> window does not disappear, but just sits there, until I kill it 
> forcibly. So it looks like a freeze.

Now I'm confused: if it freezes, why do the backtraces say that it
aborted?

bug#22356: Acknowledgement (25.0.50; emacs-25 very crashy with ivy-mode)

[Dmitry Gutov]

On 01/12/2016 07:01 PM, Eli Zaretskii wrote:

> Now I'm confused: if it freezes, why do the backtraces say that it
> aborted?

The window is frozen, but gdb shows the error (when I run it through 
gdb), and I can print the backtrace.

If I don't run it through gdb, I just get the "window frozen" effect, 
and I have to kill the process.

bug#22356: Acknowledgement (25.0.50; emacs-25 very crashy with ivy-mode)

[Eli Zaretskii]

> Cc: 22356@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 Jan 2016 19:11:26 +0300
> 
> On 01/12/2016 07:01 PM, Eli Zaretskii wrote:
> 
> > Now I'm confused: if it freezes, why do the backtraces say that it
> > aborted?
> 
> The window is frozen, but gdb shows the error (when I run it through 
> gdb), and I can print the backtrace.
> 
> If I don't run it through gdb, I just get the "window frozen" effect, 
> and I have to kill the process.

At least some of the problems seem to be with corrupted heap memory,
so maybe it's related.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Dmitry Gutov]

On 01/12/2016 03:59 PM, Dmitry Gutov wrote:

> I'll be doing 'git bisect' next.

Went back as far as 2731e821ab157bf71724a4843a9ec67120e88db0 (last 
August), and the problem's still there.

Is my system broken, or something?

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 Jan 2016 17:26:00 +0300
> 
> On 01/12/2016 03:59 PM, Dmitry Gutov wrote:
> 
> > I'll be doing 'git bisect' next.
> 
> Went back as far as 2731e821ab157bf71724a4843a9ec67120e88db0 (last 
> August), and the problem's still there.
> 
> Is my system broken, or something?

I doubt that.  Maybe that ivy-mode update exposed some old bug?  Did
you try to go back the old version of ivy-mode?  If that makes the
problem go away, then perhaps see what are the main differences
between the old and the new, this could give us some hint.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Dmitry Gutov]

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

On 01/12/2016 07:05 PM, Eli Zaretskii wrote:

> I doubt that.  Maybe that ivy-mode update exposed some old bug?  Did
> you try to go back the old version of ivy-mode?

Alas, no. I went back from the version in MELPA to swiper 0.7.0 (it 
includes ivy-mode) which was published to GNU ELPA a month ago.

Still getting the problem. It seemed gone for the first few minutes, but 
after I restarted Emacs, and repeated the familiar steps (navigate to 
~/vc/emacs, invoke projectile-find-file with ivy used as the 
completing-read function, then type vc-hg, and maybe backspace over that 
g and type it again a few times), the problem is here again.

(Other people should be able to reproduce this by installing swiper, 
enabling ivy-mode, and calling M-x project-find-file).

The error also still happens in different places. Here's the latest one:

Starting program: /home/gutov/vc/emacs/src/emacs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe6848700 (LWP 9356)]
[New Thread 0x7fffe5a21700 (LWP 9357)]
[New Thread 0x7fffe5220700 (LWP 9358)]
*** Error in `/home/gutov/vc/emacs/src/emacs': free(): invalid pointer: 
0x00000000029d5c40 ***

Program received signal SIGABRT, Aborted.
0x00007ffff14a5267 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
55	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) xbacktrace
"Automatic GC" (0x0)
"put-text-property" (0xffffbf78)
"ivy--format" (0xffffc128)
"ivy--exhibit" (0xffffc2c0)
"read-from-minibuffer" (0xffffc838)
"ivy-read" (0xffffca80)
"ivy-completing-read" (0xffffcbe0)
"if" (0xffffcd88)
"cond" (0xffffce68)
"let" (0xffffcfb8)
"projectile-completing-read" (0xffffd0c0)
"let" (0xffffd2d8)
"projectile-find-file" (0xffffd550)
"funcall-interactively" (0xffffd548)
0xb33578 PVEC_SUBR
"ad-Advice-call-interactively" (0xffffd988)
"apply" (0xffffdaf8)
"call-interactively" (0xffffdcc0)
"command-execute" (0xffffde68)
(gdb)

Sometimes, I'm also getting a graphical glitch in the minibuffer: one or 
few "character not found" glyphs flickering against the right window 
border right before the crash.

Screenshot attached.

[-- Attachment #2: Screenshot from 2016-01-12 19-42-05.png --]
[-- Type: image/png, Size: 180566 bytes --]

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Eli Zaretskii]

> Cc: 22356@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 Jan 2016 19:48:42 +0300
> 
> > I doubt that.  Maybe that ivy-mode update exposed some old bug?  Did
> > you try to go back the old version of ivy-mode?
> 
> Alas, no. I went back from the version in MELPA to swiper 0.7.0 (it 
> includes ivy-mode) which was published to GNU ELPA a month ago.

Was anything else on your system updated lately?  Some library,
perhaps, or some system component?  The problems look quite basic, for
example this:

> Starting program: /home/gutov/vc/emacs/src/emacs
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffe6848700 (LWP 9356)]
> [New Thread 0x7fffe5a21700 (LWP 9357)]
> [New Thread 0x7fffe5220700 (LWP 9358)]
> *** Error in `/home/gutov/vc/emacs/src/emacs': free(): invalid pointer: 
> 0x00000000029d5c40 ***
> 
> Program received signal SIGABRT, Aborted.
> 0x00007ffff14a5267 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:55
> 55	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

means that glibc detected an invalid pointer being passed to 'free'.
It's glibc which raises SIGABRT here, AFAIU, and it does that because
if that invalid 'free' call.

> Sometimes, I'm also getting a graphical glitch in the minibuffer: one or 
> few "character not found" glyphs flickering against the right window 
> border right before the crash.

When heap memory is corrupted, anything can happen.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Dmitry Gutov]

On 01/12/2016 09:33 PM, Eli Zaretskii wrote:

> Was anything else on your system updated lately?  Some library,
> perhaps, or some system component?

Only minor updates, as far as I know. I'm on Ubuntu 15.10, which is the 
current stable, but not LTS, distribution. In the last few days, I've 
updated from kernel 4.2.0-22 to 4.2.0-23.

But I've rebooted into the previous version now (it's kept as backup), 
and the problem is still there.

Other applications, however, haven't suddenly become all crashy, 
however. And I use a few (web browser, email client, file manager, video 
player, torrent client). On the sum, they must be more complex than 
Emacs, and they also use libc, I suppose.

 > The problems look quite basic, for
> example this:
>> Program received signal SIGABRT, Aborted.
>> 0x00007ffff14a5267 in __GI_raise (sig=sig@entry=6) at
>> ../sysdeps/unix/sysv/linux/raise.c:55
>> 55	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>
> means that glibc detected an invalid pointer being passed to 'free'.
> It's glibc which raises SIGABRT here, AFAIU, and it does that because
> if that invalid 'free' call.

Yes. Another thing I've noticed is that problems sort of clustered by 
type: if I start Emacs many times and repeat the same process, similar 
backtraces could show up for a few times in a row, then change to a 
different kind of error (also repeated a few times), then back...

Another piece of the puzzle: if I run emacs -Q -L <paths to the few 
packages I thought to be responsible: ivy, flx, highlight-tail>, 
recreate ivy's configuration and try it again, the problem doesn't show.

Going to bisect my configuration now.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Dmitry Gutov]

On 01/13/2016 01:27 AM, Dmitry Gutov wrote:

> Going to bisect my configuration now.

...goddammit. Here's the new bit of configuration I added to my init 
file while answering a user's question [0] and promptly forgot about:

(setq-default right-margin-width 2)

It needs another piece, which I had before:

(defun scale-default-face ()
   (setq-local face-remapping-alist '((default :height 1.05))))

(add-hook 'minibuffer-setup-hook 'scale-default-face)

With that, you don't even need ivy-mode to cause memory corruption.

Try this:

- Put those lines in the init file and restart Emacs, or even evaluate 
them in *scratch*.

- Open minibuffer, and put newline in there:

   M-: C-q C-j

Repeat the last command until Emacs freezes (takes 2-10 newlines here).

[0] https://github.com/dgutov/diff-hl/issues/61

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

[snip]

> Repeat the last command until Emacs freezes (takes 2-10 newlines here).

Reproduced with

GNU Emacs 25.0.50.27 (x86_64-unknown-linux-gnu, X toolkit) of 2015-12-30

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Óscar Fuentes]

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

>> Repeat the last command until Emacs freezes (takes 2-10 newlines here).
>
> Reproduced with
>
> GNU Emacs 25.0.50.27 (x86_64-unknown-linux-gnu, X toolkit) of 2015-12-30

But it seems to work fine on

GNU Emacs 25.0.50.1 (i686-w64-mingw32) of 2015-05-13 on CAB8

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Dmitry Gutov]

On 01/13/2016 04:15 AM, Óscar Fuentes wrote:

>> Reproduced with
>>
>> GNU Emacs 25.0.50.27 (x86_64-unknown-linux-gnu, X toolkit) of 2015-12-30

Thanks!

> But it seems to work fine on
>
> GNU Emacs 25.0.50.1 (i686-w64-mingw32) of 2015-05-13 on CAB8

I haven't tried this version exactly, but I can reproduce it in Emacs 
24.5 release, too.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> But it seems to work fine on
>>
>> GNU Emacs 25.0.50.1 (i686-w64-mingw32) of 2015-05-13 on CAB8
>
> I haven't tried this version exactly, but I can reproduce it in Emacs
> 24.5 release, too.

On that Windows install I can type C-q C-j on the minibuffer many times
without problem (on the GNU/Linux Emacs freezes after the second C-q
C-j). However, Emacs crashes while exiting when the window's decoration
Close button is clicked.

The many faces of memory corruption.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 13 Jan 2016 02:36:26 +0100
> Cc: 22356@debbugs.gnu.org
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> >> But it seems to work fine on
> >>
> >> GNU Emacs 25.0.50.1 (i686-w64-mingw32) of 2015-05-13 on CAB8
> >
> > I haven't tried this version exactly, but I can reproduce it in Emacs
> > 24.5 release, too.
> 
> On that Windows install I can type C-q C-j on the minibuffer many times
> without problem (on the GNU/Linux Emacs freezes after the second C-q
> C-j). However, Emacs crashes while exiting when the window's decoration
> Close button is clicked.
> 
> The many faces of memory corruption.

We weren't assigning space for glyphs of the margins in the
mini-window.  Why? because of a single typo (or thinko?) more than 2
years ago!  That typo made us think the mini-window has a very large
total width in column units:

  emacs -Q
  M-: (window-total-width (minibuffer-window)) RET
    => 672

That preposterous value then defeated the logic in the display engine
which decides how many glyphs are needed for displaying stuff in the
margin, when margins are turned on in a window: that logic decided the
correct number was zero.  And from there it's a quick path to writing
beyond the allocated memory.

Should be fixed now on the emacs-25 branch.  But since the phenomena I
saw on my system are different from what was reported here, please
make sure your problems are also solved, not just mine.

Thanks.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[martin rudalics]

 > We weren't assigning space for glyphs of the margins in the
 > mini-window.  Why? because of a single typo (or thinko?) more than 2
 > years ago!  That typo made us think the mini-window has a very large
 > total width in column units:
 >
 >    emacs -Q
 >    M-: (window-total-width (minibuffer-window)) RET
 >      => 672
 >
 > That preposterous value then defeated the logic in the display engine
 > which decides how many glyphs are needed for displaying stuff in the
 > margin, when margins are turned on in a window: that logic decided the
 > correct number was zero.  And from there it's a quick path to writing
 > beyond the allocated memory.

Thanks for fixing my silly oversight.  margin_glyphs_to_reserve is the
only client of the total_cols slot of the minibuffer window, so there's
no wonder that this bug remained undetected for such a long time.

martin

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Eli Zaretskii]

> Date: Sat, 16 Jan 2016 10:22:53 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 22356@debbugs.gnu.org
> 
>  > We weren't assigning space for glyphs of the margins in the
>  > mini-window.  Why? because of a single typo (or thinko?) more than 2
>  > years ago!  That typo made us think the mini-window has a very large
>  > total width in column units:
>  >
>  >    emacs -Q
>  >    M-: (window-total-width (minibuffer-window)) RET
>  >      => 672
>  >
>  > That preposterous value then defeated the logic in the display engine
>  > which decides how many glyphs are needed for displaying stuff in the
>  > margin, when margins are turned on in a window: that logic decided the
>  > correct number was zero.  And from there it's a quick path to writing
>  > beyond the allocated memory.
> 
> Thanks for fixing my silly oversight.

Stuff happens ;-)

> margin_glyphs_to_reserve is the only client of the total_cols slot
> of the minibuffer window, so there's no wonder that this bug
> remained undetected for such a long time.

margin_glyphs_to_reserve also had a flaw: it could return zero for
positive values of the MARGIN argument, which is clearly wrong.  I
fixed that with a follow-up patch, so now it always returns at least 1
column when the margin is non-zero.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 13 Jan 2016 02:36:26 +0100
> Cc: 22356@debbugs.gnu.org
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> >> But it seems to work fine on
> >>
> >> GNU Emacs 25.0.50.1 (i686-w64-mingw32) of 2015-05-13 on CAB8
> >
> > I haven't tried this version exactly, but I can reproduce it in Emacs
> > 24.5 release, too.
> 
> On that Windows install I can type C-q C-j on the minibuffer many times
> without problem (on the GNU/Linux Emacs freezes after the second C-q
> C-j). However, Emacs crashes while exiting when the window's decoration
> Close button is clicked.
> 
> The many faces of memory corruption.

We weren't assigning space for glyphs of the margins in the
mini-window.  Why? because of a single typo (or thinko?) more than 2
years ago!  That typo made us think the mini-window has a very large
total width in column units:

  emacs -Q
  M-: (window-total-width (minibuffer-window)) RET
    => 672

That preposterous value then defeated the logic in the display engine
which decides how many glyphs are needed for displaying stuff in the
margin, when margins are turned on in a window: that logic decided the
correct number was zero.  And from there it's a quick path to writing
beyond the allocated memory.

Should be fixed now on the emacs-25 branch.  But since the phenomena I
saw on my system are different from what was reported here, please
make sure your problems are also solved, not just mine.

Thanks.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Should be fixed now on the emacs-25 branch.  But since the phenomena I
> saw on my system are different from what was reported here, please
> make sure your problems are also solved, not just mine.

No longer reproducible on

GNU Emacs 25.0.50.28 (x86_64-unknown-linux-gnu, X toolkit) of 2016-01-15

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  22356@debbugs.gnu.org
> Date: Fri, 15 Jan 2016 17:06:21 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Should be fixed now on the emacs-25 branch.  But since the phenomena I
> > saw on my system are different from what was reported here, please
> > make sure your problems are also solved, not just mine.
> 
> No longer reproducible on
> 
> GNU Emacs 25.0.50.28 (x86_64-unknown-linux-gnu, X toolkit) of 2016-01-15

Thanks.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Dmitry Gutov]

On 01/15/2016 06:24 PM, Eli Zaretskii wrote:

> We weren't assigning space for glyphs of the margins in the
> mini-window.  Why? because of a single typo (or thinko?) more than 2
> years ago!  That typo made us think the mini-window has a very large
> total width in column units:

Columns-to-pixels conversion, huh?

> Should be fixed now on the emacs-25 branch.  But since the phenomena I
> saw on my system are different from what was reported here, please
> make sure your problems are also solved, not just mine.

Thanks, Eli. Looks fixed here too.

bug#22356: 25.0.50; emacs-25 very crashy with ivy-mode

[Eli Zaretskii]

> Cc: 22356-done@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 16 Jan 2016 01:47:08 +0300
> 
> On 01/15/2016 06:24 PM, Eli Zaretskii wrote:
> 
> > We weren't assigning space for glyphs of the margins in the
> > mini-window.  Why? because of a single typo (or thinko?) more than 2
> > years ago!  That typo made us think the mini-window has a very large
> > total width in column units:
> 
> Columns-to-pixels conversion, huh?

We used a value that could be in pixels to initialize the columns,
yes.  But only for mini-windows!

> > Should be fixed now on the emacs-25 branch.  But since the phenomena I
> > saw on my system are different from what was reported here, please
> > make sure your problems are also solved, not just mine.
> 
> Thanks, Eli. Looks fixed here too.

Great, thanks for testing.