xemacs 21.5.35 crashes whena file is loaded

[Jody Weissmann]

When i start xemacs with no arguments it seems to start normally. However, there is a n output on the console: "Warning: Missing charsets in String to FontSet conversion", and the font-related menu items in "Options" are disabled ("cannot parse current font")

When i open a *.cpp or ".h file from the file menu, xemacs crashes. On the other hand, normal text files, csv files etc. are opened but rendered with a proportional font. This might be related with the syntax coloring.

Since i am still unable to attach a file to a post from within groups.google.com i'll send the output from the crash in a separate mail.

Regards
Jody

[Jody Weissmann]

I have put the files of interest in pastebin:
- where in gdb: https://pastebin.com/rrdEczbW
- custom.el: https://pastebin.com/eZVHaMCj
- crash output: https://pastebin.com/ur7x6L59

[comp.emacs.xemacs]

The emacs-version is
"21.5 (beta35) \"kohlrabi\" XEmacs Lucid"

[Jody Weissmann]

Hi
I managed to narrow down the problem, i think.
In my ~/.xemacs/custom.el i have the statement:

(custom-set-variables
'(c-basic-offset 4)
'(column-number-mode t)
'(font-lock-mode t nil (font-lock))
'(indent-tabs-mode nil)
'(line-number-mode t)
'(truncate-lines t))

if i omit the "font-lock-mode" entry:

(custom-set-variables
'(c-basic-offset 4)
'(column-number-mode t)
'(indent-tabs-mode nil)
'(line-number-mode t)
'(truncate-lines t))

then the crash does not occur anymore.

Furthermore, i have the following statement in my custom.el:

(custom-set-faces
'(default ((t (:background "snow2" :size "11pt" :family "Fixed"))) t)
'(bg:snow2 ((t (:foreground "light gray" :background "light gray"))) t))

With this statement, i get a proportional font, and the "Font" and "Font Size" items of "Options" are disabled ("cannot parse current font").
If i comment out this statement, the font is non-proportional, and the "Font" option has dozens of fonts (most of them disabled, only 4 items named "Lucida Mono" have green diamonds but they cannot be unchecked).

Unfortunately, syntax coloring does not happen. I suspect it has to do something the "font-lock-mode" statement.

So i would say there are two issues: the first being the "font-lock-mode" problem, the second one being a bad definition of the default font (which influences the entire list of fonts)


Regards
Jody

[Jody Weissmann]

I have now found an absolutely minimal example (4 bytes) for which xemacs does crash, whereas a file with one character less does not lead to a crash.

A file named "no_crash.h" (or "no_crash.cpp") with this content (3 Bytes) does not crash:
x::

A file named "yes_crash.h" (or "yes_crash.cpp") with this content (4 bytes) *does* crash
x::x
(The crash even occurs during the writing of such a h-file or cpp-file: the string "x::" can be typed in without a problem, but after typing the second 'x', xemacs immediately crashes)

If i rename this file to "yes_crash.py", xemacs can open it without a problem.

(when a cpp, h or py file can be opened by xemacs, the font is non-proportional, and the "Font" and "FontSize" menu items are still disabled ("cannot parse current font")

[Henry S. Thompson]

OK, thanks for all your work to narrow down the problem.

It turns out to have nothing to do with font stuff, that was a red
herring, AFAICS.

See below for a simple file which you can use to stimulate the bug.

Just do
M-x load-file
bug.el
M-x die

Some work has been done recently on regexp matching, which I'm
guessing is the source of the problem. I'm working now to locate the
change which introduced the problem.

ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]

[Henry S. Thompson]

And here's the file :-).

[Henry S. Thompson]

I have identified the update that causes the problem, a major one to
the file regex.c:

changeset: 7316:55821aa1e0d7
user: Aidan Kehoe <keh...@parhasard.net>
date: Tue Jan 25 12:12:38 2022 +0000
summary: Represent register numbers with two bytes,
compiled regular expressions.

src/ChangeLog | 42 ++
src/regex.c | 572 +++++++++++++++++++--------------------
src/regex.h | 37 ++-
tests/ChangeLog | 7 +
tests/automated/regexp-tests.el | 16 +-
5 files changed, 375 insertions(+), 299 deletions(-)

It's too complicated for me to dare to try to pin-point the problem
more closely. I know Aidan is a busy person, but I'm sure he'll work
on this as soon as he can.

[Aidan Kehoe]

Hi Henry, hi Jody --

Ar an chéad lá is fiche de mí Méan Fómhair, scríobh Henry S. Thompson:

> I have identified the update that causes the problem, a major one to
> the file regex.c:
>
> changeset: 7316:55821aa1e0d7
> user: Aidan Kehoe <keh...@parhasard.net>
> date: Tue Jan 25 12:12:38 2022 +0000
> summary: Represent register numbers with two bytes,
> compiled regular expressions.

Thanks, that should do the trick to let me pin down what’s going on. I have
some regexp changes close to ready to be pushed related to
https://foss.heptapod.net/xemacs/xemacs/-/issues/3 , I have good insight into
the regexp code.

> src/ChangeLog | 42 ++
> src/regex.c | 572 +++++++++++++++++++--------------------
> src/regex.h | 37 ++-
> tests/ChangeLog | 7 +
> tests/automated/regexp-tests.el | 16 +-
> 5 files changed, 375 insertions(+), 299 deletions(-)
>
> It's too complicated for me to dare to try to pin-point the problem
> more closely. I know Aidan is a busy person, but I'm sure he'll work
> on this as soon as he can.

Best,

Aidan

--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[Jody Weissmann]

Hi Henry, hi Aidan

Thank you for your efforts. I have executed the steps regarding bug.el, but this did not crash xemacs.
Just to be sure i loaded yes_crash.cpp (the one containing just the 4 chars "x::x"), and this did crash xemacs...

[Henry S. Thompson]

Jody Weissmann writes:

> Thank you for your efforts. I have executed the steps regarding
> bug.el, but this did not crash xemacs.

> Just to be sure i loaded yes_crash.cpp (the one containing just the
> 4 chars "x::x"), and this did crash xemacs...

That's curious. Did you include the first line, the comment

;;; x::x

?

Ah, and I realise my instructions were not complete, try the following
please.

C-x C-f
bug.el

M-x load-file
bug.el
M-x die

[Jody Weissmann]

Yes, that way it crashes

I found that i could simply type ";;; x::x" at the beginning of *scratch* instead of loading bug.el as a file, and then do the "M-x load-file" for bug.el, followed by "!M-x die"

[Aidan Kehoe]

Ar an dara lá is fiche de mí Méan Fómhair, scríobh Aidan Kehoe:

> Hi Henry, hi Jody --
>
> Ar an chéad lá is fiche de mí Méan Fómhair, scríobh Henry S. Thompson:
>
> > I have identified the update that causes the problem, a major one to
> > the file regex.c:
> >
> > changeset: 7316:55821aa1e0d7
> > user: Aidan Kehoe <keh...@parhasard.net>
> > date: Tue Jan 25 12:12:38 2022 +0000
> > summary: Represent register numbers with two bytes,
> > compiled regular expressions.
>
> Thanks, that should do the trick to let me pin down what’s going on. I have
> some regexp changes close to ready to be pushed related to
> https://foss.heptapod.net/xemacs/xemacs/-/issues/3 , I have good insight into
> the regexp code.

OK, can’t reproduce it, and haven’t been able to get to those regexp changes.

We know the previous code worked, so I have pushed 53c8f75af097 which just
forces the correct order for the set_extent_endpoints() START and END
arguments. If you have the opportunity, please check that this works.