[neomutt-devel] Lua in neomutt | systematically finding segmentation faults

Ihor Antonov ihor at antonovs.family
Wed Mar 3 04:21:26 CET 2021

On 2021-03-02 20:27, toogley wrote:
> Hello everybody,
> 1) Lua
> ------
> tldr; i think Lua bindings are of no use at the moment and could be
> removed.

I agree with the spirit. Dead code must go. The real question is it
"really" dead? I can't speak about how much this feature is used,
perhaps flatcap or gahr know better. But given our current push for
refactoring shedding off some code would only be a plus..

> 2) finding segmentation faults
> ------------------------------
> tldr; OpenBSD is more strict about memory errors. We can use that in our
> CI setup and create functional tests.
> i've seen many times on github: users report crashes but either don't
> include steps to reproduce, a good backtrace with debug symbols or other
> things. And even then, devs have to try to reproduce that which is
> sometimes hard.

This is true, and it gets worse by distributions that disable -g cflag,
so even if user manages to open the the core dump in gdb it is of a
little use. We do have -g enabled by default, but we can't influence
what package maintainers do.

> And as far as i understand OpenBSD is more strict about memory errors
> compared to most linux distros and crashes therefore more often when
> something slightly is wrong.

This is an oversimplification. OpenBSD is just a different OS, and it
has different libc, different kernel, same POSIX syscall may behave
slightly differently, in the end even OpenBSD can have bugs. Lastly,
OpenBSD has the least amount of users comparing to Linux and FreeBSD so
it is fair to suggest it is the least tested. 

With that in mind I don't think it is fair to say that crashes are more
frequent on OpenBSD because it is a more secure OS (I am also not
denying that it is). It is the overall complexity of the problem that
makes it hard, too many moving parts, that is all.

> So i thought: hey, we can use that for our advantage! We could rent a
> builds.sr.ht machine and configure it so it runs with every pull
> request. After building and running the tests, we can start the neomutt
> binary with some very complicated neomutt configs and see if it crashes.
> If it crashes, builds.sr.ht provides the ability to SSH into the build
> VM. This is great because devs have automatically a working environment
> where they can attach to gdb and look around. Probably it is also very
> reproducible.
> But unfortunately i don't have time at the moment to implement that so
> i'm writing here.

Using sourcehut is something that I was thinking about too. I presented
this idea to flatcap once. I don't think that anybody would object to
more CI and tests. We just don't have enough manpower to do it.
If you are willing to contribute the build definitions I think we can
ask Drew to give us free account. (He did so when I asked for OpenSMTPD)


More information about the neomutt-devel mailing list