GNU bug report logs - #29031
25.3; Segmentation fault when starting emacs with my config

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29031 in the body.
You can then email your comments to 29031 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 25.3; Segmentation fault when starting emacs with my config
Date: Fri, 27 Oct 2017 21:24:27 +0000

[Message part 1 (text/plain, inline)]

Hello,

I build emacs locally on my machine (on emacs-26 branch now) and that works
fine.

But I got my company CAD to install the latest stable emacs 25.3 and that
is segfaulting as soon as I start.

Here is the backtrace:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00000033e307a13c in _int_malloc () from /lib64/libc.so.6
(gdb) bt
#0  0x00000033e307a13c in _int_malloc () from /lib64/libc.so.6
#1  0x00000033e307ab1c in malloc () from /lib64/libc.so.6
#2  0x00000000005462ee in lmalloc (size=8188) at alloc.c:1414
#3  lisp_malloc (nbytes=<optimized out>, type=MEM_TYPE_NON_LISP) at
alloc.c:1063
#4  0x00000000005479ef in allocate_string_data (s=0x4e1ea40, nchars=450,
nbytes=451) at alloc.c:1998
#5  0x0000000000547bc7 in make_uninit_multibyte_string (nchars=450,
nbytes=451) at alloc.c:2513
#6  0x0000000000547d46 in make_specified_string (
    contents=0x7fffffff0320 "Full list:\n     (mode-line-space-mode)\n
ez-esc (easy-escape-minor-mode)\n    wr (wrap-region-mode)\n    Undo-Tree
(undo-tree-mode)\n    PgLn (page-break-lines-mode)\n    Outl
(outline-minor-mode)\n    h"..., nchars=<optimized out>, nbytes=451,
multibyte=true)
    at alloc.c:2473
#7  0x000000000055989e in styled_format (nargs=3, args=0x7fffffff1930,
message=<optimized out>) at editfns.c:4551
#8  0x000000000055f843 in Ffuncall (nargs=<optimized out>,
args=0x7fffffff1928) at eval.c:2679
#9  0x000000000059679d in exec_byte_code (bytestr=<optimized out>,
vector=60473349, maxdepth=<optimized out>, args_template=<optimized out>,
    nargs=<optimized out>, args=<optimized out>) at bytecode.c:880
#10 0x000000000055f3fa in funcall_lambda (fun=60473525, nargs=<optimized
out>, arg_vector=0x7fffffff1b10) at eval.c:2929
#11 0x000000000055f743 in Ffuncall (nargs=<optimized out>,
args=0x7fffffff1b08) at eval.c:2760
#12 0x000000000059679d in exec_byte_code (bytestr=<optimized out>,
vector=61071245, maxdepth=<optimized out>, args_template=<optimized out>,
    nargs=<optimized out>, args=<optimized out>) at bytecode.c:880
#13 0x000000000055f3fa in funcall_lambda (fun=61071533, nargs=<optimized
out>, arg_vector=0x7fffffff1c40) at eval.c:2929
#14 0x000000000055e9eb in apply_lambda (fun=61071533, args=0, count=13) at
eval.c:2800
#15 0x000000000055ecb6 in eval_sub (form=<optimized out>) at eval.c:2247
#16 0x0000000000560a92 in Feval (form=61062547, lexical=<optimized out>) at
eval.c:1994
#17 0x000000000055f9c8 in Ffuncall (nargs=<optimized out>,
args=0x7fffffff1dd8) at eval.c:2702
#18 0x000000000055e4ce in internal_condition_case_n (bfun=0x55f5a0
<Ffuncall>, nargs=2, args=0x7fffffff1e90, handlers=<optimized out>,
    hfun=0x447a60 <safe_eval_handler>) at eval.c:1395
#19 0x000000000043ac89 in safe__call (inhibit_quit=true, nargs=2,
func=<optimized out>, ap=<optimized out>) at xdisp.c:2558
#20 0x000000000043ae42 in safe__call1 (inhibit_quit=<optimized out>,
fn=<optimized out>) at xdisp.c:2595
#21 0x000000000044fac3 in safe__eval (sexpr=<optimized out>,
inhibit_quit=true) at xdisp.c:2609
#22 display_mode_element (it=0x7fffffff2340, depth=4, field_width=0,
precision=-82, elt=61062531, props=0, risky=false) at xdisp.c:22863
#23 0x000000000044fc8e in display_mode_element (it=0x7fffffff2340, depth=3,
field_width=0, precision=-82, elt=61138403, props=0, risky=false)
    at xdisp.c:22944
#24 0x000000000044fc8e in display_mode_element (it=0x7fffffff2340, depth=1,
field_width=0, precision=0, elt=61214771, props=0, risky=false)
    at xdisp.c:22944
#25 0x0000000000454af9 in display_mode_line (w=0x11ebac0,
face_id=MODE_LINE_FACE_ID, format=61214963) at xdisp.c:22460
#26 0x0000000000454dee in display_mode_lines (w=0x11ebac0) at xdisp.c:22402
#27 0x00000000004600f7 in redisplay_window (window=18791109,
just_this_one_p=false) at xdisp.c:17066
---Type <return> to continue, or q <return> to quit---
#28 0x0000000000463936 in redisplay_window_0 (window=<optimized out>) at
xdisp.c:14491
#29 0x000000000055e5c6 in internal_condition_case_1 (bfun=0x463910
<redisplay_window_0>, arg=18791109, handlers=<optimized out>, hfun=0x429940
<redisplay_window_error>) at eval.c:1339
#30 0x0000000000445f2e in redisplay_windows (window=<optimized out>) at
xdisp.c:14471
#31 0x000000000045cdd5 in redisplay_internal () at xdisp.c:14031
#32 0x00000000004f5099 in read_char (commandflag=1, map=99214275,
prev_event=0, used_mouse_menu=0x7fffffffb0ff, end_time=0x0) at
keyboard.c:2482
#33 0x00000000004f8ec0 in read_key_sequence (keybuf=0x7fffffffb170,
prompt=0, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false, bufsize=30) at
keyboard.c:9068
#34 0x00000000004fa1ba in command_loop_1 () at keyboard.c:1370
#35 0x000000000055e62a in internal_condition_case (bfun=0x4f9ff0
<command_loop_1>, handlers=<optimized out>, hfun=0x4f8000 <cmd_error>) at
eval.c:1315
#36 0x00000000004f7fec in command_loop_2 (ignore=<optimized out>) at
keyboard.c:1112
#37 0x000000000055e6b8 in internal_catch (tag=<optimized out>,
func=0x4f7fd0 <command_loop_2>, arg=0) at eval.c:1080
#38 0x00000000004f7d67 in command_loop () at keyboard.c:1091
#39 0x00000000004f7df5 in recursive_edit_1 () at keyboard.c:697
#40 0x00000000004f7f35 in Frecursive_edit () at keyboard.c:768
#41 0x00000000004e977e in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:1629



Emacs version info:

Emacs version: GNU Emacs 25.3.1 (x86_64-unknown-linux-gnu, GTK+ Version
2.24.23)
 of 2017-10-27

./configure options:
  --prefix=/cad/adi/apps/gnu/linux/x86_64/6/local/emacs/25.3 --with-modules
PKG_CONFIG_PATH=/cad/adi/apps/gnu/linux/x86_64/6/local/emacs/25.3/lib/pkgconfig

Features:
  XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF NOTIFY ACL LIBSELINUX GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11 MODULES


I cannot understand the backtrace, but I see modeline in there..

My mode line looks like this (picture attached):

[image: image.png]

Though, it worked fine on emacs-26 (and earlier when we were on emacs 25.x
versions).

I see that the company CAD built emacs is without libotf and imagemagick.
Does this backtrace have anything to do with that?

Thanks.
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

[image.png (image/png, inline)]

Message #8 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: 29031 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 14:17:57 +0000

[Message part 1 (text/plain, inline)]

The CAD department built 25.3 again, this time, with libotf. But I still
get the segmentation fault. See the backtrace below. The backtrace looks
different this time though.. "xdisp.c: No such file or directory"!?

Emacs version: GNU Emacs 25.3.1 (x86_64-unknown-linux-gnu, GTK+ Version
2.24.23)
 of 2017-10-30, built using commit .

./configure options:
  --prefix=/cad/adi/apps/gnu/linux/x86_64/6/local/emacs/25.3 --with-modules

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


=====

Starting program:
/cad/adi/apps/gnu/linux/x86_64/6/local/emacs/25.3/bin/emacs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffef071700 (LWP 10664)]

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x000000000043d101 in append_glyph (it=0x7fffffff2390) at xdisp.c:25880
25880   xdisp.c: No such file or directory.
(gdb) bt
#0  0x000000000043d101 in append_glyph (it=0x7fffffff2390) at xdisp.c:25880
#1  x_produce_glyphs (it=0x7fffffff2390) at xdisp.c:27175
#2  0x0000000000452032 in display_line (it=0x7fffffff2390) at xdisp.c:20676
#3  0x0000000000457868 in try_window (window=18793157, pos=..., flags=1) at
xdisp.c:17251
#4  0x0000000000460e41 in redisplay_window (window=18793157,
just_this_one_p=false)
    at xdisp.c:16700
#5  0x0000000000463b36 in redisplay_window_0 (window=<optimized out>) at
xdisp.c:14491
#6  0x000000000055e7c6 in internal_condition_case_1 (bfun=0x463b10
<redisplay_window_0>,
    arg=18793157, handlers=<optimized out>, hfun=0x429b40
<redisplay_window_error>)
    at eval.c:1339
#7  0x000000000044612e in redisplay_windows (window=<optimized out>) at
xdisp.c:14471
#8  0x000000000045cfd5 in redisplay_internal () at xdisp.c:14031
#9  0x00000000004f5299 in read_char (commandflag=1, map=109811619,
prev_event=0,
    used_mouse_menu=0x7fffffffb11f, end_time=0x0) at keyboard.c:2482
#10 0x00000000004f90c0 in read_key_sequence (keybuf=0x7fffffffb190,
prompt=0,
    dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true,
    prevent_redisplay=false, bufsize=30) at keyboard.c:9068
#11 0x00000000004fa3ba in command_loop_1 () at keyboard.c:1370
#12 0x000000000055e82a in internal_condition_case (bfun=0x4fa1f0
<command_loop_1>,
    handlers=<optimized out>, hfun=0x4f8200 <cmd_error>) at eval.c:1315
#13 0x00000000004f81ec in command_loop_2 (ignore=<optimized out>) at
keyboard.c:1112
#14 0x000000000055e8b8 in internal_catch (tag=<optimized out>,
    func=0x4f81d0 <command_loop_2>, arg=0) at eval.c:1080
#15 0x00000000004f7f67 in command_loop () at keyboard.c:1091
#16 0x00000000004f7ff5 in recursive_edit_1 () at keyboard.c:697
#17 0x00000000004f8135 in Frecursive_edit () at keyboard.c:768
#18 0x00000000004e997e in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:1629

-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #11 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: 29031 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 16:03:43 +0000

[Message part 1 (text/plain, inline)]

Hello all,

I cannot understand why, but reverting nlinum to version 1.7 fixed this.

stable nlinum version for me:
http://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=e885224c70f5fc03b23590304dd0fd21524d27e1

Also I couldn't figure out how to reproduce this issue on emacs -Q. But
here are some observations (on emacs 25.3):

- I started this bug saying that I can reproduce this crash only on the
company CAD built emacs 25.3. But turns out that the crash happens on my
build of emacs-25 branch that I had done a long time back, only when
running emacs, not emacsclient.

- Crash happened only when I loaded nlinum (not linum) AND had my config
call the below modi/blend-linum function in wrapper function in
window-setup-hook.
- Couldn't recreate crash if I commented out the lines calling that
function, *or* the lines loading nlinum in my config.
- Even if I commented out the call to modi/blend-linum, emacs 25.3 does not
crash, but the line numbers look BAD (see this gifv to see what I mean:
https://i.imgur.com/8npahiz.gifv). That is with current line number
highlight enabled in nlinum.
- The crash AND visual artifact issue went away on reverted to nlinum 1.7
without having to comment out the call to modi/blend-linum, on emacs 25.3.

=====
(defun modi/blend-linum ()
  "Set the linum foreground face to that of
`font-lock-comment-face' and background color to that of the
theme."
  (interactive)
  (set-face-attribute
   'linum nil
   :height 0.9
   :foreground (if (string= (face-foreground 'font-lock-comment-face)
"unspecified-fg")
                   "#8f8f8f"
                 (face-foreground 'font-lock-comment-face))
   :background (if (string= (face-background 'default) "unspecified-bg")
                   "#282828"
                 (face-background 'default))))
=====

**I couldn't reproduce the visual artifact issues or crash on emacs 26.x+.**

Appendix: I generate my theme-loading function 'load-theme/smyx' (that
loads my custom theme smyx). That is the wrapper fn I referred above,
that's called in window-setup-hook. That wrapper fn calls modi/blend-linum.
Relevant part from my config[1].

[1]:
https://github.com/kaushalmodi/.emacs.d/blob/1e37e3502ed1337420d7fb0db7f940c52694bdca/setup-files/setup-visual.el#L157-L221



On Mon, Oct 30, 2017 at 10:17 AM Kaushal Modi <kaushal.modi <at> gmail.com>
wrote:

> The CAD department built 25.3 again, this time, with libotf. But I still
> get the segmentation fault. See the backtrace below. The backtrace looks
> different this time though.. "xdisp.c: No such file or directory"!?
>
> Emacs version: GNU Emacs 25.3.1 (x86_64-unknown-linux-gnu, GTK+ Version
> 2.24.23)
>  of 2017-10-30, built using commit .
>
> ./configure options:
>   --prefix=/cad/adi/apps/gnu/linux/x86_64/6/local/emacs/25.3 --with-modules
>
> Features:
>   XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF NOTIFY ACL LIBSELINUX GNUTLS
> LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11 MODULES
>
>
> =====
>
> Starting program:
> /cad/adi/apps/gnu/linux/x86_64/6/local/emacs/25.3/bin/emacs
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [New Thread 0x7fffef071700 (LWP 10664)]
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x000000000043d101 in append_glyph (it=0x7fffffff2390) at xdisp.c:25880
> 25880   xdisp.c: No such file or directory.
> (gdb) bt
> #0  0x000000000043d101 in append_glyph (it=0x7fffffff2390) at xdisp.c:25880
> #1  x_produce_glyphs (it=0x7fffffff2390) at xdisp.c:27175
> #2  0x0000000000452032 in display_line (it=0x7fffffff2390) at xdisp.c:20676
> #3  0x0000000000457868 in try_window (window=18793157, pos=..., flags=1)
> at xdisp.c:17251
> #4  0x0000000000460e41 in redisplay_window (window=18793157,
> just_this_one_p=false)
>     at xdisp.c:16700
> #5  0x0000000000463b36 in redisplay_window_0 (window=<optimized out>) at
> xdisp.c:14491
> #6  0x000000000055e7c6 in internal_condition_case_1 (bfun=0x463b10
> <redisplay_window_0>,
>     arg=18793157, handlers=<optimized out>, hfun=0x429b40
> <redisplay_window_error>)
>     at eval.c:1339
> #7  0x000000000044612e in redisplay_windows (window=<optimized out>) at
> xdisp.c:14471
> #8  0x000000000045cfd5 in redisplay_internal () at xdisp.c:14031
> #9  0x00000000004f5299 in read_char (commandflag=1, map=109811619,
> prev_event=0,
>     used_mouse_menu=0x7fffffffb11f, end_time=0x0) at keyboard.c:2482
> #10 0x00000000004f90c0 in read_key_sequence (keybuf=0x7fffffffb190,
> prompt=0,
>     dont_downcase_last=false, can_return_switch_frame=true,
> fix_current_buffer=true,
>     prevent_redisplay=false, bufsize=30) at keyboard.c:9068
> #11 0x00000000004fa3ba in command_loop_1 () at keyboard.c:1370
> #12 0x000000000055e82a in internal_condition_case (bfun=0x4fa1f0
> <command_loop_1>,
>     handlers=<optimized out>, hfun=0x4f8200 <cmd_error>) at eval.c:1315
> #13 0x00000000004f81ec in command_loop_2 (ignore=<optimized out>) at
> keyboard.c:1112
> #14 0x000000000055e8b8 in internal_catch (tag=<optimized out>,
>     func=0x4f81d0 <command_loop_2>, arg=0) at eval.c:1080
> #15 0x00000000004f7f67 in command_loop () at keyboard.c:1091
> #16 0x00000000004f7ff5 in recursive_edit_1 () at keyboard.c:697
> #17 0x00000000004f8135 in Frecursive_edit () at keyboard.c:768
> #18 0x00000000004e997e in main (argc=<optimized out>, argv=<optimized
> out>) at emacs.c:1629
>
> --
>
> Kaushal Modi
>
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #14 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 20:22:04 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 30 Oct 2017 14:17:57 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x000000000043d101 in append_glyph (it=0x7fffffff2390) at xdisp.c:25880

Line 25880 of xdisp.c is this:

      glyph->charpos = CHARPOS (it->position);

So what is the problematic data here?  Is 'glyph' a NULL pointer or
something?  Or is 'it' a garbled pointer?  What do these commands
show:

  (gdb) p glyph
  (gdb) p glyph->charpos
  (gdb) p it->position

Basically, I need you to run this under a debugger and answer several
questions.  Bonus points for reproducing this in an unoptimized build
configured with --enable-checking='yes,glyphs', and then showing the
backtrace from the segfault.

IOW, this problem needs to be debugged, and for that we need data that
explains the crash.  Could you please help in collecting that data?

Thanks.

Message #17 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29031 <at> debbugs.gnu.org
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 18:34:22 +0000

[Message part 1 (text/plain, inline)]

>
> So what is the problematic data here?  Is 'glyph' a NULL pointer or
> something?  Or is 'it' a garbled pointer?  What do these commands
> show:
>
>   (gdb) p glyph
>   (gdb) p glyph->charpos
>   (gdb) p it->position
>

This is what I got:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x000000000043d101 in append_glyph (it=0x7fffffff2370) at xdisp.c:25880
25880   xdisp.c: No such file or directory.
(gdb) bt
#0  0x000000000043d101 in append_glyph (it=0x7fffffff2370) at xdisp.c:25880
#1  x_produce_glyphs (it=0x7fffffff2370) at xdisp.c:27175
#2  0x0000000000452032 in display_line (it=0x7fffffff2370) at xdisp.c:20676
#3  0x0000000000457868 in try_window (window=18793157, pos=..., flags=1) at
xdisp.c:17251
#4  0x0000000000460e41 in redisplay_window (window=18793157,
just_this_one_p=false)
    at xdisp.c:16700
#5  0x0000000000463b36 in redisplay_window_0 (window=<optimized out>) at
xdisp.c:14491
#6  0x000000000055e7c6 in internal_condition_case_1 (bfun=0x463b10
<redisplay_window_0>,
    arg=18793157, handlers=<optimized out>, hfun=0x429b40
<redisplay_window_error>)
    at eval.c:1339
#7  0x000000000044612e in redisplay_windows (window=<optimized out>) at
xdisp.c:14471
#8  0x000000000045cfd5 in redisplay_internal () at xdisp.c:14031
#9  0x00000000004f5299 in read_char (commandflag=1, map=102809939,
prev_event=0,
    used_mouse_menu=0x7fffffffb0ff, end_time=0x0) at keyboard.c:2482
#10 0x00000000004f90c0 in read_key_sequence (keybuf=0x7fffffffb170,
prompt=0,
    dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true,
    prevent_redisplay=false, bufsize=30) at keyboard.c:9068
#11 0x00000000004fa3ba in command_loop_1 () at keyboard.c:1370
#12 0x000000000055e82a in internal_condition_case (bfun=0x4fa1f0
<command_loop_1>,
    handlers=<optimized out>, hfun=0x4f8200 <cmd_error>) at eval.c:1315
#13 0x00000000004f81ec in command_loop_2 (ignore=<optimized out>) at
keyboard.c:1112
#14 0x000000000055e8b8 in internal_catch (tag=<optimized out>,
    func=0x4f81d0 <command_loop_2>, arg=0) at eval.c:1080
#15 0x00000000004f7f67 in command_loop () at keyboard.c:1091
#16 0x00000000004f7ff5 in recursive_edit_1 () at keyboard.c:697
#17 0x00000000004f8135 in Frecursive_edit () at keyboard.c:768
#18 0x00000000004e997e in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:1629
(gdb) p glyph
$1 = (struct glyph *) 0x8f
(gdb) p glyph->charpos
Cannot access memory at address 0x8f
(gdb) p it->position
$2 = {charpos = 1, bytepos = 1}
(gdb)

Basically, I need you to run this under a debugger and answer several
> questions.  Bonus points for reproducing this in an unoptimized build
> configured with --enable-checking='yes,glyphs', and then showing the
> backtrace from the segfault.
>
> IOW, this problem needs to be debugged, and for that we need data that
> explains the crash.  Could you please help in collecting that data?
>

Sure.

Another data point: I can prevent the crash if I add nlinum-enabling hooks
in window-setup-hook instead of after-init-hook. When using emacsclient
(daemon), I do that nlinum enabling in after-make-frame-functions. So I see
this crash only when running emacs (not emacsclient), on 25.3.

Let me try to build emacs-25 branch with your suggested options.. hopefully
I can recreate the crash on that.

-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #20 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 20:37:27 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 30 Oct 2017 16:03:43 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> 
> **I couldn't reproduce the visual artifact issues or crash on emacs 26.x+.**

Given this, do we really need to debug this issue?  There will be no
more Emacs 25.x releases.

Thanks.

Message #23 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 20:52:07 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 30 Oct 2017 18:34:22 +0000
> Cc: 29031 <at> debbugs.gnu.org
> 
> (gdb) p glyph
> $1 = (struct glyph *) 0x8f
> (gdb) p glyph->charpos
> Cannot access memory at address 0x8f

So the problematic data is 'glyph'.  What do the following print?

  (gdb) p it->area
  (gdb) p it->glyph_row
  (gdb) p it->glyph_row->used[area]

Message #26 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29031 <at> debbugs.gnu.org
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 18:57:27 +0000

[Message part 1 (text/plain, inline)]

On Mon, Oct 30, 2017 at 2:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Kaushal Modi <kaushal.modi <at> gmail.com>
> > Date: Mon, 30 Oct 2017 18:34:22 +0000
> > Cc: 29031 <at> debbugs.gnu.org
> >
> > (gdb) p glyph
> > $1 = (struct glyph *) 0x8f
> > (gdb) p glyph->charpos
> > Cannot access memory at address 0x8f
>
> So the problematic data is 'glyph'.  What do the following print?
>
>   (gdb) p it->area
>   (gdb) p it->glyph_row
>   (gdb) p it->glyph_row->used[area]
>

(gdb) p it->area
$3 = TEXT_AREA
(gdb) p it->glyph_row
$4 = (struct glyph_row *) 0xe487f0
(gdb) p it->glyph_row->used[area]
$5 = 0
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #29 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29031 <at> debbugs.gnu.org
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 19:18:11 +0000

[Message part 1 (text/plain, inline)]

On Mon, Oct 30, 2017 at 2:57 PM Kaushal Modi <kaushal.modi <at> gmail.com> wrote:

> On Mon, Oct 30, 2017 at 2:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Kaushal Modi <kaushal.modi <at> gmail.com>
>> > Date: Mon, 30 Oct 2017 18:34:22 +0000
>> > Cc: 29031 <at> debbugs.gnu.org
>> >
>> > (gdb) p glyph
>> > $1 = (struct glyph *) 0x8f
>> > (gdb) p glyph->charpos
>> > Cannot access memory at address 0x8f
>>
>> So the problematic data is 'glyph'.  What do the following print?
>>
>>   (gdb) p it->area
>>   (gdb) p it->glyph_row
>>   (gdb) p it->glyph_row->used[area]
>>
>
> (gdb) p it->area
> $3 = TEXT_AREA
> (gdb) p it->glyph_row
> $4 = (struct glyph_row *) 0xe487f0
> (gdb) p it->glyph_row->used[area]
> $5 = 0
>

I hate to say this, but I lost that gdb session. I am still able to
consistently segfault on startup (when I load nlinum in after-init-hook).
But this time, it's at a different point. Sorry about that.

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00000033e307a13c in _int_malloc () from /lib64/libc.so.6
(gdb) bt
#0  0x00000033e307a13c in _int_malloc () from /lib64/libc.so.6
#1  0x00000033e307ab1c in malloc () from /lib64/libc.so.6
#2  0x00000000005464ee in lmalloc (size=8188) at alloc.c:1414
#3  lisp_malloc (nbytes=<optimized out>, type=MEM_TYPE_NON_LISP) at
alloc.c:1063
#4  0x0000000000547bef in allocate_string_data (s=0x4fd6600, nchars=369,
nbytes=370) at alloc.c:1998
#5  0x0000000000547dc7 in make_uninit_multibyte_string (nchars=369,
nbytes=370) at alloc.c:2513
#6  0x000000000056ab9b in concat (nargs=25, args=0x7fffffff1750,
target_type=<optimized out>, last_special=<optimized out>) at fns.c:637
#7  0x000000000056b760 in Fmapconcat (function=60420685,
sequence=<optimized out>, separator=60725716) at fns.c:2562
#8  0x000000000055fbb4 in Ffuncall (nargs=<optimized out>,
args=0x7fffffff1958) at eval.c:2706
#9  0x000000000059699d in exec_byte_code (bytestr=<optimized out>,
vector=60420725, maxdepth=<optimized out>,
    args_template=<optimized out>, nargs=<optimized out>, args=<optimized
out>) at bytecode.c:880
#10 0x000000000055f5fa in funcall_lambda (fun=60420901, nargs=<optimized
out>, arg_vector=0x7fffffff1b30) at eval.c:2929
#11 0x000000000055f943 in Ffuncall (nargs=<optimized out>,
args=0x7fffffff1b28) at eval.c:2760
#12 0x000000000059699d in exec_byte_code (bytestr=<optimized out>,
vector=61050749, maxdepth=<optimized out>,
    args_template=<optimized out>, nargs=<optimized out>, args=<optimized
out>) at bytecode.c:880
#13 0x000000000055f5fa in funcall_lambda (fun=61051037, nargs=<optimized
out>, arg_vector=0x7fffffff1c60) at eval.c:2929
#14 0x000000000055ebeb in apply_lambda (fun=61051037, args=0, count=13) at
eval.c:2800
#15 0x000000000055eeb6 in eval_sub (form=<optimized out>) at eval.c:2247
#16 0x0000000000560c92 in Feval (form=61021091, lexical=<optimized out>) at
eval.c:1994
#17 0x000000000055fbc8 in Ffuncall (nargs=<optimized out>,
args=0x7fffffff1df8) at eval.c:2702
#18 0x000000000055e6ce in internal_condition_case_n (bfun=0x55f7a0
<Ffuncall>, nargs=2, args=0x7fffffff1eb0, handlers=<optimized out>,
    hfun=0x447c60 <safe_eval_handler>) at eval.c:1395
#19 0x000000000043ae89 in safe__call (inhibit_quit=true, nargs=2,
func=<optimized out>, ap=<optimized out>) at xdisp.c:2558
#20 0x000000000043b042 in safe__call1 (inhibit_quit=<optimized out>,
fn=<optimized out>) at xdisp.c:2595
#21 0x000000000044fcc3 in safe__eval (sexpr=<optimized out>,
inhibit_quit=true) at xdisp.c:2609
#22 display_mode_element (it=0x7fffffff2360, depth=4, field_width=0,
precision=-82, elt=61021075, props=0, risky=false) at xdisp.c:22863
#23 0x000000000044fe8e in display_mode_element (it=0x7fffffff2360, depth=3,
field_width=0, precision=-82, elt=61119507, props=0,
    risky=false) at xdisp.c:22944
#24 0x000000000044fe8e in display_mode_element (it=0x7fffffff2360, depth=1,
field_width=0, precision=0, elt=61156931, props=0, risky=false)
    at xdisp.c:22944
#25 0x0000000000454cf9 in display_mode_line (w=0x11ec2c0,
face_id=MODE_LINE_FACE_ID, format=61157123) at xdisp.c:22460
#26 0x0000000000454fee in display_mode_lines (w=0x11ec2c0) at xdisp.c:22402
#27 0x00000000004602f7 in redisplay_window (window=18793157,
just_this_one_p=false) at xdisp.c:17066
#28 0x0000000000463b36 in redisplay_window_0 (window=<optimized out>) at
xdisp.c:14491
#29 0x000000000055e7c6 in internal_condition_case_1 (bfun=0x463b10
<redisplay_window_0>, arg=18793157, handlers=<optimized out>,
    hfun=0x429b40 <redisplay_window_error>) at eval.c:1339
#30 0x000000000044612e in redisplay_windows (window=<optimized out>) at
xdisp.c:14471
#31 0x000000000045cfd5 in redisplay_internal () at xdisp.c:14031
#32 0x00000000004f5299 in read_char (commandflag=1, map=100930259,
prev_event=0, used_mouse_menu=0x7fffffffb11f, end_time=0x0)
    at keyboard.c:2482
#33 0x00000000004f90c0 in read_key_sequence (keybuf=0x7fffffffb190,
prompt=0, dont_downcase_last=false, can_return_switch_frame=true,
    fix_current_buffer=true, prevent_redisplay=false, bufsize=30) at
keyboard.c:9068
#34 0x00000000004fa3ba in command_loop_1 () at keyboard.c:1370
#35 0x000000000055e82a in internal_condition_case (bfun=0x4fa1f0
<command_loop_1>, handlers=<optimized out>, hfun=0x4f8200 <cmd_error>)
    at eval.c:1315
#36 0x00000000004f81ec in command_loop_2 (ignore=<optimized out>) at
keyboard.c:1112
#37 0x000000000055e8b8 in internal_catch (tag=<optimized out>,
func=0x4f81d0 <command_loop_2>, arg=0) at eval.c:1080
#38 0x00000000004f7f67 in command_loop () at keyboard.c:1091
#39 0x00000000004f7ff5 in recursive_edit_1 () at keyboard.c:697
#40 0x00000000004f8135 in Frecursive_edit () at keyboard.c:768
#41 0x00000000004e997e in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:1629
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #32 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 19:24:19 +0000

[Message part 1 (text/plain, inline)]

On Mon, Oct 30, 2017 at 2:38 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Kaushal Modi <kaushal.modi <at> gmail.com>
> > Date: Mon, 30 Oct 2017 16:03:43 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>
> >
> > **I couldn't reproduce the visual artifact issues or crash on emacs
> 26.x+.**
>
> Given this, do we really need to debug this issue?  There will be no
> more Emacs 25.x releases.
>

I was wrong that this issue doesn't exist on emacs 26.x (my mistake was
that I was loading native line numbers automatically in my config if emacs
version >+ "26.0"). It seems to exist in a different form if I load nlinum.

I got a SIGABRT on emacs 26.0.90:

Thread 1 "emacs" received signal SIGABRT, Aborted.
0x00000033e3032625 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00000033e3032625 in raise () from /lib64/libc.so.6
#1  0x00000033e3033e05 in abort () from /lib64/libc.so.6
#2  0x00000033e3070537 in __libc_message () from /lib64/libc.so.6
#3  0x00000033e3075f4e in malloc_printerr () from /lib64/libc.so.6
#4  0x00000033e307a614 in _int_malloc () from /lib64/libc.so.6
#5  0x00000033e307ab1c in malloc () from /lib64/libc.so.6
#6  0x00000000005debb2 in lmalloc (size=8188) at alloc.c:1450
#7  0x00000000005de7a5 in lisp_malloc (nbytes=8188, type=MEM_TYPE_NON_LISP)
at alloc.c:1088
#8  0x00000000005df0f7 in allocate_string_data (s=0x21e8370, nchars=70,
nbytes=70) at alloc.c:2024
#9  0x00000000005dfe78 in make_uninit_multibyte_string (nchars=70,
nbytes=70) at alloc.c:2548
#10 0x00000000005dfd3e in make_specified_string (contents=0x7ffffffd6c50
"SOME_FILE__JUST_MASKING_REAL_FILENAME_HERE.v", nchars=70, nbytes=70,
multibyte=false) at alloc.c:2508
#11 0x000000000063cdb4 in read1 (readcharfun=..., pch=0x7ffffffdae5c,
first_in_list=false) at lread.c:3401
#12 0x000000000063e0f5 in read_list (flag=false, readcharfun=...) at
lread.c:3884
#13 0x000000000063af94 in read1 (readcharfun=..., pch=0x7ffffffdf3cc,
first_in_list=false) at lread.c:2692
#14 0x000000000063e0f5 in read_list (flag=false, readcharfun=...) at
lread.c:3884
#15 0x000000000063af94 in read1 (readcharfun=..., pch=0x7ffffffe393c,
first_in_list=false) at lread.c:2692
#16 0x000000000063e0f5 in read_list (flag=false, readcharfun=...) at
lread.c:3884
#17 0x000000000063b023 in read1 (readcharfun=..., pch=0x7ffffffe7eac,
first_in_list=false) at lread.c:2714
#18 0x000000000063a32f in read0 (readcharfun=...) at lread.c:2267
#19 0x000000000063a226 in read_internal_start (stream=..., start=...,
end=...) at lread.c:2233
#20 0x0000000000639f73 in Fread (stream=...) at lread.c:2169
#21 0x000000000060aa27 in funcall_subr (subr=0xc49738 <Sread>, numargs=1,
args=0x7ffffffe80e0) at eval.c:2841
#22 0x000000000060a66e in Ffuncall (nargs=2, args=0x7ffffffe80d8) at
eval.c:2766
#23 0x000000000065705e in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=1, args=0x7ffffffe8848) at
bytecode.c:629
#24 0x000000000060b0a9 in funcall_lambda (fun=..., nargs=1,
arg_vector=0x7ffffffe8840) at eval.c:2967
#25 0x000000000060a6b2 in Ffuncall (nargs=2, args=0x7ffffffe8838) at
eval.c:2768
#26 0x000000000065705e in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x7ffffffe8f60) at
bytecode.c:629
#27 0x000000000060b0a9 in funcall_lambda (fun=..., nargs=0,
arg_vector=0x7ffffffe8f60) at eval.c:2967
#28 0x000000000060adcc in apply_lambda (fun=..., args=..., count=205) at
eval.c:2903
#29 0x0000000000609396 in eval_sub (form=...) at eval.c:2276
#30 0x000000000060556c in Fprogn (body=...) at eval.c:455
#31 0x0000000000608dd2 in eval_sub (form=...) at eval.c:2183
#32 0x00000000006070f9 in internal_lisp_condition_case (var=...,
bodyform=..., handlers=...) at eval.c:1303
#33 0x0000000000606cfa in Fcondition_case (args=...) at eval.c:1227
#34 0x0000000000608dd2 in eval_sub (form=...) at eval.c:2183
#35 0x000000000060556c in Fprogn (body=...) at eval.c:455
#36 0x0000000000608dd2 in eval_sub (form=...) at eval.c:2183
#37 0x000000000060556c in Fprogn (body=...) at eval.c:455
#38 0x000000000060b429 in funcall_lambda (fun=..., nargs=0, arg_vector=0x0)
at eval.c:3042
#39 0x000000000060a789 in Ffuncall (nargs=1, args=0x7ffffffe9940) at
eval.c:2780
#40 0x000000000065705e in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=1, args=0x7ffffffea258) at
bytecode.c:629
#41 0x000000000060b0a9 in funcall_lambda (fun=..., nargs=1,
arg_vector=0x7ffffffea250) at eval.c:2967
#42 0x000000000060a6b2 in Ffuncall (nargs=2, args=0x7ffffffea248) at
eval.c:2768
#43 0x0000000000609aea in funcall_nil (nargs=2, args=0x7ffffffea248) at
eval.c:2397
#44 0x0000000000609ef7 in run_hook_with_args (nargs=2, args=0x7ffffffea248,
funcall=0x609ac7 <funcall_nil>) at eval.c:2574
#45 0x0000000000609b6e in Frun_hook_with_args (nargs=2,
args=0x7ffffffea248) at eval.c:2439
#46 0x000000000060a966 in funcall_subr (subr=0xc47748
<Srun_hook_with_args>, numargs=2, args=0x7ffffffea248) at eval.c:2821
#47 0x000000000060a66e in Ffuncall (nargs=3, args=0x7ffffffea240) at
eval.c:2766
#48 0x000000000065705e in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=1, args=0x7ffffffeaa30) at
bytecode.c:629
#49 0x000000000060b0a9 in funcall_lambda (fun=..., nargs=1,
arg_vector=0x7ffffffeaa28) at eval.c:2967
#50 0x000000000060a6b2 in Ffuncall (nargs=2, args=0x7ffffffeaa20) at
eval.c:2768
#51 0x000000000060a04b in call1 (fn=..., arg1=...) at eval.c:2617
#52 0x000000000063812f in Fload (file=..., noerror=..., nomessage=...,
nosuffix=..., must_suffix=...) at lread.c:1439
#53 0x0000000000617039 in Frequire (feature=..., filename=..., noerror=...)
at fns.c:2807
#54 0x000000000060aa74 in funcall_subr (subr=0xc489a8 <Srequire>,
numargs=3, args=0x7ffffffeaea0) at eval.c:2846
#55 0x000000000060a66e in Ffuncall (nargs=4, args=0x7ffffffeae98) at
eval.c:2766
#56 0x000000000065705e in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:629

...

continues till #224.
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #35 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 21:28:54 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 30 Oct 2017 19:18:11 +0000
> Cc: 29031 <at> debbugs.gnu.org
> 
> I hate to say this, but I lost that gdb session. I am still able to consistently segfault on startup (when I load
> nlinum in after-init-hook). But this time, it's at a different point. Sorry about that.
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x00000033e307a13c in _int_malloc () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00000033e307a13c in _int_malloc () from /lib64/libc.so.6
> #1  0x00000033e307ab1c in malloc () from /lib64/libc.so.6
> #2  0x00000000005464ee in lmalloc (size=8188) at alloc.c:1414
> #3  lisp_malloc (nbytes=<optimized out>, type=MEM_TYPE_NON_LISP) at alloc.c:1063
> #4  0x0000000000547bef in allocate_string_data (s=0x4fd6600, nchars=369, nbytes=370) at alloc.c:1998
> #5  0x0000000000547dc7 in make_uninit_multibyte_string (nchars=369, nbytes=370) at alloc.c:2513
> #6  0x000000000056ab9b in concat (nargs=25, args=0x7fffffff1750, target_type=<optimized out>,
> last_special=<optimized out>) at fns.c:637

Looks like some problem with memory allocation.  Could be a duplicate
of bug#29066?

Anyway, with memory allocation bugs, a tiny change in the recipe can
make the bug go away, so I don't think the evidence you collected till
now can tell us anything useful, except that this is a Heisenbug of
sorts.

Maybe someone else will have an idea for how to debug this further.

Message #38 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 21:34:55 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 30 Oct 2017 19:24:19 +0000
> Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> Thread 1 "emacs" received signal SIGABRT, Aborted.
> 0x00000033e3032625 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00000033e3032625 in raise () from /lib64/libc.so.6
> #1  0x00000033e3033e05 in abort () from /lib64/libc.so.6
> #2  0x00000033e3070537 in __libc_message () from /lib64/libc.so.6
> #3  0x00000033e3075f4e in malloc_printerr () from /lib64/libc.so.6
> #4  0x00000033e307a614 in _int_malloc () from /lib64/libc.so.6
> #5  0x00000033e307ab1c in malloc () from /lib64/libc.so.6
> #6  0x00000000005debb2 in lmalloc (size=8188) at alloc.c:1450
> #7  0x00000000005de7a5 in lisp_malloc (nbytes=8188, type=MEM_TYPE_NON_LISP) at alloc.c:1088
> #8  0x00000000005df0f7 in allocate_string_data (s=0x21e8370, nchars=70, nbytes=70) at alloc.c:2024
> #9  0x00000000005dfe78 in make_uninit_multibyte_string (nchars=70, nbytes=70) at alloc.c:2548
> #10 0x00000000005dfd3e in make_specified_string (contents=0x7ffffffd6c50
> "SOME_FILE__JUST_MASKING_REAL_FILENAME_HERE.v", nchars=70, nbytes=70, multibyte=false) at
> alloc.c:2508

Could be some bug in your glibc on that system?  Otherwise, how come
no one else sees such fundamental problems?

In any case, bugs in memory allocation need to find the code which
corrupted the data structures used by malloc, which happened somewhere
else in the code.  Maybe try running under valgrind (see the advice in
etc/DEBUG under "Running Emacs built with malloc debugging packages").

Message #41 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 21:51:57 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 30 Oct 2017 19:24:19 +0000
> Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> #55 0x000000000060a66e in Ffuncall (nargs=4, args=0x7ffffffeae98) at eval.c:2766
> #56 0x000000000065705e in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=...,
> nargs=0, args=0x0) at bytecode.c:629
> 
> ...
> 
> continues till #224.

Please show the complete backtrace, maybe that will provide some
hints.

Thanks.

Message #44 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 21:36:51 +0000

[Message part 1 (text/plain, inline)]

On Mon, Oct 30, 2017 at 3:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Kaushal Modi <kaushal.modi <at> gmail.com>
> > Date: Mon, 30 Oct 2017 19:24:19 +0000
> > Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> >
> > #55 0x000000000060a66e in Ffuncall (nargs=4, args=0x7ffffffeae98) at
> eval.c:2766
> > #56 0x000000000065705e in exec_byte_code (bytestr=..., vector=...,
> maxdepth=..., args_template=...,
> > nargs=0, args=0x0) at bytecode.c:629
> >
> > ...
> >
> > continues till #224.
>
> Please show the complete backtrace, maybe that will provide some
> hints.
>

After that I rebuilt from the latest emacs-26 with
"--enable-checking='yes,glyphs' --enable-check-lisp-object-type"", and this
time the same recipe (loading nlinum in after-init-hook) caused the
segfault on emacs 26:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00000033e307a16e in _int_malloc () from /lib64/libc.so.6
(gdb) bt
#0  0x00000033e307a16e in _int_malloc () from /lib64/libc.so.6
#1  0x00000033e307ab1c in malloc () from /lib64/libc.so.6
#2  0x0000000000618c68 in lmalloc (size=8784) at alloc.c:1444
#3  0x0000000000618634 in lisp_malloc (nbytes=8784,
type=MEM_TYPE_VECTORLIKE) at alloc.c:1082
#4  0x000000000061b4a2 in allocate_vectorlike (len=1095) at alloc.c:3333
#5  0x000000000061b590 in allocate_vector (len=1095) at alloc.c:3370
#6  0x000000000065aeac in larger_vecalloc (vec=XIL(0x2904c15),
incr_min=365, nitems_max=-1) at fns.c:3600
#7  0x000000000065af3e in larger_vector (vec=XIL(0x2904c15), incr_min=365,
nitems_max=-1) at fns.c:3612
#8  0x000000000065ba06 in maybe_resize_hash_table (h=0x708d390) at
fns.c:3905
#9  0x000000000065be19 in hash_put (h=0x708d390, key=XIL(0xc87060),
value=XIL(0x3171093), hash=3283992) at fns.c:3986
#10 0x000000000065d807 in Fputhash (key=XIL(0xc87060),
value=XIL(0x3171093), table=XIL(0x708d395)) at fns.c:4678
#11 0x00000000005b330e in where_is_internal_1 (key=XIL(0x4ac510),
binding=XIL(0xc87060), args=XIL(0), data=0x7ffffffea9e0)
    at keymap.c:2725
#12 0x00000000005ac350 in map_keymap_item (fun=0x5b3095
<where_is_internal_1>, args=XIL(0), key=XIL(0x4ac510), val=XIL(0xc87060),
    data=0x7ffffffea9e0) at keymap.c:546
#13 0x00000000005ac629 in map_keymap_internal (map=XIL(0x3b10ca3),
fun=0x5b3095 <where_is_internal_1>, args=XIL(0),
    data=0x7ffffffea9e0) at keymap.c:583
#14 0x00000000005ac90a in map_keymap (map=XIL(0x3b10ca3), fun=0x5b3095
<where_is_internal_1>, args=XIL(0), data=0x7ffffffea9e0,
    autoload=false) at keymap.c:626
#15 0x00000000005b2787 in where_is_internal (definition=XIL(0x401f50),
keymaps=XIL(0x315a283), noindirect=false, nomenus=true)
    at keymap.c:2478
#16 0x00000000005b2bdf in Fwhere_is_internal (definition=XIL(0x401f50),
keymap=XIL(0), firstonly=XIL(0xc270), noindirect=XIL(0),
    no_remap=XIL(0)) at keymap.c:2589
#17 0x000000000062f05f in Fsubstitute_command_keys (string=XIL(0x11948c4))
at doc.c:821
#18 0x000000000062dfe2 in Fdocumentation (function=XIL(0x386f6f5),
raw=XIL(0)) at doc.c:421
#19 0x000000000064a905 in funcall_subr (subr=0xd7ea30 <Sdocumentation>,
numargs=1, args=0x7ffffffeef40) at eval.c:2843
#20 0x000000000064a43b in Ffuncall (nargs=2, args=0x7ffffffeef38) at
eval.c:2766
#21 0x000000000069f457 in exec_byte_code (bytestr=XIL(0xab492c),
vector=XIL(0xab494d), maxdepth=make_number(8), args_template=XIL(0),
    nargs=0, args=0x0) at bytecode.c:629
#22 0x000000000064b559 in funcall_lambda (fun=XIL(0xab48cd), nargs=2,
arg_vector=0xab494d <pure+897645>) at eval.c:3049
#23 0x000000000064a47f in Ffuncall (nargs=3, args=0x7ffffffef7e0) at
eval.c:2768
#24 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x1bb5464),
vector=XIL(0x1717335), maxdepth=make_number(4),
    args_template=make_number(257), nargs=1, args=0x7ffffffeff18) at
bytecode.c:629
#25 0x000000000064b04d in funcall_lambda (fun=XIL(0x1717365), nargs=1,
arg_vector=0x7ffffffeff10) at eval.c:2967
#26 0x000000000064a47f in Ffuncall (nargs=2, args=0x7ffffffeff08) at
eval.c:2768
#27 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x1bb8a04),
vector=XIL(0x171c1f5), maxdepth=make_number(16),
---Type <return> to continue, or q <return> to quit---
    umber(257), nargs=1, args=0x7fffffff06e8) at bytecode.c:629
#28 0x000000000064b04d in funcall_lambda (fun=XIL(0x171c275), nargs=1,
arg_vector=0x7fffffff06e0) at eval.c:2967
#29 0x000000000064a47f in Ffuncall (nargs=2, args=0x7fffffff06d8) at
eval.c:2768
#30 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x1bb99e4),
vector=XIL(0x171e3c5), maxdepth=make_number(12),
args_template=make_number(514), nargs=2, args=0x7fffffff0ea0) at
bytecode.c:629
#31 0x000000000064b04d in funcall_lambda (fun=XIL(0x171f0c5), nargs=2,
arg_vector=0x7fffffff0e90) at eval.c:2967
#32 0x000000000064a47f in Ffuncall (nargs=3, args=0x7fffffff0e88) at
eval.c:2768
#33 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x1bb9a84),
vector=XIL(0x171f195), maxdepth=make_number(6),
args_template=make_number(513), nargs=1, args=0x7fffffff15e8) at
bytecode.c:629
#34 0x000000000064b04d in funcall_lambda (fun=XIL(0x171f225), nargs=1,
arg_vector=0x7fffffff15e0) at eval.c:2967
#35 0x000000000064a47f in Ffuncall (nargs=2, args=0x7fffffff15d8) at
eval.c:2768
#36 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x5424b34),
vector=XIL(0x5423815), maxdepth=make_number(5), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#37 0x000000000064b559 in funcall_lambda (fun=XIL(0x5423865), nargs=0,
arg_vector=0x5423815) at eval.c:3049
#38 0x000000000064a47f in Ffuncall (nargs=1, args=0x7fffffff1cf8) at
eval.c:2768
#39 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x541c294),
vector=XIL(0x541bcc5), maxdepth=make_number(5), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#40 0x000000000064b559 in funcall_lambda (fun=XIL(0x541c685), nargs=1,
arg_vector=0x541bcc5) at eval.c:3049
#41 0x000000000064a47f in Ffuncall (nargs=2, args=0x7fffffff2438) at
eval.c:2768
#42 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x541c374),
vector=XIL(0x541c735), maxdepth=make_number(3), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#43 0x000000000064b559 in funcall_lambda (fun=XIL(0x541c765), nargs=0,
arg_vector=0x541c735) at eval.c:3049
#44 0x000000000064a47f in Ffuncall (nargs=1, args=0x7fffffff2b58) at
eval.c:2768
#45 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x54180e4),
vector=XIL(0x5416dd5), maxdepth=make_number(4), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#46 0x000000000064b559 in funcall_lambda (fun=XIL(0x53ea5c5), nargs=1,
arg_vector=0x5416dd5) at eval.c:3049
#47 0x000000000064a47f in Ffuncall (nargs=2, args=0x7fffffff3398) at
eval.c:2768
#48 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x77a18e4),
vector=XIL(0x2ef7b85), maxdepth=make_number(30),
args_template=make_number(2953), nargs=11, args=0x7fffffff3c18) at
bytecode.c:629
#49 0x000000000064b04d in funcall_lambda (fun=XIL(0x43ea6d5), nargs=11,
arg_vector=0x7fffffff3bc0) at eval.c:2967
#50 0x000000000064ac89 in apply_lambda (fun=XIL(0x43ea6d5),
args=XIL(0x2fabe53), count=105) at eval.c:2903
#51 0x0000000000648e9b in eval_sub (form=XIL(0x2fabe63)) at eval.c:2276
#52 0x000000000067f8ef in readevalloop_eager_expand_eval
(val=XIL(0x2fabe63), macroexpand=XIL(0xbe7c0)) at lread.c:1850
#53 0x00000000006802b9 in readevalloop (readcharfun=XIL(0x2a568e5),
infile0=0x0, sourcename=XIL(0x29f3234), printflag=false, unibyte=XIL(0),
readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2036
#54 0x00000000006806d5 in Feval_buffer (buffer=XIL(0x2a568e5),
printflag=XIL(0), filename=XIL(0x2a82b94), unibyte=XIL(0),
do_allow_print=XIL(0xc270)) at lread.c:2103
#55 0x000000000064a9aa in funcall_subr (subr=0xd82178 <Seval_buffer>,
numargs=5, args=0x7fffffff4120) at eval.c:2853
#56 0x000000000064a43b in Ffuncall (nargs=6, args=0x7fffffff4118) at
eval.c:2766
#57 0x000000000069f457 in exec_byte_code (bytestr=XIL(0xa052ec),
vector=XIL(0xa0530d), maxdepth=make_number(6), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#58 0x000000000064b559 in funcall_lambda (fun=XIL(0xa0526d), nargs=4,
arg_vector=0xa0530d <pure+179245>) at eval.c:3049
#59 0x000000000064a47f in Ffuncall (nargs=5, args=0x7fffffff4930) at
eval.c:2768
#60 0x0000000000649e19 in call4 (fn=XIL(0x407a40), arg1=XIL(0x2a82b94),
arg2=XIL(0x2a82b94), arg3=XIL(0xc270), arg4=XIL(0xc270)) at eval.c:2642
#61 0x000000000067e3a6 in Fload (file=XIL(0x2a82a34), noerror=XIL(0xc270),
nomessage=XIL(0xc270), nosuffix=XIL(0xc270), must_suffix=XIL(0)) at
lread.c:1365
#62 0x000000000064a9aa in funcall_subr (subr=0xd82118 <Sload>, numargs=5,
args=0x7fffffff4d40) at eval.c:2853
#63 0x000000000064a43b in Ffuncall (nargs=6, args=0x7fffffff4d38) at
eval.c:2766
#64 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x33558f4),
vector=XIL(0x3341375), maxdepth=make_number(6), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#65 0x000000000064b559 in funcall_lambda (fun=XIL(0x3341405), nargs=5,
arg_vector=0x3341375) at eval.c:3049
#66 0x000000000064a47f in Ffuncall (nargs=6, args=0x7fffffff5470) at
eval.c:2768
#67 0x0000000000649671 in Fapply (nargs=3, args=0x7fffffff5698) at
eval.c:2386
#68 0x000000000064a7f2 in funcall_subr (subr=0xd80188 <Sapply>, numargs=3,
args=0x7fffffff5698) at eval.c:2821
#69 0x000000000064a43b in Ffuncall (nargs=4, args=0x7fffffff5690) at
eval.c:2766
#70 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x13f1f64),
vector=XIL(0x3341185), maxdepth=make_number(5),
args_template=make_number(128), nargs=4, args=0x7fffffff5de8) at
bytecode.c:629
#71 0x000000000064b04d in funcall_lambda (fun=XIL(0x33411b5), nargs=4,
arg_vector=0x7fffffff5de8) at eval.c:2967
#72 0x000000000064a47f in Ffuncall (nargs=5, args=0x7fffffff5de0) at
eval.c:2768
#73 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x779e8a4),
vector=XIL(0x16de0c5), maxdepth=make_number(16),
args_template=make_number(256), nargs=0, args=0x7fffffff6600) at
bytecode.c:629
#74 0x000000000064b04d in funcall_lambda (fun=XIL(0x537b985), nargs=0,
arg_vector=0x7fffffff6600) at eval.c:2967
#75 0x000000000064ac89 in apply_lambda (fun=XIL(0x537b985), args=XIL(0),
count=58) at eval.c:2903
#76 0x0000000000648e9b in eval_sub (form=XIL(0x2ed86e3)) at eval.c:2276
#77 0x000000000064373f in Fprogn (body=XIL(0)) at eval.c:455
#78 0x000000000064b4b9 in funcall_lambda (fun=XIL(0x2ed5733), nargs=0,
arg_vector=0x0) at eval.c:3042
#79 0x000000000064ac89 in apply_lambda (fun=XIL(0x2ed5733), args=XIL(0),
count=57) at eval.c:2903
#80 0x00000000006490a2 in eval_sub (form=XIL(0x2ed8673)) at eval.c:2306
#81 0x000000000064373f in Fprogn (body=XIL(0)) at eval.c:455
#82 0x0000000000648874 in eval_sub (form=XIL(0x2ed55c3)) at eval.c:2183
#83 0x00000000006434e4 in Fif (args=XIL(0x2ed55a3)) at eval.c:410
#84 0x0000000000648874 in eval_sub (form=XIL(0x2ed5593)) at eval.c:2183
#85 0x000000000064373f in Fprogn (body=XIL(0x2edf703)) at eval.c:455
#86 0x0000000000648874 in eval_sub (form=XIL(0x2ed76d3)) at eval.c:2183
#87 0x0000000000646591 in internal_lisp_condition_case (var=XIL(0x7388040),
bodyform=XIL(0x2ed76d3), handlers=XIL(0x2ed7a43)) at eval.c:1303
#88 0x0000000000646023 in Fcondition_case (args=XIL(0x2edf643)) at
eval.c:1227
#89 0x0000000000648874 in eval_sub (form=XIL(0x2edf633)) at eval.c:2183
#90 0x000000000064373f in Fprogn (body=XIL(0x2ed7d53)) at eval.c:455
#91 0x000000000064352d in Fif (args=XIL(0x2edf613)) at eval.c:411
#92 0x0000000000648874 in eval_sub (form=XIL(0x2edf623)) at eval.c:2183
#93 0x000000000067f8ef in readevalloop_eager_expand_eval
(val=XIL(0x2ed7b73), macroexpand=XIL(0xbe7c0)) at lread.c:1850
#94 0x00000000006802b9 in readevalloop (readcharfun=XIL(0x4f08de5),
infile0=0x0, sourcename=XIL(0x71213b4), printflag=false, unibyte=XIL(0),
readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2036
#95 0x00000000006806d5 in Feval_buffer (buffer=XIL(0x4f08de5),
printflag=XIL(0), filename=XIL(0x70b9bb4), unibyte=XIL(0),
do_allow_print=XIL(0xc270)) at lread.c:2103
#96 0x000000000064a9aa in funcall_subr (subr=0xd82178 <Seval_buffer>,
numargs=5, args=0x7fffffff77d0) at eval.c:2853
#97 0x000000000064a43b in Ffuncall (nargs=6, args=0x7fffffff77c8) at
eval.c:2766
#98 0x000000000069f457 in exec_byte_code (bytestr=XIL(0xa052ec),
vector=XIL(0xa0530d), maxdepth=make_number(6), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#99 0x000000000064b559 in funcall_lambda (fun=XIL(0xa0526d), nargs=4,
arg_vector=0xa0530d <pure+179245>) at eval.c:3049
#100 0x000000000064a47f in Ffuncall (nargs=5, args=0x7fffffff7fe0) at
eval.c:2768
#101 0x0000000000649e19 in call4 (fn=XIL(0x407a40), arg1=XIL(0x70b9bb4),
arg2=XIL(0x70b9bb4), arg3=XIL(0xc270), arg4=XIL(0xc270)) at eval.c:2642
#102 0x000000000067e3a6 in Fload (file=XIL(0x81074f4), noerror=XIL(0xc270),
nomessage=XIL(0xc270), nosuffix=XIL(0), must_suffix=XIL(0xc270)) at
lread.c:1365
#103 0x0000000000658d08 in Frequire (feature=XIL(0x7394dc0),
filename=XIL(0), noerror=XIL(0xc270)) at fns.c:2807
#104 0x000000000064a931 in funcall_subr (subr=0xd81448 <Srequire>,
numargs=3, args=0x7fffffff8480) at eval.c:2846
#105 0x000000000064a43b in Ffuncall (nargs=4, args=0x7fffffff8478) at
eval.c:2766
#106 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x3346694),
vector=XIL(0x3340d05), maxdepth=make_number(4), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#107 0x000000000064b559 in funcall_lambda (fun=XIL(0x3340d95), nargs=4,
arg_vector=0x3340d05) at eval.c:3049
#108 0x000000000064a47f in Ffuncall (nargs=5, args=0x7fffffff8ba0) at
eval.c:2768
#109 0x0000000000649671 in Fapply (nargs=3, args=0x7fffffff8dc8) at
eval.c:2386
#110 0x000000000064a7f2 in funcall_subr (subr=0xd80188 <Sapply>, numargs=3,
args=0x7fffffff8dc8) at eval.c:2821
#111 0x000000000064a43b in Ffuncall (nargs=4, args=0x7fffffff8dc0) at
eval.c:2766
#112 0x000000000069f457 in exec_byte_code (bytestr=XIL(0x13f1f64),
vector=XIL(0x3340aa5), maxdepth=make_number(5),
args_template=make_number(128), nargs=3, args=0x7fffffff94d8) at
bytecode.c:629
#113 0x000000000064b04d in funcall_lambda (fun=XIL(0x3340ad5), nargs=3,
arg_vector=0x7fffffff94d8) at eval.c:2967
#114 0x000000000064a47f in Ffuncall (nargs=4, args=0x7fffffff94d0) at
eval.c:2768
#115 0x0000000000649671 in Fapply (nargs=2, args=0x7fffffff96f8) at
eval.c:2386
#116 0x000000000064a7f2 in funcall_subr (subr=0xd80188 <Sapply>, numargs=2,
args=0x7fffffff96f8) at eval.c:2821
#117 0x000000000064a43b in Ffuncall (nargs=3, args=0x7fffffff96f0) at
eval.c:2766
#118 0x000000000069f457 in exec_byte_code (bytestr=XIL(0xb0c4ac),
vector=XIL(0xb0c4cd), maxdepth=make_number(10),
args_template=make_number(257), nargs=1, args=0x7fffffff9ef0) at
bytecode.c:629
#119 0x000000000064b04d in funcall_lambda (fun=XIL(0xb0c47d), nargs=1,
arg_vector=0x7fffffff9ee8) at eval.c:2967
#120 0x000000000064a47f in Ffuncall (nargs=2, args=0x7fffffff9ee0) at
eval.c:2768
#121 0x0000000000649d38 in call1 (fn=XIL(0xc600), arg1=XIL(0x8182745)) at
eval.c:2617
#122 0x000000000059a0de in timer_check_2 (timers=XIL(0x2ecdbd3),
idle_timers=XIL(0x2ecdaf3)) at keyboard.c:4462
#123 0x000000000059a209 in timer_check () at keyboard.c:4524
#124 0x00000000005978d4 in readable_events (flags=1) at keyboard.c:3340
#125 0x000000000059f029 in get_input_pending (flags=1) at keyboard.c:6824
#126 0x00000000005a6a40 in detect_input_pending_run_timers
(do_display=true) at keyboard.c:9951
#127 0x00000000006af724 in wait_reading_process_output (time_limit=0,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0,
just_wait_proc=0) at process.c:5508
#128 0x00000000005988bc in kbd_buffer_get_event (kbp=0x7fffffffa738,
used_mouse_menu=0x7fffffffaeaf, end_time=0x0) at keyboard.c:3831
#129 0x0000000000593bea in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffffabe0, used_mouse_menu=0x7fffffffaeaf) at
keyboard.c:2151
#130 0x0000000000593ee2 in read_decoded_event_from_main_queue
(end_time=0x0, local_getcjmp=0x7fffffffabe0, prev_event=XIL(0),
used_mouse_menu=0x7fffffffaeaf) at keyboard.c:2214
#131 0x0000000000595bc2 in read_char (commandflag=1, map=XIL(0x2d51ba3),
prev_event=XIL(0), used_mouse_menu=0x7fffffffaeaf, end_time=0x0) at
keyboard.c:2802
#132 0x00000000005a4d85 in read_key_sequence (keybuf=0x7fffffffb040,
bufsize=30, prompt=XIL(0), dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9147
#133 0x0000000000591833 in command_loop_1 () at keyboard.c:1368
#134 0x000000000064662d in internal_condition_case (bfun=0x591400
<command_loop_1>, handlers=XIL(0x5250), hfun=0x590a56 <cmd_error>) at
eval.c:1332
#135 0x0000000000591005 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#136 0x0000000000645b61 in internal_catch (tag=XIL(0xc8d0), func=0x590fdc
<command_loop_2>, arg=XIL(0)) at eval.c:1097
#137 0x0000000000590fa7 in command_loop () at keyboard.c:1089
#138 0x000000000059056b in recursive_edit_1 () at keyboard.c:695
#139 0x000000000059074a in Frecursive_edit () at keyboard.c:766
#140 0x000000000058e447 in main (argc=1, argv=0x7fffffffb528) at
emacs.c:1713

Lisp Backtrace:
"documentation" (0xfffeef40)
"help-function-arglist" (0xfffef7e8)
"ad-arglist" (0xfffeff10)
"ad-make-advised-definition" (0xffff06e0)
"ad-activate-advised-definition" (0xffff0e90)
"ad-activate" (0xffff15e0)
"vhl/ext/etags/on" (0xffff1d00)
"vhl/load-extension" (0xffff2440)
"vhl/load-extensions" (0xffff2b60)
"volatile-highlights-mode" (0xffff33a0)
"desktop-create-buffer" (0xffff3bc0)
"eval-buffer" (0xffff4120)
"load-with-code-conversion" (0xffff4938)
0xd82118 PVEC_SUBR
"ad-Advice-load" (0xffff5478)
"apply" (0xffff5698)
"load" (0xffff5de8)
"desktop-read" (0xffff6600)
"modi/restore-last-saved-desktop" (0xffff6920)
"progn" (0xffff6c20)
"if" (0xffff6dc0)
"progn" (0xffff6f60)
"condition-case" (0xffff7250)
"if" (0xffff7430)
"eval-buffer" (0xffff77d0)
"load-with-code-conversion" (0xffff7fe8)
0xd81448 PVEC_SUBR
"ad-Advice-require" (0xffff8ba8)
"apply" (0xffff8dc8)
"require" (0xffff94d8)
"apply" (0xffff96f8)
"timer-event-handler" (0xffff9ee8)

I'll keep that gdb session alive for further debugging if needed.
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #47 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Tue, 31 Oct 2017 22:26:21 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Mon, 30 Oct 2017 21:36:51 +0000
> Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> After that I rebuilt from the latest emacs-26 with "--enable-checking='yes,glyphs'
> --enable-check-lisp-object-type"", and this time the same recipe (loading nlinum in after-init-hook) caused the
> segfault on emacs 26:

Can you try the latest emacs-26 branch, and see if the problem still
persists?

Thanks.

Message #50 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Tue, 31 Oct 2017 20:52:23 +0000

[Message part 1 (text/plain, inline)]

On Tue, Oct 31, 2017 at 4:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

>
> Can you try the latest emacs-26 branch, and see if the problem still
> persists?
>

This time, I got SIGABRT again.

PS: While I have the gdb emacs in a limbo state after the below SIGABRT,
"emacsclient -a '' -c" stays stuck at "Waiting for Emacs...". I can start
emacsclient as usual only after I kill the gdb session. Is there a way to
keep the gdb session on emacs binary separate from my emacsclient launching?

Backtrace:
=====
Thread 1 "emacs" received signal SIGABRT, Aborted.
0x00000033e3032625 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00000033e3032625 in raise () from /lib64/libc.so.6
#1  0x00000033e3033e05 in abort () from /lib64/libc.so.6
#2  0x00000033e3070537 in __libc_message () from /lib64/libc.so.6
#3  0x00000033e3075f4e in malloc_printerr () from /lib64/libc.so.6
#4  0x00000033e307a614 in _int_malloc () from /lib64/libc.so.6
#5  0x00000033e307ab1c in malloc () from /lib64/libc.so.6
#6  0x0000000000618c68 in lmalloc (size=8188) at alloc.c:1444
#7  0x0000000000618634 in lisp_malloc (nbytes=8188, type=MEM_TYPE_NON_LISP)
at alloc.c:1082
#8  0x000000000061921a in allocate_string_data (s=0x5a7da80, nchars=62,
nbytes=62) at alloc.c:2018
#9  0x000000000061a026 in make_uninit_multibyte_string (nchars=62,
nbytes=62) at alloc.c:2542
#10 0x0000000000619eec in make_specified_string (contents=0x7ffffffd7d30
"SOME_FILE.vv", nchars=62, nbytes=62, multibyte=false) at alloc.c:2502
#11 0x0000000000683af4 in read1 (readcharfun=XIL(0x6726404),
pch=0x7ffffffdbf3c, first_in_list=false) at lread.c:3401
#12 0x0000000000684f37 in read_list (flag=false,
readcharfun=XIL(0x6726404)) at lread.c:3884
#13 0x0000000000681965 in read1 (readcharfun=XIL(0x6726404),
pch=0x7ffffffe04ac, first_in_list=false) at lread.c:2692
#14 0x0000000000684f37 in read_list (flag=false,
readcharfun=XIL(0x6726404)) at lread.c:3884
#15 0x0000000000681965 in read1 (readcharfun=XIL(0x6726404),
pch=0x7ffffffe4a1c, first_in_list=false) at lread.c:2692
#16 0x0000000000684f37 in read_list (flag=false,
readcharfun=XIL(0x6726404)) at lread.c:3884
#17 0x00000000006819f4 in read1 (readcharfun=XIL(0x6726404),
pch=0x7ffffffe8f8c, first_in_list=false) at lread.c:2714
#18 0x0000000000680d00 in read0 (readcharfun=XIL(0x6726404)) at lread.c:2267
#19 0x0000000000680bf7 in read_internal_start (stream=XIL(0x6726404),
start=XIL(0), end=XIL(0)) at lread.c:2233
#20 0x00000000006808ee in Fread (stream=XIL(0x6726404)) at lread.c:2169
#21 0x000000000064a8f8 in funcall_subr (subr=0xd821d8 <Sread>, numargs=1,
args=0x7ffffffe91c0) at eval.c:2841
#22 0x000000000064a44f in Ffuncall (nargs=2, args=0x7ffffffe91b8) at
eval.c:2766
#23 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x5244254),
vector=XIL(0x41a9d55), maxdepth=make_number(8),
args_template=make_number(257), nargs=1, args=0x7ffffffe9928) at
bytecode.c:629
#24 0x000000000064b061 in funcall_lambda (fun=XIL(0x41a9de5), nargs=1,
arg_vector=0x7ffffffe9920) at eval.c:2967
#25 0x000000000064a493 in Ffuncall (nargs=2, args=0x7ffffffe9918) at
eval.c:2768
#26 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x646e794),
vector=XIL(0x77a2095), maxdepth=make_number(7),
args_template=make_number(256), nargs=0, args=0x7ffffffea040) at
bytecode.c:629
#27 0x000000000064b061 in funcall_lambda (fun=XIL(0x76c90e5), nargs=0,
arg_vector=0x7ffffffea040) at eval.c:2967
#28 0x000000000064ac9d in apply_lambda (fun=XIL(0x76c90e5), args=XIL(0),
count=205) at eval.c:2903
#29 0x0000000000648eaf in eval_sub (form=XIL(0x715b953)) at eval.c:2276
#30 0x0000000000643753 in Fprogn (body=XIL(0)) at eval.c:455
#31 0x0000000000648888 in eval_sub (form=XIL(0x7159f53)) at eval.c:2183
#32 0x00000000006465a5 in internal_lisp_condition_case (var=XIL(0x6364520),
bodyform=XIL(0x7159f53), handlers=XIL(0x7159c23)) at eval.c:1303
#33 0x0000000000646037 in Fcondition_case (args=XIL(0x71bcfb3)) at
eval.c:1227
#34 0x0000000000648888 in eval_sub (form=XIL(0x71bcfc3)) at eval.c:2183
#35 0x0000000000643753 in Fprogn (body=XIL(0x715ad53)) at eval.c:455
#36 0x0000000000648888 in eval_sub (form=XIL(0x71bcfd3)) at eval.c:2183
#37 0x0000000000643753 in Fprogn (body=XIL(0)) at eval.c:455
#38 0x000000000064b4cd in funcall_lambda (fun=XIL(0x71bc823), nargs=0,
arg_vector=0x0) at eval.c:3042
#39 0x000000000064a595 in Ffuncall (nargs=1, args=0x7ffffffeaa20) at
eval.c:2780
#40 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x9fcf74),
vector=XIL(0x77a22d5), maxdepth=make_number(4),
args_template=make_number(257), nargs=1, args=0x7ffffffeb338) at
bytecode.c:629
#41 0x000000000064b061 in funcall_lambda (fun=XIL(0x77a2305), nargs=1,
arg_vector=0x7ffffffeb330) at eval.c:2967
#42 0x000000000064a493 in Ffuncall (nargs=2, args=0x7ffffffeb328) at
eval.c:2768
#43 0x00000000006496e1 in funcall_nil (nargs=2, args=0x7ffffffeb328) at
eval.c:2397
#44 0x0000000000649bcd in run_hook_with_args (nargs=2, args=0x7ffffffeb328,
funcall=0x6496be <funcall_nil>) at eval.c:2574
#45 0x0000000000649765 in Frun_hook_with_args (nargs=2,
args=0x7ffffffeb328) at eval.c:2439
#46 0x000000000064a806 in funcall_subr (subr=0xd801e8
<Srun_hook_with_args>, numargs=2, args=0x7ffffffeb328) at eval.c:2821
#47 0x000000000064a44f in Ffuncall (nargs=3, args=0x7ffffffeb320) at
eval.c:2766
#48 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x9fd104),
vector=XIL(0x9fd125), maxdepth=make_number(10),
args_template=make_number(257), nargs=1, args=0x7ffffffebb10) at
bytecode.c:629
#49 0x000000000064b061 in funcall_lambda (fun=XIL(0x9fd0d5), nargs=1,
arg_vector=0x7ffffffebb08) at eval.c:2967
#50 0x000000000064a493 in Ffuncall (nargs=2, args=0x7ffffffebb00) at
eval.c:2768
#51 0x0000000000649d4c in call1 (fn=XIL(0x4d70), arg1=XIL(0x30668b4)) at
eval.c:2617
#52 0x000000000067e743 in Fload (file=XIL(0x1a64964), noerror=XIL(0),
nomessage=XIL(0xc270), nosuffix=XIL(0), must_suffix=XIL(0xc270)) at
lread.c:1439
#53 0x0000000000658d1c in Frequire (feature=XIL(0xc2fd50), filename=XIL(0),
noerror=XIL(0)) at fns.c:2807
#54 0x000000000064a945 in funcall_subr (subr=0xd81448 <Srequire>,
numargs=3, args=0x7ffffffebf80) at eval.c:2846
#55 0x000000000064a44f in Ffuncall (nargs=4, args=0x7ffffffebf78) at
eval.c:2766
#56 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x33487a4),
vector=XIL(0x3340d05), maxdepth=make_number(4), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#57 0x000000000064b56d in funcall_lambda (fun=XIL(0x3340d95), nargs=2,
arg_vector=0x3340d05) at eval.c:3049
#58 0x000000000064a493 in Ffuncall (nargs=3, args=0x7ffffffec888) at
eval.c:2768
#59 0x0000000000649275 in Fapply (nargs=3, args=0x7ffffffec888) at
eval.c:2343
#60 0x000000000064a806 in funcall_subr (subr=0xd80188 <Sapply>, numargs=3,
args=0x7ffffffec888) at eval.c:2821
#61 0x000000000064a44f in Ffuncall (nargs=4, args=0x7ffffffec880) at
eval.c:2766
#62 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x13f1f64),
vector=XIL(0x3340aa5), maxdepth=make_number(5),
args_template=make_number(128), nargs=1, args=0x7ffffffecfa0) at
bytecode.c:629
---Type <return> to continue, or q <return> to quit---
#63 0x000000000064b061 in funcall_lambda (fun=XIL(0x3340ad5), nargs=1,
arg_vector=0x7ffffffecfa0) at eval.c:2967
#64 0x000000000064a493 in Ffuncall (nargs=2, args=0x7ffffffecf98) at
eval.c:2768
#65 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x53e1a44),
vector=XIL(0x2ee40b5), maxdepth=make_number(8), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#66 0x000000000069e725 in Fbyte_code (bytestr=XIL(0x53e1a44),
vector=XIL(0x2ee40b5), maxdepth=make_number(8)) at bytecode.c:321
#67 0x0000000000648d05 in eval_sub (form=XIL(0x31ce9e3)) at eval.c:2237
#68 0x00000000006802df in readevalloop (readcharfun=XIL(0x68a0),
infile0=0x7ffffffed9c0, sourcename=XIL(0x53e1a04), printflag=false,
unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2038
#69 0x000000000067e650 in Fload (file=XIL(0x1a67e64), noerror=XIL(0xc270),
nomessage=XIL(0xc270), nosuffix=XIL(0), must_suffix=XIL(0xc270)) at
lread.c:1425
#70 0x0000000000658d1c in Frequire (feature=XIL(0xc2acc0), filename=XIL(0),
noerror=XIL(0xc270)) at fns.c:2807
#71 0x000000000064a945 in funcall_subr (subr=0xd81448 <Srequire>,
numargs=3, args=0x7ffffffedc70) at eval.c:2846
#72 0x000000000064a44f in Ffuncall (nargs=4, args=0x7ffffffedc68) at
eval.c:2766
#73 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x33487a4),
vector=XIL(0x3340d05), maxdepth=make_number(4), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#74 0x000000000064b56d in funcall_lambda (fun=XIL(0x3340d95), nargs=4,
arg_vector=0x3340d05) at eval.c:3049
#75 0x000000000064a493 in Ffuncall (nargs=5, args=0x7ffffffee390) at
eval.c:2768
#76 0x0000000000649685 in Fapply (nargs=3, args=0x7ffffffee5b8) at
eval.c:2386
#77 0x000000000064a806 in funcall_subr (subr=0xd80188 <Sapply>, numargs=3,
args=0x7ffffffee5b8) at eval.c:2821
#78 0x000000000064a44f in Ffuncall (nargs=4, args=0x7ffffffee5b0) at
eval.c:2766
#79 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x13f1f64),
vector=XIL(0x3340aa5), maxdepth=make_number(5),
args_template=make_number(128), nargs=3, args=0x7ffffffeec40) at
bytecode.c:629
#80 0x000000000064b061 in funcall_lambda (fun=XIL(0x3340ad5), nargs=3,
arg_vector=0x7ffffffeec40) at eval.c:2967
#81 0x000000000064ac9d in apply_lambda (fun=XIL(0x3340ad5),
args=XIL(0x56205b3), count=153) at eval.c:2903
#82 0x0000000000648eaf in eval_sub (form=XIL(0x56205c3)) at eval.c:2276
#83 0x0000000000648be8 in eval_sub (form=XIL(0x56205e3)) at eval.c:2219
#84 0x000000000064349a in Fif (args=XIL(0x56203b3)) at eval.c:407
#85 0x0000000000648888 in eval_sub (form=XIL(0x56203a3)) at eval.c:2183
#86 0x0000000000643753 in Fprogn (body=XIL(0x55eb3d3)) at eval.c:455
#87 0x0000000000648888 in eval_sub (form=XIL(0x561fc13)) at eval.c:2183
#88 0x00000000006465a5 in internal_lisp_condition_case (var=XIL(0x4824ba0),
bodyform=XIL(0x561fc13), handlers=XIL(0x55ea163)) at eval.c:1303
#89 0x0000000000646037 in Fcondition_case (args=XIL(0x561fd33)) at
eval.c:1227
#90 0x0000000000648888 in eval_sub (form=XIL(0x561fd43)) at eval.c:2183
#91 0x0000000000643753 in Fprogn (body=XIL(0x55eaa03)) at eval.c:455
#92 0x0000000000648888 in eval_sub (form=XIL(0x561fd53)) at eval.c:2183
#93 0x0000000000643753 in Fprogn (body=XIL(0)) at eval.c:455
#94 0x000000000064b4cd in funcall_lambda (fun=XIL(0x561fd83), nargs=0,
arg_vector=0x0) at eval.c:3042
#95 0x000000000064a595 in Ffuncall (nargs=1, args=0x7ffffffef940) at
eval.c:2780
#96 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x9fcf74),
vector=XIL(0x4317255), maxdepth=make_number(4),
args_template=make_number(257), nargs=1, args=0x7fffffff0258) at
bytecode.c:629
#97 0x000000000064b061 in funcall_lambda (fun=XIL(0x70743e5), nargs=1,
arg_vector=0x7fffffff0250) at eval.c:2967
#98 0x000000000064a493 in Ffuncall (nargs=2, args=0x7fffffff0248) at
eval.c:2768
#99 0x00000000006496e1 in funcall_nil (nargs=2, args=0x7fffffff0248) at
eval.c:2397
#100 0x0000000000649bcd in run_hook_with_args (nargs=2,
args=0x7fffffff0248, funcall=0x6496be <funcall_nil>) at eval.c:2574
#101 0x0000000000649765 in Frun_hook_with_args (nargs=2,
args=0x7fffffff0248) at eval.c:2439
#102 0x000000000064a806 in funcall_subr (subr=0xd801e8
<Srun_hook_with_args>, numargs=2, args=0x7fffffff0248) at eval.c:2821
#103 0x000000000064a44f in Ffuncall (nargs=3, args=0x7fffffff0240) at
eval.c:2766
#104 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x9fd104),
vector=XIL(0x9fd125), maxdepth=make_number(10),
args_template=make_number(257), nargs=1, args=0x7fffffff0a30) at
bytecode.c:629
#105 0x000000000064b061 in funcall_lambda (fun=XIL(0x9fd0d5), nargs=1,
arg_vector=0x7fffffff0a28) at eval.c:2967
#106 0x000000000064a493 in Ffuncall (nargs=2, args=0x7fffffff0a20) at
eval.c:2768
#107 0x0000000000649d4c in call1 (fn=XIL(0x4d70), arg1=XIL(0x1b89754)) at
eval.c:2617
#108 0x000000000067e743 in Fload (file=XIL(0x1379494), noerror=XIL(0),
nomessage=XIL(0xc270), nosuffix=XIL(0), must_suffix=XIL(0xc270)) at
lread.c:1439
#109 0x0000000000658d1c in Frequire (feature=XIL(0x59afc0),
filename=XIL(0), noerror=XIL(0)) at fns.c:2807
#110 0x000000000064a945 in funcall_subr (subr=0xd81448 <Srequire>,
numargs=3, args=0x7fffffff0ea0) at eval.c:2846
#111 0x000000000064a44f in Ffuncall (nargs=4, args=0x7fffffff0e98) at
eval.c:2766
#112 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x33487a4),
vector=XIL(0x3340d05), maxdepth=make_number(4), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#113 0x000000000064b56d in funcall_lambda (fun=XIL(0x3340d95), nargs=2,
arg_vector=0x3340d05) at eval.c:3049
#114 0x000000000064a493 in Ffuncall (nargs=3, args=0x7fffffff17a8) at
eval.c:2768
#115 0x0000000000649275 in Fapply (nargs=3, args=0x7fffffff17a8) at
eval.c:2343
#116 0x000000000064a806 in funcall_subr (subr=0xd80188 <Sapply>, numargs=3,
args=0x7fffffff17a8) at eval.c:2821
#117 0x000000000064a44f in Ffuncall (nargs=4, args=0x7fffffff17a0) at
eval.c:2766
#118 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x13f1f64),
vector=XIL(0x3340aa5), maxdepth=make_number(5),
args_template=make_number(128), nargs=1, args=0x7fffffff1ec0) at
bytecode.c:629
#119 0x000000000064b061 in funcall_lambda (fun=XIL(0x3340ad5), nargs=1,
arg_vector=0x7fffffff1ec0) at eval.c:2967
#120 0x000000000064a493 in Ffuncall (nargs=2, args=0x7fffffff1eb8) at
eval.c:2768
#121 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x23de074),
vector=XIL(0x5261635), maxdepth=make_number(4), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#122 0x000000000069e725 in Fbyte_code (bytestr=XIL(0x23de074),
vector=XIL(0x5261635), maxdepth=make_number(4)) at bytecode.c:321
#123 0x0000000000648d05 in eval_sub (form=XIL(0x30cb143)) at eval.c:2237
#124 0x00000000006802df in readevalloop (readcharfun=XIL(0x68a0),
infile0=0x7fffffff28d0, sourcename=XIL(0x23de034), printflag=false,
unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2038
#125 0x000000000067e650 in Fload (file=XIL(0x2a4e114), noerror=XIL(0),
nomessage=XIL(0xc270), nosuffix=XIL(0), must_suffix=XIL(0xc270)) at
lread.c:1425
---Type <return> to continue, or q <return> to quit---
#126 0x00000000006480fb in Fautoload_do_load (fundef=XIL(0x2a4d153),
funname=XIL(0x1c52620), macro_only=XIL(0)) at eval.c:2019
#127 0x000000000064a945 in funcall_subr (subr=0xd80128 <Sautoload_do_load>,
numargs=2, args=0x7fffffff2b88) at eval.c:2846
#128 0x000000000064a44f in Ffuncall (nargs=3, args=0x7fffffff2b80) at
eval.c:2766
#129 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x772ad24),
vector=XIL(0x531e7f5), maxdepth=make_number(7),
args_template=make_number(257), nargs=1, args=0x7fffffff33a0) at
bytecode.c:629
#130 0x000000000064b061 in funcall_lambda (fun=XIL(0x4ec3e35), nargs=1,
arg_vector=0x7fffffff3398) at eval.c:2967
#131 0x000000000064a493 in Ffuncall (nargs=2, args=0x7fffffff3390) at
eval.c:2768
#132 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x772aca4),
vector=XIL(0x2ef7d05), maxdepth=make_number(30),
args_template=make_number(2953), nargs=11, args=0x7fffffff3c18) at
bytecode.c:629
#133 0x000000000064b061 in funcall_lambda (fun=XIL(0x4ec4555), nargs=11,
arg_vector=0x7fffffff3bc0) at eval.c:2967
#134 0x000000000064ac9d in apply_lambda (fun=XIL(0x4ec4555),
args=XIL(0x2f275b3), count=105) at eval.c:2903
#135 0x0000000000648eaf in eval_sub (form=XIL(0x2f275c3)) at eval.c:2276
#136 0x000000000067f903 in readevalloop_eager_expand_eval
(val=XIL(0x2f275c3), macroexpand=XIL(0xbc7b0)) at lread.c:1850
#137 0x00000000006802cd in readevalloop (readcharfun=XIL(0x52aa375),
infile0=0x0, sourcename=XIL(0x7776434), printflag=false, unibyte=XIL(0),
readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2036
#138 0x00000000006806e9 in Feval_buffer (buffer=XIL(0x52aa375),
printflag=XIL(0), filename=XIL(0x7764dc4), unibyte=XIL(0),
do_allow_print=XIL(0xc270)) at lread.c:2103
#139 0x000000000064a9be in funcall_subr (subr=0xd82178 <Seval_buffer>,
numargs=5, args=0x7fffffff4120) at eval.c:2853
#140 0x000000000064a44f in Ffuncall (nargs=6, args=0x7fffffff4118) at
eval.c:2766
#141 0x000000000069f46b in exec_byte_code (bytestr=XIL(0xa052ec),
vector=XIL(0xa0530d), maxdepth=make_number(6), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#142 0x000000000064b56d in funcall_lambda (fun=XIL(0xa0526d), nargs=4,
arg_vector=0xa0530d <pure+179245>) at eval.c:3049
#143 0x000000000064a493 in Ffuncall (nargs=5, args=0x7fffffff4930) at
eval.c:2768
#144 0x0000000000649e2d in call4 (fn=XIL(0x407a40), arg1=XIL(0x7764dc4),
arg2=XIL(0x7764dc4), arg3=XIL(0xc270), arg4=XIL(0xc270)) at eval.c:2642
#145 0x000000000067e3ba in Fload (file=XIL(0x7764f24), noerror=XIL(0xc270),
nomessage=XIL(0xc270), nosuffix=XIL(0xc270), must_suffix=XIL(0)) at
lread.c:1365
#146 0x000000000064a9be in funcall_subr (subr=0xd82118 <Sload>, numargs=5,
args=0x7fffffff4d40) at eval.c:2853
#147 0x000000000064a44f in Ffuncall (nargs=6, args=0x7fffffff4d38) at
eval.c:2766
#148 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x3355a74),
vector=XIL(0x3341375), maxdepth=make_number(6), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#149 0x000000000064b56d in funcall_lambda (fun=XIL(0x3341405), nargs=5,
arg_vector=0x3341375) at eval.c:3049
#150 0x000000000064a493 in Ffuncall (nargs=6, args=0x7fffffff5470) at
eval.c:2768
#151 0x0000000000649685 in Fapply (nargs=3, args=0x7fffffff5698) at
eval.c:2386
#152 0x000000000064a806 in funcall_subr (subr=0xd80188 <Sapply>, numargs=3,
args=0x7fffffff5698) at eval.c:2821
#153 0x000000000064a44f in Ffuncall (nargs=4, args=0x7fffffff5690) at
eval.c:2766
#154 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x13f1f64),
vector=XIL(0x3341185), maxdepth=make_number(5),
args_template=make_number(128), nargs=4, args=0x7fffffff5de8) at
bytecode.c:629
#155 0x000000000064b061 in funcall_lambda (fun=XIL(0x33411b5), nargs=4,
arg_vector=0x7fffffff5de8) at eval.c:2967
#156 0x000000000064a493 in Ffuncall (nargs=5, args=0x7fffffff5de0) at
eval.c:2768
#157 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x7726464),
vector=XIL(0x16de145), maxdepth=make_number(16),
args_template=make_number(256), nargs=0, args=0x7fffffff6600) at
bytecode.c:629
#158 0x000000000064b061 in funcall_lambda (fun=XIL(0x542e755), nargs=0,
arg_vector=0x7fffffff6600) at eval.c:2967
#159 0x000000000064ac9d in apply_lambda (fun=XIL(0x542e755), args=XIL(0),
count=58) at eval.c:2903
#160 0x0000000000648eaf in eval_sub (form=XIL(0x2edf323)) at eval.c:2276
#161 0x0000000000643753 in Fprogn (body=XIL(0)) at eval.c:455
#162 0x000000000064b4cd in funcall_lambda (fun=XIL(0x2ee9e13), nargs=0,
arg_vector=0x0) at eval.c:3042
#163 0x000000000064ac9d in apply_lambda (fun=XIL(0x2ee9e13), args=XIL(0),
count=57) at eval.c:2903
#164 0x00000000006490b6 in eval_sub (form=XIL(0x2edf2b3)) at eval.c:2306
#165 0x0000000000643753 in Fprogn (body=XIL(0)) at eval.c:455
#166 0x0000000000648888 in eval_sub (form=XIL(0x2ee9d03)) at eval.c:2183
#167 0x00000000006434f8 in Fif (args=XIL(0x2ee9ce3)) at eval.c:410
#168 0x0000000000648888 in eval_sub (form=XIL(0x2ee9cd3)) at eval.c:2183
#169 0x0000000000643753 in Fprogn (body=XIL(0x2ee7e23)) at eval.c:455
#170 0x0000000000648888 in eval_sub (form=XIL(0x2ede8a3)) at eval.c:2183
#171 0x00000000006465a5 in internal_lisp_condition_case
(var=XIL(0x737b2a0), bodyform=XIL(0x2ede8a3), handlers=XIL(0x2edeb73)) at
eval.c:1303
#172 0x0000000000646037 in Fcondition_case (args=XIL(0x2ee7d63)) at
eval.c:1227
#173 0x0000000000648888 in eval_sub (form=XIL(0x2ee7d53)) at eval.c:2183
#174 0x0000000000643753 in Fprogn (body=XIL(0x2edeed3)) at eval.c:455
#175 0x0000000000643541 in Fif (args=XIL(0x2ee7d33)) at eval.c:411
#176 0x0000000000648888 in eval_sub (form=XIL(0x2ee7d43)) at eval.c:2183
#177 0x000000000067f903 in readevalloop_eager_expand_eval
(val=XIL(0x2eded33), macroexpand=XIL(0xbc7b0)) at lread.c:1850
#178 0x00000000006802cd in readevalloop (readcharfun=XIL(0x52b1ae5),
infile0=0x0, sourcename=XIL(0x6fb5bd4), printflag=false, unibyte=XIL(0),
readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2036
#179 0x00000000006806e9 in Feval_buffer (buffer=XIL(0x52b1ae5),
printflag=XIL(0), filename=XIL(0x6f37b34), unibyte=XIL(0),
do_allow_print=XIL(0xc270)) at lread.c:2103
#180 0x000000000064a9be in funcall_subr (subr=0xd82178 <Seval_buffer>,
numargs=5, args=0x7fffffff77d0) at eval.c:2853
#181 0x000000000064a44f in Ffuncall (nargs=6, args=0x7fffffff77c8) at
eval.c:2766
#182 0x000000000069f46b in exec_byte_code (bytestr=XIL(0xa052ec),
vector=XIL(0xa0530d), maxdepth=make_number(6), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#183 0x000000000064b56d in funcall_lambda (fun=XIL(0xa0526d), nargs=4,
arg_vector=0xa0530d <pure+179245>) at eval.c:3049
#184 0x000000000064a493 in Ffuncall (nargs=5, args=0x7fffffff7fe0) at
eval.c:2768
#185 0x0000000000649e2d in call4 (fn=XIL(0x407a40), arg1=XIL(0x6f37b34),
arg2=XIL(0x6f37b34), arg3=XIL(0xc270), arg4=XIL(0xc270)) at eval.c:2642
#186 0x000000000067e3ba in Fload (file=XIL(0x80f8294), noerror=XIL(0xc270),
nomessage=XIL(0xc270), nosuffix=XIL(0), must_suffix=XIL(0xc270)) at
lread.c:1365
#187 0x0000000000658d1c in Frequire (feature=XIL(0x73847c0),
filename=XIL(0), noerror=XIL(0xc270)) at fns.c:2807
#188 0x000000000064a945 in funcall_subr (subr=0xd81448 <Srequire>,
numargs=3, args=0x7fffffff8480) at eval.c:2846
---Type <return> to continue, or q <return> to quit---
#189 0x000000000064a44f in Ffuncall (nargs=4, args=0x7fffffff8478) at
eval.c:2766
#190 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x33487a4),
vector=XIL(0x3340d05), maxdepth=make_number(4), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#191 0x000000000064b56d in funcall_lambda (fun=XIL(0x3340d95), nargs=4,
arg_vector=0x3340d05) at eval.c:3049
#192 0x000000000064a493 in Ffuncall (nargs=5, args=0x7fffffff8ba0) at
eval.c:2768
#193 0x0000000000649685 in Fapply (nargs=3, args=0x7fffffff8dc8) at
eval.c:2386
#194 0x000000000064a806 in funcall_subr (subr=0xd80188 <Sapply>, numargs=3,
args=0x7fffffff8dc8) at eval.c:2821
#195 0x000000000064a44f in Ffuncall (nargs=4, args=0x7fffffff8dc0) at
eval.c:2766
#196 0x000000000069f46b in exec_byte_code (bytestr=XIL(0x13f1f64),
vector=XIL(0x3340aa5), maxdepth=make_number(5),
args_template=make_number(128), nargs=3, args=0x7fffffff94d8) at
bytecode.c:629
#197 0x000000000064b061 in funcall_lambda (fun=XIL(0x3340ad5), nargs=3,
arg_vector=0x7fffffff94d8) at eval.c:2967
#198 0x000000000064a493 in Ffuncall (nargs=4, args=0x7fffffff94d0) at
eval.c:2768
#199 0x0000000000649685 in Fapply (nargs=2, args=0x7fffffff96f8) at
eval.c:2386
#200 0x000000000064a806 in funcall_subr (subr=0xd80188 <Sapply>, numargs=2,
args=0x7fffffff96f8) at eval.c:2821
#201 0x000000000064a44f in Ffuncall (nargs=3, args=0x7fffffff96f0) at
eval.c:2766
#202 0x000000000069f46b in exec_byte_code (bytestr=XIL(0xb0c44c),
vector=XIL(0xb0c46d), maxdepth=make_number(10),
args_template=make_number(257), nargs=1, args=0x7fffffff9ef0) at
bytecode.c:629
#203 0x000000000064b061 in funcall_lambda (fun=XIL(0xb0c41d), nargs=1,
arg_vector=0x7fffffff9ee8) at eval.c:2967
#204 0x000000000064a493 in Ffuncall (nargs=2, args=0x7fffffff9ee0) at
eval.c:2768
#205 0x0000000000649d4c in call1 (fn=XIL(0xc600), arg1=XIL(0x80f7285)) at
eval.c:2617
#206 0x000000000059a0de in timer_check_2 (timers=XIL(0x2ed5b83),
idle_timers=XIL(0x2ed5ac3)) at keyboard.c:4462
#207 0x000000000059a209 in timer_check () at keyboard.c:4524
#208 0x00000000005978d4 in readable_events (flags=1) at keyboard.c:3340
#209 0x000000000059f029 in get_input_pending (flags=1) at keyboard.c:6824
#210 0x00000000005a6a40 in detect_input_pending_run_timers
(do_display=true) at keyboard.c:9951
#211 0x00000000006af738 in wait_reading_process_output (time_limit=0,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0,
just_wait_proc=0) at process.c:5508
#212 0x00000000005988bc in kbd_buffer_get_event (kbp=0x7fffffffa738,
used_mouse_menu=0x7fffffffaeaf, end_time=0x0) at keyboard.c:3831
#213 0x0000000000593bea in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffffabe0, used_mouse_menu=0x7fffffffaeaf) at
keyboard.c:2151
#214 0x0000000000593ee2 in read_decoded_event_from_main_queue
(end_time=0x0, local_getcjmp=0x7fffffffabe0, prev_event=XIL(0),
used_mouse_menu=0x7fffffffaeaf) at keyboard.c:2214
#215 0x0000000000595bc2 in read_char (commandflag=1, map=XIL(0x2d4fb23),
prev_event=XIL(0), used_mouse_menu=0x7fffffffaeaf, end_time=0x0) at
keyboard.c:2802
#216 0x00000000005a4d85 in read_key_sequence (keybuf=0x7fffffffb040,
bufsize=30, prompt=XIL(0), dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9147
#217 0x0000000000591833 in command_loop_1 () at keyboard.c:1368
#218 0x0000000000646641 in internal_condition_case (bfun=0x591400
<command_loop_1>, handlers=XIL(0x5250), hfun=0x590a56 <cmd_error>) at
eval.c:1332
#219 0x0000000000591005 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#220 0x0000000000645b75 in internal_catch (tag=XIL(0xc8d0), func=0x590fdc
<command_loop_2>, arg=XIL(0)) at eval.c:1097
#221 0x0000000000590fa7 in command_loop () at keyboard.c:1089
#222 0x000000000059056b in recursive_edit_1 () at keyboard.c:695
#223 0x000000000059074a in Frecursive_edit () at keyboard.c:766
#224 0x000000000058e447 in main (argc=1, argv=0x7fffffffb528) at
emacs.c:1713

Lisp Backtrace:
"read" (0xfffe91c0)
"projectile-unserialize" (0xfffe9920)
"projectile-global-mode" (0xfffea040)
"progn" (0xfffea340)
"condition-case" (0xfffea630)
"progn" (0xfffea7d0)
0x71bc820 Lisp type 3
"eval-after-load-helper" (0xfffeb330)
"run-hook-with-args" (0xfffeb328)
"do-after-load-evaluation" (0xfffebb08)
0xd81448 PVEC_SUBR
"ad-Advice-require" (0xfffec890)
"apply" (0xfffec888)
"require" (0xfffecfa0)
"byte-code" (0xfffed640)
0xd81448 PVEC_SUBR
"ad-Advice-require" (0xfffee398)
"apply" (0xfffee5b8)
"require" (0xfffeec40)
"not" (0xfffeef20)
"if" (0xfffef0c0)
"progn" (0xfffef260)
"condition-case" (0xfffef550)
"progn" (0xfffef6f0)
0x561fd80 Lisp type 3
---Type <return> to continue, or q <return> to quit---
"eval-after-load-helper" (0xffff0250)
"run-hook-with-args" (0xffff0248)
"do-after-load-evaluation" (0xffff0a28)
0xd81448 PVEC_SUBR
"ad-Advice-require" (0xffff17b0)
"apply" (0xffff17a8)
"require" (0xffff1ec0)
"byte-code" (0xffff2550)
"autoload-do-load" (0xffff2b88)
"desktop-load-file" (0xffff3398)
"desktop-create-buffer" (0xffff3bc0)
"eval-buffer" (0xffff4120)
"load-with-code-conversion" (0xffff4938)
0xd82118 PVEC_SUBR
"ad-Advice-load" (0xffff5478)
"apply" (0xffff5698)
"load" (0xffff5de8)
"desktop-read" (0xffff6600)
"modi/restore-last-saved-desktop" (0xffff6920)
"progn" (0xffff6c20)
"if" (0xffff6dc0)
"progn" (0xffff6f60)
"condition-case" (0xffff7250)
"if" (0xffff7430)
"eval-buffer" (0xffff77d0)
"load-with-code-conversion" (0xffff7fe8)
0xd81448 PVEC_SUBR
"ad-Advice-require" (0xffff8ba8)
"apply" (0xffff8dc8)
"require" (0xffff94d8)
"apply" (0xffff96f8)
"timer-event-handler" (0xffff9ee8)
(gdb)


-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #53 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: 25.3; Segmentation fault when starting emacs with my config
Date: Tue, 31 Oct 2017 22:56:08 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Tue, 31 Oct 2017 20:52:23 +0000
> Cc: 29031 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
>  Can you try the latest emacs-26 branch, and see if the problem still
>  persists?
> 
> This time, I got SIGABRT again.

Oh well, it was a long shot anyway.

Thanks.

Message #56 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29031 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Tue, 07 Nov 2017 08:27:27 -0500

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

> On Tue, Oct 31, 2017 at 4:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> This time, I got SIGABRT again.
>
> PS: While I have the gdb emacs in a limbo state after the below SIGABRT,
> "emacsclient -a '' -c" stays stuck at "Waiting for Emacs...". I can start
> emacsclient as usual only after I kill the gdb session. Is there a way to
> keep the gdb session on emacs binary separate from my emacsclient launching?

You can give different server names, not sure what you're asking
exactly.

Can you try running under valgrind?

Message #59 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29031 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Tue, 07 Nov 2017 13:30:35 +0000

[Message part 1 (text/plain, inline)]

On Tue, Nov 7, 2017, 8:27 AM Noam Postavsky <npostavs <at> users.sourceforge.net>
wrote:

>
> You can give different server names, not sure what you're asking
> exactly.
>

Thanks, that didn't occur to me.

Can you try running under valgrind?
>

I have no idea what that is. I am not a C developer. So I haven't yet found
time to learn valgrind. I read the referenced DEBUG file, but it made no
sense. I believe it's a steep learning curve for someone who doesn't know
what valgrind is.

> --

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #62 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Tue, 07 Nov 2017 08:55:37 -0500

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

> I have no idea what that is. I am not a C developer. So I haven't yet
> found time to learn valgrind. I read the referenced DEBUG file, but
> it made no sense. I believe it's a steep learning curve for someone
> who doesn't know what valgrind is. 

Could you try just installing valgrind, reconfiguring and recompile
emacs with --enable-checking (reconfigure after installing valgrind, as
configure checks for its header file) and then running 'valgrind emacs'
and posting the result.  I tried this now without making any more
complex changes suggested in DEBUG and emacs did manage to run.  There
were a couple of warnings about pselect and writev, but otherwise it
seemed to work okay.

It's possible something useful will come out.  If not, we can consider
whether it's worth trying the more complex stuff.

Message #65 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29031 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Kaushal Modi <kaushal.modi <at> gmail.com>
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Sun, 29 Sep 2019 02:44:57 +0200

tags 29031 + moreinfo
quit

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

> Kaushal Modi <kaushal.modi <at> gmail.com> writes:
>
>> I have no idea what that is. I am not a C developer. So I haven't yet
>> found time to learn valgrind. I read the referenced DEBUG file, but
>> it made no sense. I believe it's a steep learning curve for someone
>> who doesn't know what valgrind is.
>
> Could you try just installing valgrind, reconfiguring and recompile
> emacs with --enable-checking (reconfigure after installing valgrind, as
> configure checks for its header file) and then running 'valgrind emacs'
> and posting the result.  I tried this now without making any more
> complex changes suggested in DEBUG and emacs did manage to run.  There
> were a couple of warnings about pselect and writev, but otherwise it
> seemed to work okay.
>
> It's possible something useful will come out.  If not, we can consider
> whether it's worth trying the more complex stuff.

Are you still seeing this?  If the answer is yes, it seems like more
information is needed here to progress.  Could you please try the
procedure suggested above by Noam Postavsky on Emacs 26.3?

Best regards,
Stefan Kangas

Message #70 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 29031 <at> debbugs.gnu.org, Kaushal Modi <kaushal.modi <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Sat, 28 Sep 2019 20:58:33 -0400

Stefan Kangas <stefan <at> marxist.se> writes:
>
>> Kaushal Modi <kaushal.modi <at> gmail.com> writes:
>>
>>> I have no idea what that is. I am not a C developer. So I haven't yet
>>> found time to learn valgrind. I read the referenced DEBUG file, but
>>> it made no sense. I believe it's a steep learning curve for someone
>>> who doesn't know what valgrind is.
>>
>> Could you try just installing valgrind, reconfiguring and recompile
>> emacs with --enable-checking (reconfigure after installing valgrind, as
>> configure checks for its header file) and then running 'valgrind emacs'
>> and posting the result.  I tried this now without making any more
>> complex changes suggested in DEBUG and emacs did manage to run.  There
>> were a couple of warnings about pselect and writev, but otherwise it
>> seemed to work okay.
>>
>> It's possible something useful will come out.  If not, we can consider
>> whether it's worth trying the more complex stuff.
>
> Are you still seeing this?  If the answer is yes, it seems like more
> information is needed here to progress.  Could you please try the
> procedure suggested above by Noam Postavsky on Emacs 26.3?

It would likely be more productive to do this on a version from master,
since I believe the switch to pdumper solves some potential problems
when using valgrind.

Message #73 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca,
 kaushal.modi <at> gmail.com
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Sun, 29 Sep 2019 10:26:39 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 29031 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,  Stefan Monnier <monnier <at> iro.umontreal.ca>,  Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Sat, 28 Sep 2019 20:58:33 -0400
> 
> It would likely be more productive to do this on a version from master,
> since I believe the switch to pdumper solves some potential problems
> when using valgrind.

I agree.  I expect this problem not to happen at all in Emacs 27.

Message #76 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29031 <at> debbugs.gnu.org, Kaushal Modi <kaushal.modi <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Wed, 30 Oct 2019 21:17:37 +0100

tags 29031 + unreproducible
close 29031
quit

Stefan Kangas <stefan <at> marxist.se> writes:

> Are you still seeing this?  If the answer is yes, it seems like more
> information is needed here to progress.  Could you please try the
> procedure suggested above by Noam Postavsky on Emacs 26.3?

More information was requested, but none was given within 4 weeks, so
I'm closing this bug.  If this is still an issue, please reopen the bug
report.

Best regards,
Stefan Kangas

Message #83 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: 29031 <at> debbugs.gnu.org
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Wed, 30 Oct 2019 16:47:19 -0400

[Message part 1 (text/plain, inline)]

On Wed, Oct 30, 2019 at 4:18 PM Stefan Kangas <stefan <at> marxist.se> wrote:

>
> More information was requested, but none was given within 4 weeks, so
> I'm closing this bug.  If this is still an issue, please reopen the bug
> report.
>

Sorry. I haven't got a chance to reproduce the issue. I will open a new bug
report when I see any crash.

[Message part 2 (text/html, inline)]

Message #86 received at 29031 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29031 <at> debbugs.gnu.org
Subject: Re: bug#29031: 25.3;
 Segmentation fault when starting emacs with my config
Date: Wed, 30 Oct 2019 22:16:20 +0100

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

> On Wed, Oct 30, 2019 at 4:18 PM Stefan Kangas <stefan <at> marxist.se> wrote:
>
>  More information was requested, but none was given within 4 weeks, so
>  I'm closing this bug.  If this is still an issue, please reopen the bug
>  report.
>
> Sorry. I haven't got a chance to reproduce the issue. I will open a new bug report when I see any crash. 

Thanks.  Note what Eli said though -- this will most likely have been
fixed in the upcoming Emacs 27.1 release (which will hopefully see a
pre-test within a couple of weeks).

Best regards,
Stefan Kangas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.