[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building the igc branch on MS-Windows
From: |
Eli Zaretskii |
Subject: |
Re: Building the igc branch on MS-Windows |
Date: |
Sat, 27 Apr 2024 09:58:00 +0300 |
> Date: Sat, 27 Apr 2024 09:11:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
>
> *** MPS GC start: Client requests: immediate full collection.
>
> Thread 1 received signal SIGSEGV, Segmentation fault.
> XCAR (c=0xb2c6f33) at lisp.h:751
> 751 return lisp_h_XLP (o);
> (gdb) bt
> #0 XCAR (c=0xb2c6f33) at lisp.h:751
> #1 assoc_no_quit (key=<optimized out>, alist=0xb2c6f33) at fns.c:2032
> #2 0x0100c20d in font_list_entities (f=0xaa1c478, spec=0xa8217a5)
> at font.c:2795
The crash is here:
for (; driver_list; driver_list = driver_list->next)
if (driver_list->on
&& (NILP (ftype) || EQ (driver_list->driver->type, ftype)))
{
Lisp_Object cache = font_get_cache (f, driver_list->driver);
ASET (scratch_font_spec, FONT_TYPE_INDEX, driver_list->driver->type);
val = assoc_no_quit (scratch_font_spec, XCDR (cache));
And font_get_cache does this on MS-Windows:
Lisp_Object
w32font_get_cache (struct frame *f)
{
struct w32_display_info *dpyinfo = FRAME_DISPLAY_INFO (f);
return (dpyinfo->name_list_element);
}
dpyinfo on MS-Windows is a single global variable
one_w32_display_info, so I made this change:
diff --git a/src/w32term.c b/src/w32term.c
index 7afd130..96f8530 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -7812,6 +7812,9 @@ #define LOAD_PROC(lib, fn) pfn##fn = (void *)
GetProcAddress (lib, #fn)
void
syms_of_w32term (void)
{
+ one_w32_display_info.name_list_element = Qnil;
+ staticpro (&one_w32_display_info.name_list_element);
+
DEFSYM (Qvendor_specific_keysyms, "vendor-specific-keysyms");
DEFSYM (Qadded, "added");
(Is this correct? should all Lisp members of global variables be
similarly staticpro'd?)
With this change, scrolling through xdisp.c now works (yay!), with the
following messages output several times to stderr:
*** MPS GC start: Generation 0 of a chain has reached capacity: start a minor
collection.
*** MPS GC start: Opportunism: client predicts plenty of idle time, so start
full collection.
(Btw, it would be nice to have these go to echo-area messages
instead.)
But the original Helmut's recipe still crashes, albeit with a
different backtrace:
*** MPS GC start: Client requests: immediate full collection.
Thread 1 received signal SIGSEGV, Segmentation fault.
gui_produce_glyphs (it=0xbfa6b0) at xdisp.c:32587
32587 boff = font->baseline_offset;
(gdb) bt
#0 gui_produce_glyphs (it=0xbfa6b0) at xdisp.c:32587
#1 0x01030e47 in display_line (it=it@entry=0xbfa6b0,
cursor_vpos=cursor_vpos@entry=1) at xdisp.c:25389
#2 0x01037611 in try_window (window=<optimized out>, window@entry=0xc0007b5,
pos=..., flags=<optimized out>, flags@entry=1) at xdisp.c:21139
#3 0x01059947 in redisplay_window (window=window@entry=0xc0007b5,
just_this_one_p=just_this_one_p@entry=false) at xdisp.c:20533
#4 0x0105cb44 in redisplay_window_0 (window=0xc0007b5) at xdisp.c:18018
#5 0x011729bb in internal_condition_case_1 (
bfun=bfun@entry=0x105cb0f <redisplay_window_0>, arg=arg@entry=0xc0007b5,
handlers=0x1a3e10c3, hfun=hfun@entry=0x1006297 <redisplay_window_error>)
at eval.c:1568
#6 0x01001eed in redisplay_windows (window=0xc0007b5) at xdisp.c:17987
#7 0x01040f5f in redisplay_internal () at xdisp.c:17387
#8 0x010424b3 in redisplay () at xdisp.c:16565
#9 0x010e61a8 in read_char (commandflag=<optimized out>, commandflag@entry=1,
map=<optimized out>, map@entry=0xa82060b, prev_event=<optimized out>,
used_mouse_menu=<optimized out>, used_mouse_menu@entry=0xbff7fb,
end_time=<optimized out>, end_time@entry=0x0) at keyboard.c:2678
#10 0x010e97dd in read_key_sequence (keybuf=keybuf@entry=0xbff8d8,
prompt=prompt@entry=0x0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=<optimized out>,
can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
prevent_redisplay@entry=false, disable_text_conversion_p=false)
at keyboard.c:10727
#11 0x010eb36b in command_loop_1 () at lisp.h:1179
#12 0x0117291d in internal_condition_case (
bfun=bfun@entry=0x10eb1b0 <command_loop_1>, handlers=handlers@entry=0x48,
hfun=hfun@entry=0x10de4f6 <cmd_error>) at eval.c:1544
#13 0x010d480b in command_loop_2 (handlers=0x48) at keyboard.c:1168
#14 0x01172837 in internal_catch (tag=tag@entry=0x87a8,
func=func@entry=0x10d47eb <command_loop_2>, arg=arg@entry=0x48)
at eval.c:1224
#15 0x010d47ab in command_loop () at lisp.h:1179
#16 0x010de0b1 in recursive_edit_1 () at keyboard.c:754
#17 0x010de3a1 in Frecursive_edit () at keyboard.c:837
#18 0x01317d3f in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:2626
(gdb) p font
$1 = (struct font *) 0xad2fce0
(gdb) p *$
Cannot access memory at address 0xad2fce0
So this is progress, but now the font structure of a face is invalid,
so some other protection is missing somewhere. Any ideas?
- Re: Building the igc branch on MS-Windows, (continued)
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows, Ihor Radchenko, 2024/04/27
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows, Ihor Radchenko, 2024/04/27
- Re: Building the igc branch on MS-Windows, Gerd Möllmann, 2024/04/27
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows,
Eli Zaretskii <=
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows, Gerd Möllmann, 2024/04/27
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows, Gerd Möllmann, 2024/04/27
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows, Gerd Möllmann, 2024/04/27
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27
- Re: Building the igc branch on MS-Windows, Gerd Möllmann, 2024/04/27
- Re: Building the igc branch on MS-Windows, Eli Zaretskii, 2024/04/27