bug#36155: 26.2.50; crash on printing thread with print-circle = t

bug#36155: 26.2.50; crash on printing thread with print-circle = t

[Juanma Barranquero]

Calling prin1 with a thread argument crashes if either print-circle or
print-gensym are set to t.

emacs -Q --eval "(setq print-circle t)" --eval "(prin1 (current-thread))"

GNU gdb (GDB) 8.3
[...]
Breakpoint 1 at 0x4000ed1a0: file emacs.c, line 368.
Temporary breakpoint 2 at 0x4001103ae: file sysdep.c, line 1071.
(gdb) run -Q --eval "(setq print-circle t)" --eval "(prin1 (current-thread))"
Starting program: D:\Devel\emacs\repo\emacs-26\src\emacs.exe -Q --eval
"(setq print-circle t)" --eval "(prin1 (current-thread))"
[New Thread 5796.0x5884]
[New Thread 5796.0x65d8]
[New Thread 5796.0x5aa8]
[New Thread 5796.0x2d2c]
[New Thread 5796.0x657c]

Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22,
    backtrace_limit=2147483647) at emacs.c:368
368     {
(gdb) bt
#0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
    at emacs.c:368
#1  0x0000000400162a44 in die (
    msg=0x40066d4f4 <chartab_size+10084> "0 <= size",
    file=0x40066cf01 <chartab_size+8561> "lisp.h", line=1438) at alloc.c:7379
#2  0x00000004000e746e in ASIZE (array=...) at lisp.h:1438
#3  0x00000004001ad039 in VECTORP (x=...) at lisp.h:2800
#4  print_preprocess (obj=obj@entry=XIL(0x4007394c5)) at print.c:1179
#5  0x00000004001afad2 in print (obj=XIL(0x4007394c5),
    obj@entry=XIL(0x40095dd10), printcharfun=...,
    printcharfun@entry=XIL(0xca50), escapeflag=escapeflag@entry=true)
    at print.c:1115
#6  0x00000004001b00cf in Fprin1 (object=XIL(0x40095dd10),
    printcharfun=XIL(0xca50)) at print.c:629
#7  0x000000040018c2a4 in eval_sub (form=..., form@entry=XIL(0x4008e8fc3))
    at eval.c:2244
#8  0x000000040018ebce in Feval (form=XIL(0x4008e8fc3), lexical=...)
    at eval.c:2061
#9  0x000000040018aa6a in funcall_subr (subr=0x400657420 <Seval>,
    numargs=numargs@entry=1, args=args@entry=0xbfe068) at eval.c:2853
#10 0x0000000400189656 in Ffuncall (nargs=2, args=args@entry=0xbfe060)
    at eval.c:2776
#11 0x00000004001d14a0 in exec_byte_code (bytestr=..., vector=...,
    vector@entry=XIL(0x4003a66bd), maxdepth=...,
    maxdepth@entry=make_number(23), args_template=...,
    args_template@entry=make_number(257), nargs=nargs@entry=1,
    args=<optimized out>, args@entry=0xbfe760) at bytecode.c:630
#12 0x000000040018ca49 in funcall_lambda (fun=fun@entry=XIL(0x4003a666d),
    nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfe760) at lisp.h:1614
#13 0x00000004001897a3 in Ffuncall (nargs=2, args=args@entry=0xbfe758)
    at eval.c:2778
#14 0x00000004001d14a0 in exec_byte_code (bytestr=..., vector=...,
    vector@entry=XIL(0x4003a0ed5), maxdepth=...,
    maxdepth@entry=make_number(21), args_template=...,
    args_template@entry=make_number(0), nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0xbff128) at bytecode.c:630
#15 0x000000040018ca49 in funcall_lambda (fun=fun@entry=XIL(0x4003a0e85),
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbff128) at lisp.h:1614
#16 0x00000004001897a3 in Ffuncall (nargs=1, args=args@entry=0xbff120)
    at eval.c:2778
#17 0x00000004001d14a0 in exec_byte_code (bytestr=..., vector=...,
    vector@entry=XIL(0x4003a0165), maxdepth=...,
    maxdepth@entry=make_number(12), args_template=...,
    args_template@entry=make_number(0), nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0xbff500) at bytecode.c:630
#18 0x000000040018ca49 in funcall_lambda (fun=XIL(0x4003a0115),
    fun@entry=XIL(0xbff5e0), nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0xbff500) at lisp.h:1614
#19 0x000000040018ced7 in apply_lambda (fun=XIL(0xbff5e0),
    fun@entry=XIL(0x4003a0115), args=..., count=count@entry=4) at eval.c:2913
#20 0x000000040018c3f4 in eval_sub (form=..., form@entry=XIL(0x4008e4703))
    at eval.c:2286
#21 0x000000040018ebce in Feval (form=XIL(0x4008e4703), lexical=...,
    lexical@entry=XIL(0)) at eval.c:2061
#22 0x00000004000f1ddf in top_level_2 () at lisp.h:849
#23 0x00000004001885d7 in internal_condition_case (
    bfun=bfun@entry=0x4000f1db7 <top_level_2>, handlers=...,
    handlers@entry=XIL(0x4e90), hfun=hfun@entry=0x4000f6e0a <cmd_error>)
    at eval.c:1336
#24 0x00000004000f5f16 in top_level_1 (ignore=...) at lisp.h:849
#25 0x000000040018850f in internal_catch (tag=...,
    func=func@entry=0x4000f5eca <top_level_1>, arg=arg@entry=XIL(0))
    at eval.c:1101
#26 0x00000004000eea50 in command_loop () at lisp.h:855
#27 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Lisp Backtrace:
"prin1" (0xbfddc0)
"eval" (0xbfe068)
"command-line-1" (0xbfe760)
"command-line" (0xbff128)
"normal-top-level" (0xbff500)
(gdb)




In GNU Emacs 26.2.50 (build 1, x86_64-w64-mingw32)
 of 2019-06-09 built on ODIEFAST
Repository revision: 4904fb352c14539e1c6927e8c893abb037bca8a0
Windowing system distributor 'Microsoft Corp.', version 10.0.18362
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/d/Devel/emacs/repo/emacs-26 --with-modules
 --enable-checking=yes
 --enable-locallisppath=%emacs_dir%/../site-lisp:%emacs_dir%/share/emacs/@VER@/site-lisp:%emacs_dir%/share/emacs/site-lisp
 'CFLAGS=-Og -ggdb3' CPPFLAGS=-DGC_MCHECK=1'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES THREADS LCMS2

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils elec-pair pcase subr-x cl-loaddefs cl-lib
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 99748 13041)
 (symbols 48 20311 1)
 (miscs 40 78 118)
 (strings 32 30100 1148)
 (string-bytes 1 771917)
 (vectors 16 14924)
 (vector-slots 8 504919 8770)
 (floats 8 51 221)
 (intervals 56 290 22)
 (buffers 992 12))

bug#36155: 26.2.50; crash on printing thread with print-circle = t

[Paul Eggert]

I can't reproduce this bug on Fedora 30 x86-64 (emacs-26 commit 
4904fb352c14539e1c6927e8c893abb037bca8a0), so I guess the bug is 
specific to MS-Windows.

bug#36155: 26.2.50; crash on printing thread with print-circle = t

[Juanma Barranquero]

> I can't reproduce this bug on Fedora 30 x86-64 (emacs-26 commit
> 4904fb352c14539e1c6927e8c893abb037bca8a0), so I guess the bug is
> specific to MS-Windows.

That's weird, as it doesn't seem like it should depend on anything
windowsy... (but who knows).

I'm configuring with --enable-checking=yes and -DGC_MCHECK=1 btw.

I don't get the crash in the current trunk, only the current release branch.

bug#36155: 26.2.50; crash on printing thread with print-circle = t

[Paul Eggert]

On 6/9/19 5:02 PM, Juanma Barranquero wrote:
> That's weird, as it doesn't seem like it should depend on anything
> windowsy... (but who knows).
>
> I'm configuring with --enable-checking=yes and -DGC_MCHECK=1 btw.
>
> I don't get the crash in the current trunk, only the current release branch.

Yes, I was using the emacs-26 branch too. However, I'm not using 
-DGC_MCHECK as it does not work at all on Fedora; I don't know why and I 
have no plans to look into it as GC_MCHECK is an obsolete hack (people 
should be using gcc -fsanitize=address in the master branch). So, I 
suggest that you stop using -DGC_MCHECK on MS-Windows and see whether 
that fixes your problem.

bug#36155: 26.2.50; crash on printing thread with print-circle = t

[Juanma Barranquero]

On Mon, Jun 10, 2019 at 2:45 AM Paul Eggert <eggert@cs.ucla.edu> wrote:

> Yes, I was using the emacs-26 branch too. However, I'm not using
> -DGC_MCHECK as it does not work at all on Fedora; I don't know why and I
> have no plans to look into it as GC_MCHECK is an obsolete hack

I have removed that -D from my setup, though I haven't been able to
find anything stating that GC_MCHECK is obsolete.

> (people should be using gcc -fsanitize=address in the master branch).

Address Sanitizer is not supported on Mingw64, AFAICS.

> So, Isuggest that you stop using -DGC_MCHECK on MS-Windows and see
> whether that fixes your problem.

No, it doesn't. Even without -DGC_MCHECK=1, the above recipe still
crashes Emacs.

bug#36155: 26.2.50; crash on printing thread with print-circle = t

[Paul Eggert]

Juanma Barranquero wrote:
> No, it doesn't. Even without -DGC_MCHECK=1, the above recipe still
> crashes Emacs.

Fedora 30 x86-64 works fine with that recipe (without GC_MCHECK=1).

bug#36155: 26.2.50; crash on printing thread with print-circle = t

[Andreas Schwab]

On Jun 10 2019, Juanma Barranquero <lekktu@gmail.com> wrote:

> I'm configuring with --enable-checking=yes and -DGC_MCHECK=1 btw.

Should be fixed now.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."