Emacs: Segfault

Emacs: Segfault

[T.V Raman]

This started happening yesterday on a build of emacs that has been
running happily on what is a new laptop --- build from May 30.

I updated from HEAD and rebuilt emacs; but still get the segfault.

here is what GDB shows:

run
Starting program: /usr/local/bin/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1769640 (LWP 107662)]
[New Thread 0x7ffff0cbb640 (LWP 107663)]
[New Thread 0x7fffebfff640 (LWP 107664)]
[New Thread 0x7fffeb2a3640 (LWP 107665)]
[Detaching after vfork from child process 107668]
[Detaching after vfork from child process 107669]
[Detaching after vfork from child process 107670]
[Detaching after vfork from child process 107681]
[Detaching after vfork from child process 107682]
[New Thread 0x7fffea511640 (LWP 107683)]
[Thread 0x7fffea511640 (LWP 107683) exited]

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x000055555577b798 in getc_unlocked (__fp=0x7ffff1ec670d) at /usr/include/x86_64-linux-gnu/bits/stdio.h:68
68	  return __getc_unlocked_body (__fp);
(gdb) where 
#0  0x000055555577b798 in getc_unlocked (__fp=0x7ffff1ec670d) at /usr/include/x86_64-linux-gnu/bits/stdio.h:68
#1  readbyte_from_stdio () at lread.c:498
#2  0x000055555577d490 in readchar (readcharfun=0x7f20, multibyte=0x7fffffffb6c7) at lread.c:353
#3  0x000055555578121d in read0 (readcharfun=<optimized out>, locate_syms=<optimized out>) at lread.c:3683
#4  0x00005555557834f0 in read_internal_start (stream=0x7f20, start=0x0, end=0x0, locate_syms=<optimized out>) at lread.c:2569
#5  0x00005555557501c3 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffbc60) at eval.c:2943
#6  0x0000555555783e87 in call1 (arg1=0x7f20, fn=<optimized out>) at /home/raman/sourceforge/emacs/src/lisp.h:3225
#7  readevalloop
    (readcharfun=0x7f20, infile0=0x7fffffffbd00, sourcename=0x55555b93dab4, printflag=false, unibyte=<optimized out>, readfun=0x0, start=0x0, end=0x0) at lread.c:2318
#8  0x000055555578498e in Fload (file=0x7ffff1f9f604, noerror=0x0, nomessage=0x0, nosuffix=<optimized out>, must_suffix=<optimized out>)
    at lread.c:1592
#9  0x0000555555797127 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:809
#10 0x00005555557501c3 in Ffuncall (nargs=289, args=0x7fffffffbf20) at eval.c:2943
#11 0x0000555555751958 in Fapply (nargs=3, args=0x7ffff1795140) at eval.c:2614
#12 0x0000555555797127 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:809
#13 0x0000555555755287 in apply_lambda (fun=0x7ffff1f49ed5, args=<optimized out>, count=...) at eval.c:3052
#14 0x0000555555753c9d in eval_sub (form=<optimized out>) at eval.c:2536
#15 0x0000555555783ceb in readevalloop
    (readcharfun=0x7f20, infile0=0x7fffffffd420, sourcename=0x55555b22c1f4, printflag=false, unibyte=<optimized out>, readfun=0x0, start=0x0, end=0x0) at lread.c:2338
#16 0x000055555578498e in Fload (file=0x55555b0ec5a4, noerror=0x0, nomessage=0x0, nosuffix=<optimized out>, must_suffix=<optimized out>)
    at lread.c:1592
#17 0x0000555555753e65 in eval_sub (form=<optimized out>) at eval.c:2460
#18 0x00005555557542ad in Fprogn (body=0x0) at eval.c:451
#19 0x0000555555753daa in eval_sub (form=<optimized out>) at eval.c:2399
#20 0x0000555555753daa in eval_sub (form=<optimized out>) at eval.c:2399
#21 0x0000555555755805 in Fprogn (body=0x555556e62ec3) at eval.c:451
#22 Flet (args=0x555556eb4c93) at eval.c:1037
#23 0x0000555555753daa in eval_sub (form=<optimized out>) at eval.c:2399
#24 0x0000555555754e65 in Fprogn (body=0x0) at eval.c:451
#25 funcall_lambda (fun=0x555556eb4d63, nargs=0, arg_vector=0x7fffffffd990) at eval.c:3182
#26 0x0000555555755287 in apply_lambda (fun=0x555556eb4d73, args=<optimized out>, count=...) at eval.c:3052
#27 0x0000555555753c9d in eval_sub (form=<optimized out>) at eval.c:2536
#28 0x0000555555754e65 in Fprogn (body=0x555556eb4663) at eval.c:451
#29 funcall_lambda (fun=0x555556eb4043, nargs=0, arg_vector=0x7fffffffdbd0) at eval.c:3182
#30 0x00005555557501c3 in Ffuncall (nargs=1, args=0x7fffffffdbc8) at eval.c:2943
#31 0x0000555555750289 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2625
#32 0x000055555574f16c in run_hook_with_args (nargs=1, args=0x7fffffffdbc8, funcall=0x555555750280 <funcall_nil>) at eval.c:2802
#33 0x000055555574f3c5 in Frun_hook_with_args (args=0x7fffffffdbc8, nargs=1) at eval.c:2667
#34 run_hook (hook=<optimized out>) at eval.c:2815
#35 Frun_hooks (nargs=2, args=0x7ffff17950b8) at eval.c:2649
#36 0x0000555555797127 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:809
#37 0x0000555555755287 in apply_lambda (fun=0x7ffff20be1e5, args=<optimized out>, count=...) at eval.c:3052
#38 0x0000555555753c9d in eval_sub (form=<optimized out>) at eval.c:2536
#39 0x00005555557562b7 in Feval (form=0x7ffff25f709b, lexical=<optimized out>) at eval.c:2304
#40 0x000055555574ea57 in internal_condition_case
    (bfun=bfun@entry=0x5555556c4240 <top_level_2>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x5555556cb510 <cmd_error>) at eval.c:1478
#41 0x00005555556c4bc6 in top_level_1 (ignore=ignore@entry=0x0) at keyboard.c:1157
#42 0x000055555574e9b1 in internal_catch (tag=tag@entry=0xf5d0, func=func@entry=0x5555556c4ba0 <top_level_1>, arg=arg@entry=0x0) at eval.c:1208
#43 0x00005555556c41bf in command_loop () at keyboard.c:1117
#44 0x00005555556cb0c3 in recursive_edit_1 () at keyboard.c:727
#45 0x00005555556cb43c in Frecursive_edit () at keyboard.c:810
#46 0x00005555555a682a in main (argc=1, argv=<optimized out>) at emacs.c:2493
(gdb) 

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Emacs: Segfault

[Lars Ingebrigtsen]

"T.V Raman" <raman@google.com> writes:

> This started happening yesterday on a build of emacs that has been
> running happily on what is a new laptop --- build from May 30.
>
> I updated from HEAD and rebuilt emacs; but still get the segfault.

[...]

> #3 0x000055555578121d in read0 (readcharfun=<optimized out>,
> locate_syms=<optimized out>) at lread.c:3683

Is this with the current HEAD now?  There were some reader-related
things that were fixed some hours ago.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs: Segfault

[T.V Raman]

head as of last night.

Will try building again later.

Incidentally with the same crashing build:

I have been using make-thread in my emacs and emacspeak startup to
speed up emacs start time; taking those out avoids the crash.

It makes emacs startup slightly slower to do that -- though not
significantly so 0.34s vs 0.65s -- but if it helps catch errors ...
Lars Ingebrigtsen writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > This started happening yesterday on a build of emacs that has been
 > > running happily on what is a new laptop --- build from May 30.
 > >
 > > I updated from HEAD and rebuilt emacs; but still get the segfault.
 > 
 > [...]
 > 
 > > #3 0x000055555578121d in read0 (readcharfun=<optimized out>,
 > > locate_syms=<optimized out>) at lread.c:3683
 > 
 > Is this with the current HEAD now?  There were some reader-related
 > things that were fixed some hours ago.
 > 
 > -- 
 > (domestic pets only, the antidote for overdose, milk.)
 >    bloggy blog: http://lars.ingebrigtsen.no

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Emacs: Segfault

[Lars Ingebrigtsen]

"T.V Raman" <raman@google.com> writes:

> specific example for you Lars to try since it is "close to home"
> (make-thread #'(lambda () (load-library "eww"))

This doesn't crash for me on the current trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs: Segfault

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 391 bytes --]

Rebuilt from head, restored make-thread calls in my startup -- and it
still segfaults.

Can send a gdb trace sometime later in the day if that will help 
but both the earlier build which is installed, and the latest git update
build crash reliably if my startup uses make-thread 

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Emacs: Segfault

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2199 bytes --]

here is a gdb stack trace 

gdb ./emacs
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs...
warning: File "/home/raman/sourceforge/emacs/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /home/raman/sourceforge/emacs/src/.gdbinit
line to your configuration file "/home/raman/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/raman/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) run
Starting program: /home/raman/sourceforge/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1769640 (LWP 131159)]
[New Thread 0x7ffff0cbb640 (LWP 131160)]
[New Thread 0x7fffebfff640 (LWP 131161)]
Font ¡®-adobe-helvetica-medium-r-normal--25-*-*-*-p-130-iso10646-1¡¯ is not defined
[Thread 0x7ffff0cbb640 (LWP 131160) exited]
[Thread 0x7ffff1769640 (LWP 131159) exited]
[Thread 0x7ffff29b7040 (LWP 131153) exited]
[Inferior 1 (process 131153) exited with code 0377]
(gdb) where 
No stack.
(gdb) 
-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Emacs: Segfault

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Jun 2022 09:16:49 -0700
> 
> here is a gdb stack trace 

There's no backtrace here, just an abnormal exit.

Please type "break exit" at GDB prompt, before you type "run", and
show the backtrace from the breakpoint in 'exit'.

Re: Emacs: Segfault

[T.V Raman]

This last crash I sent is spurious -- only look at the earlier gdb run
which is related to make-thread in the startup sequence.

Not an excuse, but I'm dealing with a new laptop and a 4K display
(that does me no good) but makes the on screen fonts in emacs so tiny
that it would be impossible for me to collaborate with someone who can
see.

I was fiddling with .Xresources and inadvertantly created a situation
where emacs couldn't find any fonts :-(

restored sanity by resetting via gsettings.

Eli Zaretskii writes:
 > > From: "T.V Raman" <raman@google.com>
 > > Cc: emacs-devel@gnu.org
 > > Date: Thu, 02 Jun 2022 09:16:49 -0700
 > > 
 > > here is a gdb stack trace 
 > 
 > There's no backtrace here, just an abnormal exit.
 > 
 > Please type "break exit" at GDB prompt, before you type "run", and
 > show the backtrace from the breakpoint in 'exit'.

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Emacs: Segfault

[Mattias Engdegård]

2 juni 2022 kl. 16.01 skrev T.V Raman <raman@google.com>:

> This started happening yesterday on a build of emacs that has been
> running happily on what is a new laptop --- build from May 30.

I just fixed a mistake of mine (4bacd2a6457). Did that help?

Re: Emacs: Segfault

[T.V Raman]

Haven't tested yes, but see Lars' message -- a reliable way of
tickling it seems to be to use make-thread to load heavier libs during
startup


-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Emacs: Segfault

[Eli Zaretskii]

> Date: Thu, 02 Jun 2022 07:01:21 -0700
> From: "T.V Raman" <raman@google.com>
> 
> This started happening yesterday on a build of emacs that has been
> running happily on what is a new laptop --- build from May 30.

It segfaults inside a library function.  Any chance your system was
updated yesterday-ish?

Re: Emacs: Segfault

[T.V Raman]

possible since updates happen behind the scene

Eli Zaretskii writes:
 > > Date: Thu, 02 Jun 2022 07:01:21 -0700
 > > From: "T.V Raman" <raman@google.com>
 > > 
 > > This started happening yesterday on a build of emacs that has been
 > > running happily on what is a new laptop --- build from May 30.
 > 
 > It segfaults inside a library function.  Any chance your system was
 > updated yesterday-ish?

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Emacs: Segfault

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Date: Thu, 2 Jun 2022 09:32:42 -0700
> Cc: raman@google.com,
>     emacs-devel@gnu.org
> 
> possible since updates happen behind the scene

Is there some kind of update log where you could check if an update
really happened?  Or maybe look at the time stamp of libc.so (and if
it's a symlink, of the symlink's target)?