all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Kaushal Modi <kaushal.modi@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 29031@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#29031: 25.3; Segmentation fault when starting emacs with my config
Date: Mon, 30 Oct 2017 19:24:19 +0000	[thread overview]
Message-ID: <CAFyQvY15BoTdEgDFQvgj9utepaWvQJOYAVb=eMnv_DjY_029xA@mail.gmail.com> (raw)
In-Reply-To: <83mv48trbs.fsf@gnu.org>

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

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

> > From: Kaushal Modi <kaushal.modi@gmail.com>
> > Date: Mon, 30 Oct 2017 16:03:43 +0000
> > Cc: Eli Zaretskii <eliz@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

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

  reply	other threads:[~2017-10-30 19:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27 21:24 bug#29031: 25.3; Segmentation fault when starting emacs with my config Kaushal Modi
2017-10-30 14:17 ` Kaushal Modi
2017-10-30 16:03   ` Kaushal Modi
2017-10-30 18:37     ` Eli Zaretskii
2017-10-30 19:24       ` Kaushal Modi [this message]
2017-10-30 19:34         ` Eli Zaretskii
2017-10-30 19:51         ` Eli Zaretskii
2017-10-30 21:36           ` Kaushal Modi
2017-10-31 20:26             ` Eli Zaretskii
2017-10-31 20:52               ` Kaushal Modi
2017-10-31 20:56                 ` Eli Zaretskii
2017-11-07 13:27                 ` Noam Postavsky
2017-11-07 13:30                   ` Kaushal Modi
2017-11-07 13:55                     ` Noam Postavsky
2017-10-30 18:22   ` Eli Zaretskii
2017-10-30 18:34     ` Kaushal Modi
2017-10-30 18:52       ` Eli Zaretskii
2017-10-30 18:57         ` Kaushal Modi
2017-10-30 19:18           ` Kaushal Modi
2017-10-30 19:28             ` Eli Zaretskii
2019-09-29  0:44 ` Stefan Kangas
2019-09-29  0:58   ` Noam Postavsky
2019-09-29  7:26     ` Eli Zaretskii
2019-10-30 20:17   ` Stefan Kangas
2019-10-30 20:47     ` Kaushal Modi
2019-10-30 21:16       ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFyQvY15BoTdEgDFQvgj9utepaWvQJOYAVb=eMnv_DjY_029xA@mail.gmail.com' \
    --to=kaushal.modi@gmail.com \
    --cc=29031@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.