bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

Hello,

I have started seeing this crash in the past week I believe.

The crash happens when I randomly minimize/maximize the Emacs frame by
clicking on its tab in the OS taskbar. I am using RHEL 6.8.

I have yet to find a good recipe to recreate this programmatically.

xdisp.c:21236: Emacs fatal error: assertion failed: it->glyph_row == NULL
|| it->glyph_row->used[TEXT_AREA] == 0

Backtrace:
emacs[0x5bd0c2]

...

emacs[0x592ea5]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x32f4c1ed1d]

I'll next attempt to recreate this from gdb.

Here is my Emacs build information.

Emacs version: GNU Emacs 27.0.50 (build 11, x86_64-pc-linux-gnu, GTK+
Version 2.24.23)
 of 2018-07-23, built using commit 57c4bc146b7e17b6f662604047cb5d10982f962c.

./configure options:
  --with-modules --prefix=/home/kmodi/usr_local/apps/6/emacs/master
'--program-transform-name=s/^ctags$/ctags_emacs/'
--enable-checking=yes,glyphs --enable-check-lisp-object-type
'CPPFLAGS=-I/home/kmodi/usr_local/6/include -I/usr/include/freetype2
-I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0'
'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64
-ggdb3'

Features:
  XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK2 X11 MODULES THREADS

-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1803 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

I need some help getting started with ignoring initial errors in gdb.
Things seem to have changed from what I have in my notes.

From my notes, after:

    break Fsignal
    r -Q

Below worked:

Breakpoint 3, Fsignal (error_symbol=41328, data=16185859) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) p error_symbol
$1 = 41328
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0xc85aa0 <lispsym+41328>
"scan-error"
(gdb) condition 3 error_symbol!=41328
(gdb) c

But now, I am getting this breakpoint:

Starting program: /home/kmodi/downloads/git/emacs/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffed1b3700 (LWP 30703)]

(emacs:30702): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed

Thread 1 "emacs" hit Breakpoint 3, Fsignal (error_symbol=XIL(0xd980),
data=XIL(0x127f163))
    at eval.c:1582
1582      signal_or_quit (error_symbol, data, false);
(gdb) r -Q
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) p error_symbol
$1 = XIL(0xd980)
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0xe1b2c0 <lispsym+55680>
"void-variable"
(gdb) condition 3 error_symbol!=XIL(0xd980)
(gdb) c
Continuing.
Error in testing breakpoint condition:
Structure has no component named operator!=.
Error in testing breakpoint condition:
Structure has no component named operator!=.

Thread 1 "emacs" hit Breakpoint 3, Fsignal (error_symbol=XIL(0xd980),
data=XIL(0x1284653))
    at eval.c:1582
1582      signal_or_quit (error_symbol, data, false);
(gdb) condition 3 error_symbol!=0xd980
(gdb) c
Continuing.
Error in testing breakpoint condition:
Structure has no component named operator!=.
Error in testing breakpoint condition:
Structure has no component named operator!=.

Thread 1 "emacs" hit Breakpoint 3, Fsignal (error_symbol=XIL(0xd980),
data=XIL(0x12838e3))
    at eval.c:1582
1582      signal_or_quit (error_symbol, data, false);
(gdb) condition 3 error_symbol!=55680
(gdb) c
Continuing.
Error in testing breakpoint condition:
Structure has no component named operator!=.

Thread 1 "emacs" hit Breakpoint 3, Fsignal (error_symbol=XIL(0xd980),
data=XIL(0x1282ca3))
    at eval.c:1582
1582      signal_or_quit (error_symbol, data, false);

So, what would be the right way to ignore that hex error_symbol code?
Earlier that code was in decimal. But now it is in hex.

As seen above, none of the below works:
- condition 3 error_symbol!=XIL(0xd980)   -- What is XIL?
- condition 3 error_symbol!=0xd980
- condition 3 error_symbol!=55680

Thanks.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3404 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Noam Postavsky]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Thread 1 "emacs" hit Breakpoint 3, Fsignal (error_symbol=XIL(0xd980),
> data=XIL(0x127f163))
>     at eval.c:1582
> 1582      signal_or_quit (error_symbol, data, false);
> (gdb) r -Q
> The program being debugged has been started already.
> Start it from the beginning? (y or n) n
> Program not restarted.
> (gdb) p error_symbol
> $1 = XIL(0xd980)
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0xe1b2c0 <lispsym+55680>
> "void-variable"
> (gdb) condition 3 error_symbol!=XIL(0xd980)
> (gdb) c
> Continuing.
> Error in testing breakpoint condition:
> Structure has no component named operator!=.
> Error in testing breakpoint condition:
> Structure has no component named operator!=.

This works for me:

    condition 3 !EQ (error_symbol, XIL(0xd980))

Using $1 instead of XIL(0xd980) also works (and in this case,
Qvoid_variable is an option too).

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

Hello Noam,

On Tue, Jul 24, 2018 at 9:52 AM Noam Postavsky <npostavs@gmail.com> wrote:

>
> This works for me:
>
>     condition 3 !EQ (error_symbol, XIL(0xd980))
>
> Using $1 instead of XIL(0xd980) also works (and in this case,
> Qvoid_variable is an option too).
>

Thank you. That helped! Looks like some update in gdb invalidated the "!="
operator? Need to update my notes ..

Now I am just waiting for that crash to happen again.. so that I can post
the backtrace.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 926 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 24 Jul 2018 09:36:10 -0400
> 
> I need some help getting started with ignoring initial errors in gdb. Things seem to have changed from what I
> have in my notes.
> 
> From my notes, after:
> 
>     break Fsignal
>     r -Q
> 
> Below worked:
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=16185859) at eval.c:1471
> 1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) p error_symbol
> $1 = 41328
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0xc85aa0 <lispsym+41328>
> "scan-error"
> (gdb) condition 3 error_symbol!=41328
> (gdb) c
> 
> But now, I am getting this breakpoint:

You don't need to set breakpoints when you know Emacs will crash (or
abort due to an assertion violation, which has the same effect).  Just
run Emacs, and when the assertion violation happens, GDB will kick in
automatically, and you will be able to display the C backtrace, look
at related variables, etc.

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

Hello Eli,

On Tue, Jul 24, 2018 at 10:39 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> You don't need to set breakpoints when you know Emacs will crash (or
> abort due to an assertion violation, which has the same effect).  Just
> run Emacs, and when the assertion violation happens, GDB will kick in
> automatically, and you will be able to display the C backtrace, look
> at related variables, etc.
>

Thanks. I did not know that. I was just living by my notes. The only time I
use gdb is to report Emacs bugs.

But now that I have emacs running through gdb, I am failing to get that
crash.. and without that, I got that crash 4 times since yesterday (and 2-3
times in the past week).

I use emacsclient by default. But in gdb I run ./emacs. Based on the
assertion failure in:

,-------- #21236 -- /home/kmodi/downloads/git/emacs/src/xdisp.c ---
| eassert (it->glyph_row == NULL || it->glyph_row->used[TEXT_AREA] == 0);
`-------- #21236 -- 2018/07/24 -- kmodi

would that make any difference?

If yes, how do I run emacsclient from gdb?
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1605 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 24 Jul 2018 11:55:54 -0400
> Cc: 32258@debbugs.gnu.org
> 
> But now that I have emacs running through gdb, I am failing to get that crash.. and without that, I got that crash
> 4 times since yesterday (and 2-3 times in the past week).
> 
> I use emacsclient by default. But in gdb I run ./emacs. Based on the assertion failure in:
> 
> ,-------- #21236 -- /home/kmodi/downloads/git/emacs/src/xdisp.c ---
> | eassert (it->glyph_row == NULL || it->glyph_row->used[TEXT_AREA] == 0);
> `-------- #21236 -- 2018/07/24 -- kmodi
> 
> would that make any difference?
> 
> If yes, how do I run emacsclient from gdb?

What exactly do you mean by "use emacsclient by default"?  Does
emacsclient start Emacs, or do you start Emacs as a daemon (or maybe
normally)?

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

On Tue, Jul 24, 2018 at 2:17 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> What exactly do you mean by "use emacsclient by default"?  Does
> emacsclient start Emacs, or do you start Emacs as a daemon (or maybe
> normally)?
>

I start Emacs using "emacsclient -a '' -n -c" when launching the first
time, and then onwards using "emacsclient -a '' -n". I do this via a
wrapper script[1].

[1]: https://gist.github.com/e2512ccd59039c88c15b03cef32b3d4f

-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 989 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 24 Jul 2018 14:26:18 -0400
> Cc: 32258@debbugs.gnu.org
> 
>  What exactly do you mean by "use emacsclient by default"?  Does
>  emacsclient start Emacs, or do you start Emacs as a daemon (or maybe
>  normally)?
> 
> I start Emacs using "emacsclient -a '' -n -c" when launching the first time, and then onwards using
> "emacsclient -a '' -n". I do this via a wrapper script[1].

Then start Emacs via emacsclient as you usually do, and then
immediately attach GDB to it with "gdb -p PID" where PID is the
process ID of the Emacs process (NOT the emacsclient process!).  When
GDB shows its prompt "(gdb)", type "continue RET" to let Emacs
continue to run.  Then do whatever you did before to cause the abort,
and GDB should kick in when you succeed.

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

On Tue, Jul 24, 2018 at 2:55 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Then start Emacs via emacsclient as you usually do, and then
> immediately attach GDB to it with "gdb -p PID" where PID is the
> process ID of the Emacs process (NOT the emacsclient process!).


Thanks. I was able to link gdb to the emacs process (Though, the only
process containing "emacs" string was "emacs --daemon". I believe
emacsclient launches that? I did not find a separate emacsclient process.)


> When GDB shows its prompt "(gdb)", type "continue RET" to let Emacs
> continue to run.  Then do whatever you did before to cause the abort,
> and GDB should kick in when you succeed.
>

I tried minimizing/maximizing the emacs frame quite a few times, but still
no luck making it crash. Very strange.

I think you can stop actively tracking this issue. I will update the issue
when that crash happens again, or just close this bug if no crash happens
in about a week :(.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1609 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 24 Jul 2018 15:04:56 -0400
> Cc: 32258@debbugs.gnu.org
> 
> Thanks. I was able to link gdb to the emacs process (Though, the only process containing "emacs" string was
> "emacs --daemon". I believe emacsclient launches that?

Yes.

> I tried minimizing/maximizing the emacs frame quite a few times, but still no luck making it crash. Very
> strange.

It probably means it's a Heisenbug: it's triggered by some specific
memory layout, and that changes under the debugger.

Are you still able to trigger the abort when running not under GDB?
If that's gone as well, try rebuilding Emacs by touching src/config.h
or somesuch, then try again.

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

On Tue, Jul 24, 2018 at 3:13 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> It probably means it's a Heisenbug: it's triggered by some specific
> memory layout, and that changes under the debugger.
>

Yeah, I hate those kinds of bugs.. I am good for stumbling across those
:P[1]


> Are you still able to trigger the abort when running not under GDB?
>

Sadly, no.

If that's gone as well, try rebuilding Emacs by touching src/config.h
> or somesuch, then try again.
>

Same. The crash is gone.

I'll still leave that emacsclient session running with gdb attached -  I
hope to catch this Heisenbug. Funny, I see like 6-7 crashes in the past
week. And the moment I report it, it gets scared and goes away.


[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29031#35
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1616 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

On Tue, Jul 24, 2018 at 3:35 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

>
> I'll still leave that emacsclient session running with gdb attached -  I
> hope to catch this Heisenbug. Funny, I see like 6-7 crashes in the past
> week. And the moment I report it, it gets scared and goes away.
>

Looks like emacs crashed overnight. On doing bt in gdb, I got this:

(gdb) bt
#0  0x00000032f580f6ab in raise () from /lib64/libpthread.so.0
#1  0x000000000059118c in terminate_due_to_signal (sig=6,
backtrace_limit=2147483647) at emacs.c:399
#2  0x00000000006264e9 in die (msg=0x729930 "it->glyph_row == NULL ||
it->glyph_row->used[TEXT_AREA] == 0",
    file=0x724dfd "xdisp.c", line=21236) at alloc.c:7293
#3  0x0000000000483e19 in maybe_produce_line_number (it=0x7ffea6f395e0) at
xdisp.c:21236
#4  0x000000000048486e in display_line (it=0x7ffea6f395e0, cursor_vpos=24)
at xdisp.c:21459
#5  0x00000000004775d5 in try_window (window=..., pos=..., flags=0) at
xdisp.c:17735
#6  0x0000000000473dc8 in redisplay_window (window=...,
just_this_one_p=false) at xdisp.c:16919
#7  0x000000000046d315 in redisplay_window_0 (window=...) at xdisp.c:14939
#8  0x0000000000649791 in internal_condition_case_1 (bfun=0x46d2d3
<redisplay_window_0>, arg=..., handlers=...,
    hfun=0x46d29b <redisplay_window_error>) at eval.c:1373
#9  0x000000000046d26d in redisplay_windows (window=...) at xdisp.c:14919
#10 0x000000000046d223 in redisplay_windows (window=...) at xdisp.c:14913
#11 0x000000000046bd41 in redisplay_internal () at xdisp.c:14402
#12 0x000000000046c991 in redisplay_preserve_echo_area (from_where=8) at
xdisp.c:14732
#13 0x00000000005ab154 in detect_input_pending_run_timers (do_display=true)
at keyboard.c:9916
#14 0x00000000006b255a in wait_reading_process_output (time_limit=0,
nsecs=0, read_kbd=-1, do_display=true,
    wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at process.c:5521
#15 0x000000000059d358 in kbd_buffer_get_event (kbp=0x7ffea6f3ec38,
used_mouse_menu=0x7ffea6f3f25f, end_time=0x0)
    at keyboard.c:3813
#16 0x0000000000598527 in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7ffea6f3f040,
    used_mouse_menu=0x7ffea6f3f25f) at keyboard.c:2122
#17 0x000000000059881e in read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7ffea6f3f040,
    prev_event=..., used_mouse_menu=0x7ffea6f3f25f) at keyboard.c:2185
#18 0x000000000059a525 in read_char (commandflag=1, map=...,
prev_event=..., used_mouse_menu=0x7ffea6f3f25f,
    end_time=0x0) at keyboard.c:2773
#19 0x00000000005a948d in read_key_sequence (keybuf=0x7ffea6f3f3d0,
prompt=..., dont_downcase_last=false,
    can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9108
#20 0x0000000000596329 in command_loop_1 () at keyboard.c:1338
#21 0x00000000006496ba in internal_condition_case (bfun=0x595edc
<command_loop_1>, handlers=...,
    hfun=0x59555c <cmd_error>) at eval.c:1349
#22 0x0000000000595b0f in command_loop_2 (ignore=...) at keyboard.c:1079
#23 0x0000000000648c14 in internal_catch (tag=..., func=0x595ae6
<command_loop_2>, arg=...) at eval.c:1114
#24 0x0000000000595ab1 in command_loop () at keyboard.c:1058
#25 0x000000000059506e in recursive_edit_1 () at keyboard.c:703
#26 0x0000000000595250 in Frecursive_edit () at keyboard.c:774
#27 0x0000000000592ea5 in main (argc=2, argv=0x7ffea6f3f898) at emacs.c:1722

I cannot tell if it's that same assertion error. But the error seems to
have happened around the same area.. something with glyphs and displaying
line numbers.

I'll leave that gdb open. Let me know what more information I can give you
from that session.

Thanks!
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 4403 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 26 Jul 2018 09:42:35 -0400
> Cc: 32258@debbugs.gnu.org
> 
> (gdb) bt
> #0  0x00000032f580f6ab in raise () from /lib64/libpthread.so.0
> #1  0x000000000059118c in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:399
> #2  0x00000000006264e9 in die (msg=0x729930 "it->glyph_row == NULL || it->glyph_row->used[TEXT_AREA] == 0",
>     file=0x724dfd "xdisp.c", line=21236) at alloc.c:7293
> #3  0x0000000000483e19 in maybe_produce_line_number (it=0x7ffea6f395e0) at xdisp.c:21236
> #4  0x000000000048486e in display_line (it=0x7ffea6f395e0, cursor_vpos=24) at xdisp.c:21459
> #5  0x00000000004775d5 in try_window (window=..., pos=..., flags=0) at xdisp.c:17735
> #6  0x0000000000473dc8 in redisplay_window (window=..., just_this_one_p=false) at xdisp.c:16919
> #7  0x000000000046d315 in redisplay_window_0 (window=...) at xdisp.c:14939
> #8  0x0000000000649791 in internal_condition_case_1 (bfun=0x46d2d3 <redisplay_window_0>, arg=...,
> handlers=...,
>     hfun=0x46d29b <redisplay_window_error>) at eval.c:1373
> #9  0x000000000046d26d in redisplay_windows (window=...) at xdisp.c:14919
> #10 0x000000000046d223 in redisplay_windows (window=...) at xdisp.c:14913
> #11 0x000000000046bd41 in redisplay_internal () at xdisp.c:14402
> #12 0x000000000046c991 in redisplay_preserve_echo_area (from_where=8) at xdisp.c:14732
> #13 0x00000000005ab154 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9916
> #14 0x00000000006b255a in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1,
> do_display=true,
>     wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at process.c:5521
> #15 0x000000000059d358 in kbd_buffer_get_event (kbp=0x7ffea6f3ec38,
> used_mouse_menu=0x7ffea6f3f25f, end_time=0x0)
>     at keyboard.c:3813
> #16 0x0000000000598527 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7ffea6f3f040,
>     used_mouse_menu=0x7ffea6f3f25f) at keyboard.c:2122
> #17 0x000000000059881e in read_decoded_event_from_main_queue (end_time=0x0,
> local_getcjmp=0x7ffea6f3f040,
>     prev_event=..., used_mouse_menu=0x7ffea6f3f25f) at keyboard.c:2185
> #18 0x000000000059a525 in read_char (commandflag=1, map=..., prev_event=...,
> used_mouse_menu=0x7ffea6f3f25f,
>     end_time=0x0) at keyboard.c:2773
> #19 0x00000000005a948d in read_key_sequence (keybuf=0x7ffea6f3f3d0, prompt=...,
> dont_downcase_last=false,
>     can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9108
> #20 0x0000000000596329 in command_loop_1 () at keyboard.c:1338
> #21 0x00000000006496ba in internal_condition_case (bfun=0x595edc <command_loop_1>, handlers=...,
>     hfun=0x59555c <cmd_error>) at eval.c:1349
> #22 0x0000000000595b0f in command_loop_2 (ignore=...) at keyboard.c:1079
> #23 0x0000000000648c14 in internal_catch (tag=..., func=0x595ae6 <command_loop_2>, arg=...) at
> eval.c:1114
> #24 0x0000000000595ab1 in command_loop () at keyboard.c:1058
> #25 0x000000000059506e in recursive_edit_1 () at keyboard.c:703
> #26 0x0000000000595250 in Frecursive_edit () at keyboard.c:774
> #27 0x0000000000592ea5 in main (argc=2, argv=0x7ffea6f3f898) at emacs.c:1722
> 
> I cannot tell if it's that same assertion error. But the error seems to have happened around the same area..
> something with glyphs and displaying line numbers.

It's the same assertion violation.

> I'll leave that gdb open. Let me know what more information I can give you from that session.

Here:

  (gdb) source /path/to/emacs/src/.gdbinit
  (gdb) frame 3
  (gdb) p lnum_buf
  (gdb) p it->glyph_row->used[TEXT_AREA]
  (gdb) pgrowx it->glyph_row

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

On Thu, Jul 26, 2018 at 1:59 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
>   (gdb) source /path/to/emacs/src/.gdbinit
>   (gdb) frame 3
>   (gdb) p lnum_buf
>   (gdb) p it->glyph_row->used[TEXT_AREA]
>   (gdb) pgrowx it->glyph_row
>

Here's what I get.

I was luckily able to share the whole of "pgrowx it->glyph_row" output
because it's not much confidential. That string is part of code from a
verilog-mode buffer.


(gdb) source /home/kmodi/downloads/git/emacs/src/.gdbinit
Warning: /home/kmodi/downloads/git/emacs/../lwlib: No such file or
directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = :1.0
TERM = screen-256color
Breakpoint 1 at 0x5910b5: file emacs.c, line 369.
Temporary breakpoint 2 at 0x5bb7de: file sysdep.c, line 1077.
(gdb) frame 3
#3  0x0000000000483e19 in maybe_produce_line_number (it=0x7ffea6f395e0) at
xdisp.c:21236
21236     eassert (it->glyph_row == NULL || it->glyph_row->used[TEXT_AREA]
== 0);
(gdb) p lnum_buf
$1 = " 424 \000\000\000\060\324\310\006\000\000\000\000\060\250\363\246\376"
(gdb) p it->glyph_row->used[TEXT_AREA]
$2 = 112
(gdb) pgrowx it->glyph_row
TEXT: 112 glyphs
  0    0: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
  1    9: CHAR[4] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
  2   18: CHAR[2] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
  3   27: CHAR[4] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
  4   36: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
  5   45: CHAR[ ] pos=15965 blev=0,btyp=L w=9 a+d=17+3 MB
  6   54: CHAR[ ] pos=15966 blev=0,btyp=L w=9 a+d=17+3 MB
  7   63: CHAR[ ] pos=15967 blev=0,btyp=L w=9 a+d=17+3 MB
  8   72: CHAR[ ] pos=15968 blev=0,btyp=L w=9 a+d=17+3 MB
  9   81: CHAR[ ] pos=15969 blev=0,btyp=L w=9 a+d=17+3 MB
 10   90: CHAR[ ] pos=15970 blev=0,btyp=L w=9 a+d=17+3 MB
 11   99: CHAR[ ] pos=15971 blev=0,btyp=L w=9 a+d=17+3 MB
 12  108: CHAR[ ] pos=15972 blev=0,btyp=L w=9 a+d=17+3 MB
 13  117: CHAR[ ] pos=15973 blev=0,btyp=L w=9 a+d=17+3 MB
 14  126: CHAR[ ] pos=15974 blev=0,btyp=L w=9 a+d=17+3 MB
 15  135: CHAR[ ] pos=15975 blev=0,btyp=L w=9 a+d=17+3 MB
 16  144: CHAR[ ] pos=15976 blev=0,btyp=L w=9 a+d=17+3 MB
 17  153: CHAR[ ] pos=15977 blev=0,btyp=L w=9 a+d=17+3 MB
 18  162: CHAR[ ] pos=15978 blev=0,btyp=L w=9 a+d=17+3 MB
 19  171: CHAR[ ] pos=15979 blev=0,btyp=L w=9 a+d=17+3 MB
 20  180: CHAR[ ] pos=15980 blev=0,btyp=L w=9 a+d=17+3 MB
 21  189: CHAR[ ] pos=15981 blev=0,btyp=L w=9 a+d=17+3 MB
 22  198: CHAR[ ] pos=15982 blev=0,btyp=L w=9 a+d=17+3 MB
 23  207: CHAR[ ] pos=15983 blev=0,btyp=L w=9 a+d=17+3 MB
 24  216: CHAR[ ] pos=15984 blev=0,btyp=L w=9 a+d=17+3 MB
 25  225: CHAR[ ] pos=15985 blev=0,btyp=L w=9 a+d=17+3 MB
 26  234: CHAR[ ] pos=15986 blev=0,btyp=L w=9 a+d=17+3 MB
 27  243: CHAR[ ] pos=15987 blev=0,btyp=L w=9 a+d=17+3 MB
 28  252: CHAR[ ] pos=15988 blev=0,btyp=L w=9 a+d=17+3 MB
 29  261: CHAR[ ] pos=15989 blev=0,btyp=L w=9 a+d=17+3 MB
 30  270: CHAR[ ] pos=15990 blev=0,btyp=L w=9 a+d=17+3 MB
 31  279: CHAR[ ] pos=15991 blev=0,btyp=L w=9 a+d=17+3 MB
 32  288: CHAR[ ] pos=15992 blev=0,btyp=L w=9 a+d=17+3 MB
 33  297: CHAR[ ] pos=15993 blev=0,btyp=L w=9 a+d=17+3 MB
 34  306: CHAR[ ] pos=15994 blev=0,btyp=L w=9 a+d=17+3 MB
 35  315: CHAR[ ] pos=15995 blev=0,btyp=L w=9 a+d=17+3 MB
 36  324: CHAR[ ] pos=15996 blev=0,btyp=L w=9 a+d=17+3 MB
 37  333: CHAR[ ] pos=15997 blev=0,btyp=L w=9 a+d=17+3 MB
 38  342: CHAR[ ] pos=15998 blev=0,btyp=L w=9 a+d=17+3 MB
 39  351: CHAR[ ] pos=15999 blev=0,btyp=L w=9 a+d=17+3 MB
 40  360: CHAR[ ] pos=16000 blev=0,btyp=L w=9 a+d=17+3 MB
 41  369: CHAR[ ] pos=16001 blev=0,btyp=L w=9 a+d=17+3 MB
 42  378: CHAR[ ] pos=16002 blev=0,btyp=L w=9 a+d=17+3 MB
 43  387: CHAR[ ] pos=16003 blev=0,btyp=L w=9 a+d=17+3 MB
 44  396: CHAR[ ] pos=16004 blev=0,btyp=L w=9 a+d=17+3 MB
 45  405: CHAR[ ] pos=16005 blev=0,btyp=L w=9 a+d=17+3 MB
 46  414: CHAR[ ] pos=16006 blev=0,btyp=L w=9 a+d=17+3 MB
 47  423: CHAR[ ] pos=16007 blev=0,btyp=L w=9 a+d=17+3 MB
 48  432: CHAR[ ] pos=16008 blev=0,btyp=L w=9 a+d=17+3 MB
 49  441: CHAR[ ] pos=16009 blev=0,btyp=L w=9 a+d=17+3 MB
 50  450: CHAR[ ] pos=16010 blev=0,btyp=L w=9 a+d=17+3 MB
 51  459: CHAR[ ] pos=16011 blev=0,btyp=L w=9 a+d=17+3 MB
 52  468: CHAR[ ] pos=16012 blev=0,btyp=L w=9 a+d=17+3 MB
 53  477: CHAR[ ] pos=16013 blev=0,btyp=L w=9 a+d=17+3 MB
 54  486: CHAR[ ] pos=16014 blev=0,btyp=L w=9 a+d=17+3 MB
 55  495: CHAR[ ] pos=16015 blev=0,btyp=L w=9 a+d=17+3 MB
 56  504: CHAR[ ] pos=16016 blev=0,btyp=L w=9 a+d=17+3 MB
 57  513: CHAR[ ] pos=16017 blev=0,btyp=L w=9 a+d=17+3 MB
 58  522: CHAR[ ] pos=16018 blev=0,btyp=L w=9 a+d=17+3 MB
 59  531: CHAR[ ] pos=16019 blev=0,btyp=L w=9 a+d=17+3 MB
 60  540: CHAR[ ] pos=16020 blev=0,btyp=L w=9 a+d=17+3 MB
 61  549: CHAR[$] pos=16021 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 62  558: CHAR[s] pos=16022 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 63  567: CHAR[f] pos=16023 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 64  576: CHAR[o] pos=16024 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 65  585: CHAR[r] pos=16025 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 66  594: CHAR[m] pos=16026 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 67  603: CHAR[a] pos=16027 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 68  612: CHAR[t] pos=16028 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 69  621: CHAR[f] pos=16029 blev=0,btyp=L w=9 a+d=17+3 face=18 MB
 70  630: CHAR[(] pos=16030 blev=0,btyp=L w=9 a+d=17+3 face=19 MB
 71  639: CHAR["] pos=16031 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 72  648: CHAR[r] pos=16032 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 73  657: CHAR[e] pos=16033 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 74  666: CHAR[a] pos=16034 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 75  675: CHAR[d] pos=16035 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 76  684: CHAR[ ] pos=16036 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 77  693: CHAR[c] pos=16037 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 78  702: CHAR[h] pos=16038 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 79  711: CHAR[0] pos=16039 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 80  720: CHAR[ ] pos=16040 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 81  729: CHAR[(] pos=16041 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 82  738: CHAR[t] pos=16042 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 83  747: CHAR[e] pos=16043 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 84  756: CHAR[s] pos=16044 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 85  765: CHAR[t] pos=16045 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 86  774: CHAR[ ] pos=16046 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 87  783: CHAR[m] pos=16047 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 88  792: CHAR[o] pos=16048 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 89  801: CHAR[d] pos=16049 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 90  810: CHAR[e] pos=16050 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 91  819: CHAR[ ] pos=16051 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 92  828: CHAR[=] pos=16052 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 93  837: CHAR[ ] pos=16053 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 94  846: CHAR[%] pos=16054 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 95  855: CHAR[d] pos=16055 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 96  864: CHAR[ ] pos=16056 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 97  873: CHAR[/] pos=16057 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 98  882: CHAR[ ] pos=16058 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
 99  891: CHAR[d] pos=16059 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
100  900: CHAR[i] pos=16060 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
101  909: CHAR[v] pos=16061 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
102  918: CHAR[i] pos=16062 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
103  927: CHAR[d] pos=16063 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
104  936: CHAR[e] pos=16064 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
105  945: CHAR[r] pos=16065 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
106  954: CHAR[ ] pos=16066 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
107  963: CHAR[=] pos=16067 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
108  972: CHAR[ ] pos=16068 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
109  981: CHAR[%] pos=16069 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
110  990: CHAR[d] pos=16070 blev=0,btyp=L w=9 a+d=17+3 face=20 MB
111  999: CHAR[)] pos=16071 blev=0,btyp=L w=9 a+d=17+3 face=20 MB

-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 9307 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 26 Jul 2018 14:07:55 -0400
> Cc: 32258@debbugs.gnu.org
> 
> (gdb) source /home/kmodi/downloads/git/emacs/src/.gdbinit
> Warning: /home/kmodi/downloads/git/emacs/../lwlib: No such file or directory.
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
> DISPLAY = :1.0
> TERM = screen-256color
> Breakpoint 1 at 0x5910b5: file emacs.c, line 369.
> Temporary breakpoint 2 at 0x5bb7de: file sysdep.c, line 1077.
> (gdb) frame 3
> #3  0x0000000000483e19 in maybe_produce_line_number (it=0x7ffea6f395e0) at xdisp.c:21236
> 21236     eassert (it->glyph_row == NULL || it->glyph_row->used[TEXT_AREA] == 0);
> (gdb) p lnum_buf
> $1 = " 424 \000\000\000\060\324\310\006\000\000\000\000\060\250\363\246\376"
> (gdb) p it->glyph_row->used[TEXT_AREA]
> $2 = 112
> (gdb) pgrowx it->glyph_row
> TEXT: 112 glyphs
>   0    0: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
>   1    9: CHAR[4] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
>   2   18: CHAR[2] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
>   3   27: CHAR[4] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
>   4   36: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=17+3 face=16 MB AVOID
>   5   45: CHAR[ ] pos=15965 blev=0,btyp=L w=9 a+d=17+3 MB
>   6   54: CHAR[ ] pos=15966 blev=0,btyp=L w=9 a+d=17+3 MB
>   7   63: CHAR[ ] pos=15967 blev=0,btyp=L w=9 a+d=17+3 MB
>   8   72: CHAR[ ] pos=15968 blev=0,btyp=L w=9 a+d=17+3 MB
>   9   81: CHAR[ ] pos=15969 blev=0,btyp=L w=9 a+d=17+3 MB

This is some variant of bug#28710 and bug#27668.  But those were
fixed, so it's some similar, but different problem.  Unfortunately, to
debug this I need either to be able to reproduce this on my system
(unlikely, since I'm guessing GTK triggers that bug on your system),
or I need you to run a debugging session described in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27668#89

and show the results.

But since you cannot trigger the problem at will, it sounds
impractical.  So it sounds like we are stuck, sorry.

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> Date: Thu, 26 Jul 2018 22:20:36 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32258@debbugs.gnu.org
> 
> But since you cannot trigger the problem at will, it sounds
> impractical.  So it sounds like we are stuck, sorry.

OK, stabbing in the dark here: in this fragment of xdisp.c:

      /* Redisplay, then check if cursor has been set during the
	 redisplay.  Give up if new fonts were loaded.  */
      /* We used to issue a CHECK_MARGINS argument to try_window here,
	 but this causes scrolling to fail when point begins inside
	 the scroll margin (bug#148) -- cyd  */
      if (!try_window (window, startp, 0))
	{
	  w->force_start = true;
	  clear_glyph_matrix (w->desired_matrix);
	  goto need_larger_matrices;
	}

which on the current trunk is around line 16920, please insert this
line:

      clear_glyph_matrix (w->desired_matrix);

before this line:

      if (!try_window (window, startp, 0))

Then try running with this change for a while, and see if it solves
the assertion violations and doesn't produce any unintended adverse
effects.

Thanks.

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

On Thu, Jul 26, 2018 at 4:14 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> which on the current trunk is around line 16920, please insert this
> line:
>
>       clear_glyph_matrix (w->desired_matrix);
>
> before this line:
>
>       if (!try_window (window, startp, 0))
>
> Then try running with this change for a while, and see if it solves
> the assertion violations and doesn't produce any unintended adverse
> effects.
>

OK, I have added that line, rebuilt and running it with gdb attached, will
keep you posted.

Thanks!
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 978 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Kaushal Modi]

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

On Thu, Jul 26, 2018 at 4:46 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> OK, I have added that line, rebuilt and running it with gdb attached, will
> keep you posted.
>

An update. My emacs sessions haven't crashed after that experimental fix.
Also, I didn't see any adverse effects because of that.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 810 bytes --]

bug#32258: 27.0.50; Crash on minimizing/maximizing Emacs frame from taskbar [RHEL 6.8 GTK2]

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 1 Aug 2018 15:21:56 -0400
> Cc: 32258@debbugs.gnu.org
> 
> An update. My emacs sessions haven't crashed after that experimental fix. Also, I didn't see any adverse
> effects because of that. 

OK, I've now pushed the change to the emacs-26 branch, and I'm closing
the bug.  Thanks for testing.