GNU bug report logs -
#78444
30.1; Crash in GC (vector_marked_p)
Previous Next
Full log
Message #17 received at 78444 <at> debbugs.gnu.org (full text, mbox):
"George P" <georgepanagopo <at> gmail.com> writes:
> Can you describe what you were doing at the time of the crash?
>
> I was not doing anything in particular (editing a latex file with LaTeX/PS mode). These crashes have happened to me at very random times. The only
> thing that I have been suspecting could be causing this is viewing org-mode buffers that have special fontification. I have
> https://github.com/awth13/org-appear and https://github.com/minad/org-modern installed, and previously I had
> https://github.com/integral-dw/org-superstar-mode. I had just viewed an org file before the crash.
I suspect it's an X problem, but that may be totally wrong. It may well
be related to fonts rather than the xterm.c code.
> Unfortunately, I don't have the program running (because I foolishly thought I could continue from the crash). I do have the core however, here is what
> you both asked for:
Thank you! Unfortunately, the buffer object itself is not contained
within the 512 last_marked elements. Can you also produce the output of
x/77gx 0x15554f39bca8
so we can see which of the buffer elements we got to?
> 0x1f646393, 0x30, 0x0, 0x98e7985, 0x8f680f4, 0x1f647ac3, 0x1f647ad3, 0xdc20, 0xa, 0x1f647aa3, 0x1f647ab3, 0xdb90, 0x2, 0x1f647a53,
> 0x1f647a93, 0x96c0, 0x1f647a83, 0x3a, 0x1f647a73, 0xa, 0x1f647a63, 0x6, 0x98e79dd, 0x98f1d0d, 0x0, 0x400000002300000d, 0x0, 0x27f62ad, 0x0,
That's "gccjit", 14, 2, 1, interspersed with some cons cells, then two
vectors or pseudovectors, Qnil, and the bogus object. So we probably
dumped a compiled unit's data, then returned to the vectors or
pseudovectors, which would be interesting.
Can you provide the output of:
p *XVECTOR(0x98e79dd)
x/32gx $.contents
p *XVECTOR(0x98f1d0d)
x/32gx $.contents
> Also, what is the memory footprint of the crashed Emacs process?
>
> Hard for me to say. I restored my session and this is the memory-report for that session. I would assume that the crashed session is 2-3 times larger:
The size of the core file might provide a good ballpark number.
"objdump -h /path/to/core" may reveal even more about how much memory
was in use.
> Does this mean you run Emacs on a Red Hat system via the Cygwin X
> implementation that runs on Windows?
>
> Correct.
Can you say more about that? Are you running using a remote X server,
or some kind of tunnel setup, or is this some sort of WSL or VM setup?
It's relevant because remote X sessions have very different timing
characteristics, and different code for determining mouse positions is
in use.
Can you also include the output of
p *terminal_list->display_info
and as much of the output of
p *terminal_list->display_info.x
as you're comfortable with (x_id_name might be something you would want
to redact), as well as
p Vx_use_fast_mouse_position
Background: I have a vague hunch that commit
ced135ebdbfb0eea719ce165a454e7ff0b681e88 is part of the problem. This
replaced the staticpro'd global variable last_mouse_scroll_bar by an
element of dpyinfo (with the same name) which does not appear to be
protected from GC. (The same is true of the last_mouse_frame,
last_mouse_glyph_frame, last_mouse_motion_frame,
x_pending_autoraise_frame elements of dpyinfo, and a few others... I
don't understand why these aren't GC-protected, and there is no comment
clearly explaining they shouldn't be, so we could try adding protection
to them and seeing whether that fixes the crashes).
Thank you, and sorry for requesting so much information!
Pip
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.