* bug#48711: Crashes in lisp_string_width
@ 2021-05-28 6:37 Juri Linkov
2021-05-28 7:11 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2021-05-28 6:37 UTC (permalink / raw)
To: 48711
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@entry=0, to=12, metrics=metrics@entry=0x0) at composite.c:777
777 if (NILP (LGLYPH_ADJUSTMENT (*glyph)))
(gdb) bt
#0 composition_gstring_width (gstring=<optimized out>, from=1, from@entry=0, to=12, metrics=metrics@entry=0x0) at composite.c:777
#1 0x0000555555642ff7 in lisp_string_width (string=string@entry=XIL(0x555557825e54), from=from@entry=0, to=to@entry=1, precision=precision@entry=-1, nchars=nchars@entry=0x7fffffff4850, nbytes=nbytes@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@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@entry=XIL(0x55555e57e475), arg1=arg1@entry=XIL(0x555557fe4f13), arg2=<optimized out>) at eval.c:2906
#7 0x0000555555646be8 in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57e475), table=table@entry=XIL(0x55555d6d3a75), arg=arg@entry=XIL(0x5555589bce05), val=<optimized out>, range=range@entry=XIL(0x555557fe4f13), top=XIL(0x5555589bce05)) at chartab.c:837
#8 0x00005555556469b7 in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57e475), table=table@entry=XIL(0x555556f32b1d), arg=arg@entry=XIL(0x5555589bce05), val=<optimized out>, range=range@entry=XIL(0x555557fe4f13), top=XIL(0x5555589bce05)) at chartab.c:784
#9 0x00005555556469b7 in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57e475), table=table@entry=XIL(0x555559509bbd), arg=arg@entry=XIL(0x5555589bce05), val=<optimized out>, range=range@entry=XIL(0x555557fe4f13), top=XIL(0x5555589bce05)) at chartab.c:784
#10 0x00005555556469b7 in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57e475), table=table@entry=XIL(0x5555589bce05), arg=arg@entry=XIL(0x5555589bce05), val=<optimized out>, range=range@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@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@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@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@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@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@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@entry=XIL(0x55555e57c415), arg1=<optimized out>, arg2=<optimized out>) at eval.c:2906
#27 0x0000555555646c8d in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57c415), table=table@entry=XIL(0x55555caf085d), arg=arg@entry=XIL(0x55555c90fc85), val=<optimized out>, range=range@entry=XIL(0x555557fc4153), top=XIL(0x55555c90fc85)) at lisp.h:1420
#28 0x00005555556469b7 in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57c415), table=table@entry=XIL(0x55555c8fb995), arg=arg@entry=XIL(0x55555c90fc85), val=<optimized out>, range=range@entry=XIL(0x555557fc4153), top=XIL(0x55555c90fc85)) at chartab.c:784
#29 0x00005555556469b7 in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57c415), table=table@entry=XIL(0x55555c93f7cd), arg=arg@entry=XIL(0x55555c90fc85), val=<optimized out>, range=range@entry=XIL(0x555557fc4153), top=XIL(0x55555c90fc85)) at chartab.c:784
#30 0x00005555556469b7 in map_sub_char_table (c_function=c_function@entry=0x0, function=function@entry=XIL(0x55555e57c415), table=table@entry=XIL(0x55555c90fc85), arg=arg@entry=XIL(0x55555c90fc85), val=<optimized out>, range=range@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@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@entry=XIL(0x55555c9f1e14), arg3=arg3@entry=XIL(0), arg4=arg4@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@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@entry=XIL(0x555556d84504), arg3=arg3@entry=XIL(0), arg4=arg4@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@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@entry=XIL(0x5555564e8394), arg3=arg3@entry=XIL(0x30), arg4=arg4@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@entry=0x555555695920 <top_level_2>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55555569b580 <cmd_error>) at eval.c:1478
#71 0x000055555569665a in top_level_1 (ignore=ignore@entry=XIL(0)) at lisp.h:1008
#72 0x0000555555717d8b in internal_catch (tag=tag@entry=XIL(0xe550), func=func@entry=0x555555696630 <top_level_1>, arg=arg@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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-28 6:37 bug#48711: Crashes in lisp_string_width Juri Linkov
@ 2021-05-28 7:11 ` Eli Zaretskii
2021-05-28 7:29 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-28 7:11 UTC (permalink / raw)
To: Juri Linkov; +Cc: 48711
> From: Juri Linkov <juri@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@entry=0, to=12, metrics=metrics@entry=0x0) at composite.c:777
> 777 if (NILP (LGLYPH_ADJUSTMENT (*glyph)))
> (gdb) bt
> #0 composition_gstring_width (gstring=<optimized out>, from=1, from@entry=0, to=12, metrics=metrics@entry=0x0) at composite.c:777
> #1 0x0000555555642ff7 in lisp_string_width (string=string@entry=XIL(0x555557825e54), from=from@entry=0, to=to@entry=1, precision=precision@entry=-1, nchars=nchars@entry=0x7fffffff4850, nbytes=nbytes@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@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-28 7:11 ` Eli Zaretskii
@ 2021-05-28 7:29 ` Eli Zaretskii
2021-05-28 8:39 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-28 7:29 UTC (permalink / raw)
To: juri; +Cc: 48711
> Date: Fri, 28 May 2021 10:11:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 48711@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-28 7:29 ` Eli Zaretskii
@ 2021-05-28 8:39 ` Juri Linkov
2021-05-28 11:06 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2021-05-28 8:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 48711
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-28 8:39 ` Juri Linkov
@ 2021-05-28 11:06 ` Eli Zaretskii
2021-05-28 18:32 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-28 11:06 UTC (permalink / raw)
To: Juri Linkov; +Cc: 48711
> From: Juri Linkov <juri@linkov.net>
> Cc: 48711@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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-28 11:06 ` Eli Zaretskii
@ 2021-05-28 18:32 ` Juri Linkov
2021-05-28 19:03 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2021-05-28 18:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 48711
>> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-28 18:32 ` Juri Linkov
@ 2021-05-28 19:03 ` Eli Zaretskii
2021-05-29 21:38 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-28 19:03 UTC (permalink / raw)
To: Juri Linkov; +Cc: 48711
> From: Juri Linkov <juri@linkov.net>
> Cc: 48711@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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-28 19:03 ` Eli Zaretskii
@ 2021-05-29 21:38 ` Juri Linkov
2021-05-30 6:33 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2021-05-29 21:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 48711
>> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#48711: Crashes in lisp_string_width
2021-05-29 21:38 ` Juri Linkov
@ 2021-05-30 6:33 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2021-05-30 6:33 UTC (permalink / raw)
To: Juri Linkov; +Cc: 48711
> From: Juri Linkov <juri@linkov.net>
> Cc: 48711@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-05-30 6:33 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-05-28 6:37 bug#48711: Crashes in lisp_string_width Juri Linkov
2021-05-28 7:11 ` Eli Zaretskii
2021-05-28 7:29 ` Eli Zaretskii
2021-05-28 8:39 ` Juri Linkov
2021-05-28 11:06 ` Eli Zaretskii
2021-05-28 18:32 ` Juri Linkov
2021-05-28 19:03 ` Eli Zaretskii
2021-05-29 21:38 ` Juri Linkov
2021-05-30 6:33 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).