* bug#18270: Crash in lates emacs-24 branch on ubuntu 14.04
@ 2014-08-15 4:22 jaimef
2014-08-21 1:58 ` bug#18270: Crash in latest " Paul Eggert
2019-08-23 19:03 ` Stefan Kangas
0 siblings, 2 replies; 8+ messages in thread
From: jaimef @ 2014-08-15 4:22 UTC (permalink / raw)
To: 18270
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04
2014-08-15 4:22 bug#18270: Crash in lates emacs-24 branch on ubuntu 14.04 jaimef
@ 2014-08-21 1:58 ` Paul Eggert
2014-08-21 2:00 ` Jaime Fournier
2014-08-21 2:00 ` Jaime Fournier
2019-08-23 19:03 ` Stefan Kangas
1 sibling, 2 replies; 8+ messages in thread
From: Paul Eggert @ 2014-08-21 1:58 UTC (permalink / raw)
To: jaimef; +Cc: 18270
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04
2014-08-21 1:58 ` bug#18270: Crash in latest " Paul Eggert
@ 2014-08-21 2:00 ` Jaime Fournier
2014-08-21 2:00 ` Jaime Fournier
1 sibling, 0 replies; 8+ messages in thread
From: Jaime Fournier @ 2014-08-21 2:00 UTC (permalink / raw)
To: Paul Eggert; +Cc: 18270
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04
2014-08-21 1:58 ` bug#18270: Crash in latest " Paul Eggert
2014-08-21 2:00 ` Jaime Fournier
@ 2014-08-21 2:00 ` Jaime Fournier
2014-08-21 3:04 ` Paul Eggert
1 sibling, 1 reply; 8+ messages in thread
From: Jaime Fournier @ 2014-08-21 2:00 UTC (permalink / raw)
To: Paul Eggert; +Cc: 18270
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#18270: Crash in latest emacs-24 branch on ubuntu 14.04
2014-08-15 4:22 bug#18270: Crash in lates emacs-24 branch on ubuntu 14.04 jaimef
2014-08-21 1:58 ` bug#18270: Crash in latest " Paul Eggert
@ 2019-08-23 19:03 ` Stefan Kangas
2019-08-24 0:59 ` Paul Eggert
1 sibling, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2019-08-23 19:03 UTC (permalink / raw)
To: jaimef; +Cc: Paul Eggert, 18270
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-24 0:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-15 4:22 bug#18270: Crash in lates emacs-24 branch on ubuntu 14.04 jaimef
2014-08-21 1:58 ` bug#18270: Crash in latest " Paul Eggert
2014-08-21 2:00 ` Jaime Fournier
2014-08-21 2:00 ` Jaime Fournier
2014-08-21 3:04 ` Paul Eggert
2014-08-24 18:56 ` jaimef
2019-08-23 19:03 ` Stefan Kangas
2019-08-24 0:59 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.