GNU bug report logs - #61960
30.0.50; Unexec build reliably crashes during loadup

Previous Next

Full log

View this message in rfc822 format

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61960 <at> debbugs.gnu.org
Subject: bug#61960: 30.0.50; Unexec build reliably crashes during loadup
Date: Fri, 21 Jul 2023 19:09:04 +0300

Okay, so I've spent today a lot of time debugging this problem, and out
of interesting things I found so far the following:

1. Problem seems like some discrepancy between _heapinfo and an abase
whose index points at _heapinfo
2. Given two Emacs executions, one which buggy and one isn't, I found
that "good execution" returns from `aligned_alloc` the same result it
gotten from `_malloc_internal_nolock`, whereas in "bad execution" it's
different.
   The reason for this is that inside `aligned_alloc()` "good
execution" *never* goes into `if (adj != 0)` condition. The function
has 3 places where `malloc` is called (which is not actually a malloc()
but instead a wrapper `gmalloc` eventually calling into
`_malloc_internal_nolock()`), one of which is inside the mentioned
condition. The latter one changes `malloc` result, while 2 others do
not.

In the lieu of that it is possible that this conditional branch simply
was never tested. I decided to check how it works in a usual Emacs
build, and I found out that it doesn't even have `gmalloc.c` source
compiled in 🤷‍♂️

-----------------------

That makes me wonder if keeping this whole customized allocation engine
even makes sense. It is not used in the actual Emacs, only in `temacs`
— but why? Is it to make `temacs` faster? I would imagine in the
"compilation usecase" where `temacs` is used, shaving off a few seconds
is not worth that complexity (not to mention I am not sure how well
this code may compete with specialized allocator projects like
"jemalloc", which also do allocation caching). This code is
incomprehensible. It does funny stuff like redefining system functions,
like `malloc` to its wrappers, so even just reading it is hard. And
I've spent hours watching simultaneously two `temacs` executions, "bad"
and "good" one, recorded with `rr record`, using reverse-execution and
watchpoints and still not sure how close I am to solving the case. 

So, I would be glad to hear what people think about the purpose of this
gmalloc being in the project.

Previous Next

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