bug#18270: Crash in lates emacs-24 branch on ubuntu 14.04

bug#18270: Crash in lates emacs-24 branch on ubuntu 14.04

[jaimef]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 115 bytes --]

The gdb output is provided.
Latest emacs-24 branch built today with default autogen/configure/make 
bootstrap/make

[-- Attachment #2: Type: TEXT/PLAIN, Size: 9418 bytes --]

jaimef@jaimef:~$ gdb emacs
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from emacs...done.
(gdb) run
Starting program: /usr/local/bin/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb55a700 (LWP 6596)]
[New Thread 0x7fffe9124700 (LWP 6597)]
[New Thread 0x7fffe3fff700 (LWP 6600)]

(emacs:6592): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

Program received signal SIGSEGV, Segmentation fault.
mark_window_display_accurate_1 (w=w@entry=0x2ba87a8, accurate_p=0) at xdisp.c:14151
14151     w->last_had_star = BUF_MODIFF (b) > BUF_SAVE_MODIFF (b);
(gdb) bt
#0  mark_window_display_accurate_1 (w=w@entry=0x2ba87a8, accurate_p=0) at xdisp.c:14151
#1  0x0000000000439348 in mark_window_display_accurate (window=45778861, accurate_p=accurate_p@entry=0) at xdisp.c:14204
#2  0x000000000043937a in mark_window_display_accurate (window=45774965, accurate_p=accurate_p@entry=0) at xdisp.c:14202
#3  0x000000000041f546 in redraw_frame (f=0x11384e8) at dispnew.c:2999
#4  0x0000000000424a26 in x_set_frame_parameters (f=f@entry=0x11384e8, alist=<optimized out>, alist@entry=26893110) at frame.c:2883
#5  0x000000000042550c in Fmodify_frame_parameters (frame=<optimized out>, alist=26893110) at frame.c:2344
#6  0x0000000000555368 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at eval.c:2818
#7  0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=12128562, nargs=140737488343152, args=0x3)
    at bytecode.c:916
#8  0x0000000000554e1f in funcall_lambda (fun=9811117, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffd250) at eval.c:3049
#9  0x000000000055518b in Ffuncall (nargs=1, args=0x7fffffffd248) at eval.c:2876
#10 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=0, nargs=140737488343616, args=0x1)
    at bytecode.c:916
#11 0x0000000000554eb7 in funcall_lambda (fun=140737488344976, nargs=nargs@entry=0, arg_vector=0x8c6a99 <pure+566009>, arg_vector@entry=0x7fffffffd3a8)
    at eval.c:2983
#12 0x000000000055518b in Ffuncall (nargs=1, args=0x7fffffffd3a0) at eval.c:2876
#13 0x0000000000554a58 in eval_sub (form=<optimized out>) at eval.c:2157
#14 0x0000000000554b85 in Fprogn (body=45778856) at eval.c:468
#15 0x0000000000553fde in unbind_to (count=<optimized out>, value=12128562) at eval.c:3309
#16 0x0000000000554193 in unwind_to_catch (catch=catch@entry=0xf55f40, value=value@entry=8661742) at eval.c:1167
#17 0x00000000005556d3 in Fsignal (error_symbol=12128562, data=<optimized out>) at eval.c:1564
#18 0x0000000000555aa9 in xsignal (error_symbol=<optimized out>, data=<optimized out>) at eval.c:1588
#19 0x0000000000539a81 in memory_full (nbytes=nbytes@entry=18446744073709551597) at alloc.c:3759
#20 0x0000000000539fb7 in xrealloc (block=<optimized out>, size=18446744073709551597) at alloc.c:721
#21 0x000000000041e583 in adjust_decode_mode_spec_buffer (f=0x11384e8, f=0x11384e8) at dispnew.c:2142
#22 adjust_frame_glyphs (f=0x11384e8) at dispnew.c:1792
#23 0x00000000004694cc in apply_window_adjustment (w=w@entry=0x1136688) at window.c:6790
#24 0x000000000046eb01 in set_window_buffer (window=window@entry=18048653, buffer=buffer@entry=14739189, run_hooks_p=run_hooks_p@entry=true, 
    keep_margins_p=<optimized out>) at window.c:3495
#25 0x000000000046f44e in Fset_window_buffer (window=<optimized out>, buffer_or_name=<optimized out>, keep_margins=12128562) at window.c:3559
#26 0x0000000000555358 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at eval.c:2822
#27 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=12128562, nargs=140737488344864, args=0x3)
    at bytecode.c:916
#28 0x0000000000554e1f in funcall_lambda (fun=8994349, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x7fffffffd8f0) at eval.c:3049
#29 0x000000000055518b in Ffuncall (nargs=5, args=0x7fffffffd8e8) at eval.c:2876
#30 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=12128562, nargs=140737488345312, args=0x5)
    at bytecode.c:916
#31 0x0000000000554e1f in funcall_lambda (fun=9001461, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fffffffdab0) at eval.c:3049
#32 0x000000000055518b in Ffuncall (nargs=3, args=0x7fffffffdaa8) at eval.c:2876
#33 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=12128562, nargs=140737488345760, args=0x3)
    at bytecode.c:916
#34 0x0000000000554e1f in funcall_lambda (fun=8997709, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffdc80) at eval.c:3049
#35 0x000000000055518b in Ffuncall (nargs=2, args=0x7fffffffdc78) at eval.c:2876
#36 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=12128562, nargs=107, args=0x2) at bytecode.c
#37 0x0000000000554e1f in funcall_lambda (fun=25644869, nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7fffffffde40) at eval.c:3049
#38 0x000000000055518b in Ffuncall (nargs=4, args=0x7fffffffde38) at eval.c:2876
#39 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=0, nargs=140737488346720, args=0x4)
    at bytecode.c:916
#40 0x0000000000554eb7 in funcall_lambda (fun=140737488347488, nargs=nargs@entry=0, arg_vector=0x8c8809 <pure+573545>, arg_vector@entry=0x7fffffffe008)
    at eval.c:2983
#41 0x000000000055518b in Ffuncall (nargs=1, args=0x7fffffffe000) at eval.c:2876
#42 0x0000000000555409 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2366
#43 0x0000000000553c8d in run_hook_with_args (nargs=1, args=0x7fffffffe000, funcall=0x555400 <funcall_nil>) at eval.c:2551
#44 0x0000000000553db6 in Frun_hooks (nargs=1, args=0x7fffffffe0b0) at eval.c:2393
#45 0x000000000055526a in Ffuncall (nargs=<optimized out>, args=<optimized out>) at eval.c:2796
#46 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=0, nargs=140737488347296, args=0x2)
    at bytecode.c:916
#47 0x0000000000554eb7 in funcall_lambda (fun=140737488347872, nargs=nargs@entry=0, arg_vector=0x8c7399 <pure+568313>, arg_vector@entry=0x7fffffffe258)
    at eval.c:2983
#48 0x000000000055518b in Ffuncall (nargs=1, args=0x7fffffffe250) at eval.c:2876
#49 0x0000000000589575 in exec_byte_code (bytestr=203483504443392, vector=0, maxdepth=3266576448, args_template=0, nargs=140737488347720, args=0x1)
    at bytecode.c:916
#50 0x0000000000554eb7 in funcall_lambda (fun=0, fun@entry=9201109, nargs=nargs@entry=0, arg_vector=0x8c6601 <pure+564833>, arg_vector@entry=0x7fffffffe350)
    at eval.c:2983
#51 0x00000000005542f4 in apply_lambda (fun=9201109, args=<optimized out>) at eval.c:2924
#52 0x000000000055467e in eval_sub (form=form@entry=15465238) at eval.c:2260
#53 0x0000000000557c91 in Feval (form=15465238, lexical=<optimized out>) at eval.c:2003
#54 0x00000000005537ce in internal_condition_case (bfun=bfun@entry=0x4e46d0 <top_level_2>, handlers=<optimized out>, hfun=hfun@entry=0x4e8f00 <cmd_error>)
    at eval.c:1354
#55 0x00000000004e46b6 in top_level_1 (ignore=ignore@entry=12128562) at keyboard.c:1194
#56 0x00000000005536db in internal_catch (tag=12176066, func=func@entry=0x4e4650 <top_level_1>, arg=12128562) at eval.c:1118
#57 0x00000000004e8b0f in command_loop () at keyboard.c:1155
#58 recursive_edit_1 () at keyboard.c:777
#59 0x00000000004e8e3d in Frecursive_edit () at keyboard.c:848
#60 0x00000000004168c5 in main (argc=<optimized out>, argv=0x7fffffffe6e8) at emacs.c:1646
(gdb) info registers
rax            0xb91132000000   203483504443392
rbx            0x2ba87a8        45778856
rcx            0x1e15a00        31545856
rdx            0xc2b40040       3266576448
rsi            0x0      0
rdi            0x2ba87a8        45778856
rbp            0xb9112d 0xb9112d
rsp            0x7fffffffce20   0x7fffffffce20
r8             0x0      0
r9             0x1aafd60        27983200
r10            0x2e     46
r11            0x1f4    500
r12            0x0      0
r13            0x400000003f000000       4611686019484352512
r14            0x11384e8        18056424
r15            0x1      1
rip            0x42a74d 0x42a74d <mark_window_display_accurate_1+381>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04

[Paul Eggert]

The backtrace looks like nonsense, unfortunately, e.g., it shows two 
arguments to adjust_decode_mode_spec_buffer, a function that has just 
one argument, and it shows xrealloc being called with 
size=18446744073709551597, even though the code passed 
FRAME_MESSAGE_BUF_SIZE (f) + 1 as the size, and I don't see any way to 
get 18446744073709551597 even if overflow is taken into account.

Can you reproduce the problem?

Can you compile with '-g3 -O0' and reproduce the problem?

bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04

[Jaime Fournier]

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

I can reproduce if I link against gtk3. Not on gtk2/1

On August 20, 2014 6:58:39 PM PDT, Paul Eggert <eggert@cs.ucla.edu> wrote:
>The backtrace looks like nonsense, unfortunately, e.g., it shows two 
>arguments to adjust_decode_mode_spec_buffer, a function that has just 
>one argument, and it shows xrealloc being called with 
>size=18446744073709551597, even though the code passed 
>FRAME_MESSAGE_BUF_SIZE (f) + 1 as the size, and I don't see any way to 
>get 18446744073709551597 even if overflow is taken into account.
>
>Can you reproduce the problem?
>
>Can you compile with '-g3 -O0' and reproduce the problem?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04

[Jaime Fournier]

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

I can reproduce if I link against gtk3. Not on gtk2/1

On August 20, 2014 6:58:39 PM PDT, Paul Eggert <eggert@cs.ucla.edu> wrote:
>The backtrace looks like nonsense, unfortunately, e.g., it shows two 
>arguments to adjust_decode_mode_spec_buffer, a function that has just 
>one argument, and it shows xrealloc being called with 
>size=18446744073709551597, even though the code passed 
>FRAME_MESSAGE_BUF_SIZE (f) + 1 as the size, and I don't see any way to 
>get 18446744073709551597 even if overflow is taken into account.
>
>Can you reproduce the problem?
>
>Can you compile with '-g3 -O0' and reproduce the problem?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04

[Paul Eggert]

Jaime Fournier wrote:
> I can reproduce if I link against gtk3

Thanks; please send a recipe for reproducing it, starting with 'emacs 
-Q'.  It'd be nice if you could rebuild with -g3 -O0 first and send a 
backtrace.

bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04

[jaimef]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 749 bytes --]

I can reproduce with my config on Spectrwm tiling WM.
However under KDE it runs fine without segfaults.
Also "emacs -Q" would hang but not crash as it did.
Must be an issue with gtk3 and the Spectrwm wm.

I've attached the Crash output as well as the configure/etc.


On Wed, 20 Aug 2014, Paul Eggert wrote:

> Date: Wed, 20 Aug 2014 20:04:46 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> To: Jaime Fournier <jaimef@linbsd.org>
> Cc: 18270@debbugs.gnu.org
> Subject: Re: Crash in latest emacs-24 branch on ubuntu 14.04
> 
> Jaime Fournier wrote:
>> I can reproduce if I link against gtk3
>
> Thanks; please send a recipe for reproducing it, starting with 'emacs -Q'. 
> It'd be nice if you could rebuild with -g3 -O0 first and send a backtrace.
>

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 276424 bytes --]

bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04

[Stefan Kangas]

jaimef@linbsd.org writes:

> I can reproduce with my config on Spectrwm tiling WM.
> However under KDE it runs fine without segfaults.
> Also "emacs -Q" would hang but not crash as it did.
> Must be an issue with gtk3 and the Spectrwm wm.
>
> I've attached the Crash output as well as the configure/etc.

I see in the output from the crash:

> (emacs:19316): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
> Fatal error 11: Segmentation fault

In the etc/PROBLEMS file, we have the following item regarding a crash
with the same error message:

> *** Emacs built with GTK+ toolkit can unexpectedly widen frames

Perhaps this should therefore be merged with the bugs mentioned there:

> See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15700,
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22000,
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22898 and
> https://lists.gnu.org/r/emacs-devel/2016-07/msg00154.html.

Thanks,
Stefan Kangas

bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04

[Paul Eggert]

Stefan Kangas wrote:
> Perhaps this should therefore be merged with the bugs mentioned there:

Sounds good to me; I merged them.