GNU bug report logs - #48711
Crashes in lisp_string_width

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 48711 in the body.
You can then email your comments to 48711 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: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Crashes in lisp_string_width
Date: Fri, 28 May 2021 09:37:49 +0300

Yesterday's changes in lisp_string_width cause crashes:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
composition_gstring_width (gstring=<optimized out>, from=1, from <at> entry=0, to=12, metrics=metrics <at> entry=0x0) at composite.c:777
777	      if (NILP (LGLYPH_ADJUSTMENT (*glyph)))
(gdb) bt
#0  composition_gstring_width (gstring=<optimized out>, from=1, from <at> entry=0, to=12, metrics=metrics <at> entry=0x0) at composite.c:777
#1  0x0000555555642ff7 in lisp_string_width (string=string <at> entry=XIL(0x555557825e54), from=from <at> entry=0, to=to <at> entry=1, precision=precision <at> entry=-1, nchars=nchars <at> entry=0x7fffffff4850, nbytes=nbytes <at> entry=0x7fffffff4858) at lisp.h:1644
#2  0x000055555570c46e in styled_format (nargs=<optimized out>, args=<optimized out>, message=<optimized out>) at editfns.c:3392
#3  0x0000555555716690 in Ffuncall (nargs=4, args=args <at> entry=0x7fffffffa060) at lisp.h:2093
#4  0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#5  0x0000555555716527 in Ffuncall (nargs=3, args=0x7fffffffa3b0) at eval.c:3055
#6  0x00005555557167d3 in call2 (fn=fn <at> entry=XIL(0x55555e57e475), arg1=arg1 <at> entry=XIL(0x555557fe4f13), arg2=<optimized out>) at eval.c:2906
#7  0x0000555555646be8 in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57e475), table=table <at> entry=XIL(0x55555d6d3a75), arg=arg <at> entry=XIL(0x5555589bce05), val=<optimized out>, range=range <at> entry=XIL(0x555557fe4f13), top=XIL(0x5555589bce05)) at chartab.c:837
#8  0x00005555556469b7 in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57e475), table=table <at> entry=XIL(0x555556f32b1d), arg=arg <at> entry=XIL(0x5555589bce05), val=<optimized out>, range=range <at> entry=XIL(0x555557fe4f13), top=XIL(0x5555589bce05)) at chartab.c:784
#9  0x00005555556469b7 in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57e475), table=table <at> entry=XIL(0x555559509bbd), arg=arg <at> entry=XIL(0x5555589bce05), val=<optimized out>, range=range <at> entry=XIL(0x555557fe4f13), top=XIL(0x5555589bce05)) at chartab.c:784
#10 0x00005555556469b7 in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57e475), table=table <at> entry=XIL(0x5555589bce05), arg=arg <at> entry=XIL(0x5555589bce05), val=<optimized out>, range=range <at> entry=XIL(0x555557fe4f13), top=XIL(0x5555589bce05)) at chartab.c:784
#11 0x0000555555647847 in map_char_table (c_function=0x0, function=XIL(0x55555e57e475), table=XIL(0x5555589bce05), arg=XIL(0x5555589bce05)) at chartab.c:870
#12 0x0000555555647a14 in Fmap_char_table (function=<optimized out>, char_table=<optimized out>) at chartab.c:930
#13 0x0000555555716690 in Ffuncall (nargs=3, args=args <at> entry=0x7fffffffa818) at lisp.h:2093
#14 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#15 0x0000555555716527 in Ffuncall (nargs=2, args=args <at> entry=0x7fffffffabe8) at eval.c:3055
#16 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#17 0x0000555555716527 in Ffuncall (nargs=4, args=args <at> entry=0x7fffffffb058) at eval.c:3055
#18 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#19 0x0000555555716527 in Ffuncall (nargs=2, args=args <at> entry=0x7fffffffb4b8) at eval.c:3055
#20 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#21 0x0000555555716527 in Ffuncall (nargs=4, args=args <at> entry=0x7fffffffb8f8) at eval.c:3055
#22 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#23 0x0000555555716527 in Ffuncall (nargs=2, args=args <at> entry=0x7fffffffbc28) at eval.c:3055
#24 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#25 0x0000555555716527 in Ffuncall (nargs=3, args=0x7fffffffbee0) at eval.c:3055
#26 0x00005555557167d3 in call2 (fn=fn <at> entry=XIL(0x55555e57c415), arg1=<optimized out>, arg2=<optimized out>) at eval.c:2906
#27 0x0000555555646c8d in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57c415), table=table <at> entry=XIL(0x55555caf085d), arg=arg <at> entry=XIL(0x55555c90fc85), val=<optimized out>, range=range <at> entry=XIL(0x555557fc4153), top=XIL(0x55555c90fc85)) at lisp.h:1420
#28 0x00005555556469b7 in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57c415), table=table <at> entry=XIL(0x55555c8fb995), arg=arg <at> entry=XIL(0x55555c90fc85), val=<optimized out>, range=range <at> entry=XIL(0x555557fc4153), top=XIL(0x55555c90fc85)) at chartab.c:784
#29 0x00005555556469b7 in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57c415), table=table <at> entry=XIL(0x55555c93f7cd), arg=arg <at> entry=XIL(0x55555c90fc85), val=<optimized out>, range=range <at> entry=XIL(0x555557fc4153), top=XIL(0x55555c90fc85)) at chartab.c:784
#30 0x00005555556469b7 in map_sub_char_table (c_function=c_function <at> entry=0x0, function=function <at> entry=XIL(0x55555e57c415), table=table <at> entry=XIL(0x55555c90fc85), arg=arg <at> entry=XIL(0x55555c90fc85), val=<optimized out>, range=range <at> entry=XIL(0x555557fc4153), top=XIL(0x55555c90fc85)) at chartab.c:784
#31 0x0000555555647847 in map_char_table (c_function=0x0, function=XIL(0x55555e57c415), table=XIL(0x55555c90fc85), arg=XIL(0x55555c90fc85)) at chartab.c:870
#32 0x0000555555647a14 in Fmap_char_table (function=<optimized out>, char_table=<optimized out>) at chartab.c:930
#33 0x00007fffdeb87266 in F636861722d666f6c642d2d6d616b652d7461626c65_char_fold__make_table_0 () at ~/.emacs.d/eln-cache/28.0.50-7cdc5574/char-fold-b79b1b8c-5a333c88.eln
#34 0x0000555555716690 in Ffuncall (nargs=1, args=0x7fffffffc438) at lisp.h:2093
#35 0x00007fffdeb873e4 in F636861722d666f6c642d7570646174652d7461626c65_char_fold_update_table_0 () at ~/.emacs.d/eln-cache/28.0.50-7cdc5574/char-fold-b79b1b8c-5a333c88.eln
#36 0x0000555555719158 in eval_sub (form=<optimized out>) at lisp.h:2093
#37 0x00005555557415cd in readevalloop (readcharfun=XIL(0x55555c9f15d5), infile0=0x0, sourcename=XIL(0x55555c9f1e14), printflag=false, unibyte=<optimized out>, readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2311
#38 0x00005555557426e5 in Feval_buffer (buffer=<optimized out>, printflag=XIL(0), filename=XIL(0x55555c9f1e14), unibyte=XIL(0), do_allow_print=XIL(0x30)) at lisp.h:1376
#39 0x0000555555716690 in Ffuncall (nargs=6, args=args <at> entry=0x7fffffffc6b0) at lisp.h:2093
#40 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#41 0x0000555555716527 in Ffuncall (nargs=5, args=0x7fffffffca20) at eval.c:3055
#42 0x000055555571688d in call4 (fn=<optimized out>, arg1=<optimized out>, arg2=arg2 <at> entry=XIL(0x55555c9f1e14), arg3=arg3 <at> entry=XIL(0), arg4=arg4 <at> entry=XIL(0)) at eval.c:2921
#43 0x00005555557423cd in Fload (file=<optimized out>, noerror=XIL(0), nomessage=<optimized out>, nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1376
#44 0x0000555555716690 in Ffuncall (nargs=2, args=0x7fffffffcca0) at lisp.h:2093
#45 0x00007fffdf9e75a5 in F6f72672d626162656c2d6c6f61642d66696c65_org_babel_load_file_0 () at ~/.emacs.d/eln-cache/28.0.50-7cdc5574/org-28d11805-438c963d.eln
#46 0x00005555557190df in eval_sub (form=<optimized out>) at lisp.h:2093
#47 0x00005555557415cd in readevalloop (readcharfun=XIL(0x555558421e55), infile0=0x0, sourcename=XIL(0x555556d84504), printflag=false, unibyte=<optimized out>, readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2311
#48 0x00005555557426e5 in Feval_buffer (buffer=<optimized out>, printflag=XIL(0), filename=XIL(0x555556d84504), unibyte=XIL(0), do_allow_print=XIL(0x30)) at lisp.h:1376
#49 0x0000555555716690 in Ffuncall (nargs=6, args=args <at> entry=0x7fffffffcf70) at lisp.h:2093
#50 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#51 0x0000555555716527 in Ffuncall (nargs=5, args=0x7fffffffd2e0) at eval.c:3055
#52 0x000055555571688d in call4 (fn=<optimized out>, arg1=<optimized out>, arg2=arg2 <at> entry=XIL(0x555556d84504), arg3=arg3 <at> entry=XIL(0), arg4=arg4 <at> entry=XIL(0)) at eval.c:2921
#53 0x00005555557423cd in Fload (file=<optimized out>, noerror=XIL(0), nomessage=<optimized out>, nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1376
#54 0x00005555557190a3 in eval_sub (form=<optimized out>) at lisp.h:2093
#55 0x00005555557415cd in readevalloop (readcharfun=XIL(0x55555653547d), infile0=0x0, sourcename=XIL(0x5555564e8394), printflag=false, unibyte=<optimized out>, readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2311
#56 0x00005555557426e5 in Feval_buffer (buffer=<optimized out>, printflag=XIL(0), filename=XIL(0x5555564e8394), unibyte=XIL(0), do_allow_print=XIL(0x30)) at lisp.h:1376
#57 0x0000555555716690 in Ffuncall (nargs=6, args=args <at> entry=0x7fffffffd720) at lisp.h:2093
#58 0x0000555555754ba4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#59 0x0000555555716527 in Ffuncall (nargs=5, args=0x7fffffffda90) at eval.c:3055
#60 0x000055555571688d in call4 (fn=<optimized out>, arg1=<optimized out>, arg2=arg2 <at> entry=XIL(0x5555564e8394), arg3=arg3 <at> entry=XIL(0x30), arg4=arg4 <at> entry=XIL(0x30)) at eval.c:2921
#61 0x00005555557423cd in Fload (file=<optimized out>, noerror=XIL(0x2aaa9a056768), nomessage=<optimized out>, nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1376
#62 0x0000555555716690 in Ffuncall (nargs=4, args=0x7fffffffdd28) at lisp.h:2093
#63 0x00007fffef612071 in F737461727475702d2d6c6f61642d757365722d696e69742d66696c65_startup__load_user_init_file_0 () at ../native-lisp/28.0.50-7cdc5574/preloaded/startup-bbc6ea72-6a9af975.eln
#64 0x0000555555716690 in Ffuncall (nargs=4, args=0x7fffffffde20) at lisp.h:2093
#65 0x00007fffef613c04 in F636f6d6d616e642d6c696e65_command_line_0 () at ../native-lisp/28.0.50-7cdc5574/preloaded/startup-bbc6ea72-6a9af975.eln
#66 0x0000555555716690 in Ffuncall (nargs=1, args=0x7fffffffdf08) at lisp.h:2093
#67 0x00007fffef610aa6 in F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 () at ../native-lisp/28.0.50-7cdc5574/preloaded/startup-bbc6ea72-6a9af975.eln
#68 0x0000555555719158 in eval_sub (form=<optimized out>) at lisp.h:2093
#69 0x000055555571acad in Feval (form=XIL(0x7fffefe9581b), lexical=<optimized out>) at eval.c:2343
#70 0x0000555555715547 in internal_condition_case (bfun=bfun <at> entry=0x555555695920 <top_level_2>, handlers=handlers <at> entry=XIL(0x90), hfun=hfun <at> entry=0x55555569b580 <cmd_error>) at eval.c:1478
#71 0x000055555569665a in top_level_1 (ignore=ignore <at> entry=XIL(0)) at lisp.h:1008
#72 0x0000555555717d8b in internal_catch (tag=tag <at> entry=XIL(0xe550), func=func <at> entry=0x555555696630 <top_level_1>, arg=arg <at> entry=XIL(0)) at eval.c:1198
#73 0x00005555556958a0 in command_loop () at lisp.h:1008
#74 0x000055555569b18a in recursive_edit_1 () at keyboard.c:720
#75 0x000055555569b4c6 in Frecursive_edit () at keyboard.c:789
#76 0x00005555555a9aff in main (argc=1, argv=<optimized out>) at emacs.c:2298

Lisp Backtrace:
"format" (0xffffa068)
0x5e57e470 PVEC_COMPILED
"map-char-table" (0xffffa820)
"regexp-opt-charset" (0xffffabf0)
"regexp-opt-group" (0xffffb060)
"regexp-opt-group" (0xffffb4c0)
"regexp-opt-group" (0xffffb900)
"regexp-opt" (0xffffbc30)
0x5e57c410 PVEC_COMPILED
"char-fold--make-table" (0xffffc440)
"char-fold-update-table" (0xffffc4a0)
"eval-buffer" (0xffffc6b8)
"load-with-code-conversion" (0xffffca28)
"load-file" (0xffffcca8)
"org-babel-load-file" (0xffffcd60)
"eval-buffer" (0xffffcf78)
"load-with-code-conversion" (0xffffd2e8)
"load" (0xffffd510)
"eval-buffer" (0xffffd728)
"load-with-code-conversion" (0xffffda98)
"load" (0xffffdd30)
"startup--load-user-init-file" (0xffffde28)
"command-line" (0xffffdf10)
"normal-top-level" (0xffffdfb0)
(gdb) 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Fri, 28 May 2021 10:11:35 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Date: Fri, 28 May 2021 09:37:49 +0300
> 
> Yesterday's changes in lisp_string_width cause crashes:
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> composition_gstring_width (gstring=<optimized out>, from=1, from <at> entry=0, to=12, metrics=metrics <at> entry=0x0) at composite.c:777
> 777	      if (NILP (LGLYPH_ADJUSTMENT (*glyph)))
> (gdb) bt
> #0  composition_gstring_width (gstring=<optimized out>, from=1, from <at> entry=0, to=12, metrics=metrics <at> entry=0x0) at composite.c:777
> #1  0x0000555555642ff7 in lisp_string_width (string=string <at> entry=XIL(0x555557825e54), from=from <at> entry=0, to=to <at> entry=1, precision=precision <at> entry=-1, nchars=nchars <at> entry=0x7fffffff4850, nbytes=nbytes <at> entry=0x7fffffff4858) at lisp.h:1644
> #2  0x000055555570c46e in styled_format (nargs=<optimized out>, args=<optimized out>, message=<optimized out>) at editfns.c:3392
> #3  0x0000555555716690 in Ffuncall (nargs=4, args=args <at> entry=0x7fffffffa060) at lisp.h:2093

Thanks, but I need a recipe to reproduce this, and/or at least some
idea about which variables cause the problem.  The backtrace you show
is from an optimized build where the values of the relevant variables
are all "optimized out".  That doesn't give me much to work with, and
there are no other experts on composite.c on board to help.  So I need
all the help you can provide to fix this.

TIA

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: juri <at> linkov.net
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Fri, 28 May 2021 10:29:57 +0300

> Date: Fri, 28 May 2021 10:11:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 48711 <at> debbugs.gnu.org
> 
> Thanks, but I need a recipe to reproduce this, and/or at least some
> idea about which variables cause the problem.

But before you embark on providing that info, please try the latest
master branch, where I installed a stab-in-the-dark change which
hopefully could take care of whatever happened in your case.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Fri, 28 May 2021 11:39:46 +0300

tags 48711 fixed
close 48711 28.0.50
thanks

> But before you embark on providing that info, please try the latest
> master branch, where I installed a stab-in-the-dark change which
> hopefully could take care of whatever happened in your case.

This is the shortest test case:

  (require 'char-fold)
  (setq char-fold-symmetric t)
  (char-fold-update-table)

and your latest change 3fe2f482bd fixed it,
so this can be closed.

BTW, now compilation highlights this line

  Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others

using red error face.  Does this mean that something needs to be fixed?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Fri, 28 May 2021 14:06:04 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 48711 <at> debbugs.gnu.org
> Date: Fri, 28 May 2021 11:39:46 +0300
> 
> This is the shortest test case:
> 
>   (require 'char-fold)
>   (setq char-fold-symmetric t)
>   (char-fold-update-table)
> 
> and your latest change 3fe2f482bd fixed it,
> so this can be closed.

Thanks.  The fix notwithstanding, the test case is very useful, and it
already allowed me to find one more bug there, which was exposed by
adding support for automatic compositions.  Now fixed.

> BTW, now compilation highlights this line
> 
>   Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others
> 
> using red error face.  Does this mean that something needs to be fixed?

You mean, this is a result of the string-width changes?

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Fri, 28 May 2021 21:32:12 +0300

>> BTW, now compilation highlights this line
>>
>>   Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others
>>
>> using red error face.  Does this mean that something needs to be fixed?
>
> You mean, this is a result of the string-width changes?

I don't know, the red error face was in the compilation output only 1 day,
but it's weird that now the last compilation highlights the line

  Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others

with the blue face-lock-function-name-face correctly again.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Fri, 28 May 2021 22:03:42 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 48711 <at> debbugs.gnu.org
> Date: Fri, 28 May 2021 21:32:12 +0300
> 
> >> BTW, now compilation highlights this line
> >>
> >>   Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others
> >>
> >> using red error face.  Does this mean that something needs to be fixed?
> >
> > You mean, this is a result of the string-width changes?
> 
> I don't know, the red error face was in the compilation output only 1 day,
> but it's weird that now the last compilation highlights the line
> 
>   Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others
> 
> with the blue face-lock-function-name-face correctly again.

I don't think I follow.  Are you saying that the problem no longer
exists?

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Sun, 30 May 2021 00:38:56 +0300

>> I don't know, the red error face was in the compilation output only 1 day,
>> but it's weird that now the last compilation highlights the line
>>
>>   Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others
>>
>> with the blue face-lock-function-name-face correctly again.
>
> I don't think I follow.  Are you saying that the problem no longer
> exists?

No problem anymore, everything is back to normal.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 48711 <at> debbugs.gnu.org
Subject: Re: bug#48711: Crashes in lisp_string_width
Date: Sun, 30 May 2021 09:33:15 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 48711 <at> debbugs.gnu.org
> Date: Sun, 30 May 2021 00:38:56 +0300
> 
> >> I don't know, the red error face was in the compilation output only 1 day,
> >> but it's weird that now the last compilation highlights the line
> >>
> >>   Pure-hashed: 15274 strings, 3028 vectors, 41734 conses, 2570 bytecodes, 254 others
> >>
> >> with the blue face-lock-function-name-face correctly again.
> >
> > I don't think I follow.  Are you saying that the problem no longer
> > exists?
> 
> No problem anymore, everything is back to normal.

Then I guess we can let the sleeping dogs lie...

Thanks.

Previous Next

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