[Toybox] [PATCH 2] Fix segfault in config2help

[Patrick Oppenlander]

For some reason config2help started segfaulting on me.

I haven't had time to completely track down the reason for this, but it seems that under some conditions sym->help is left dangling after memory is free'd by:

// Append trailing lines.
while (tfrom) dlist_add(&anchor, dlist_zap(&tfrom));

Either way, testing sym->enabled appears to fix the problem.

============8<===============

commit 6c892548ad623ffe2b026139d7f22efb7763f024 (HEAD -> master)
Author: Patrick Oppenlander <***@gmail.com>
Date: Thu Sep 21 15:37:42 2017 +1000

fix segfault in config2help

Somehow sym->help can be left non-null after trailing lines are appended.

Fix by not attempting to print help for disabled symbols.

diff --git a/scripts/config2help.c b/scripts/config2help.c
index d238939..cdb250d 100644
--- a/scripts/config2help.c
+++ b/scripts/config2help.c
@@ -397,7 +397,7 @@ int main(int argc, char *argv[])
while (sym) {
struct double_list *dd;

- if (sym->help) {
+ if (sym->help && sym->enabled) {
int i;
char *s = xstrdup(sym->name);

[Rob Landley]

Post by Patrick Oppenlander
For some reason config2help started segfaulting on me.

Yeah, the openembedded maintainer recently hit this too:

http://lists.openembedded.org/pipermail/openembedded-devel/2017-September/114879.html

But only on a system with all the package upgrades applied, installing
straight from DVD ditn't reproduce it. I've een very slowly debugging it
under a qemu instance (which takes like 15 seconds to pull up "vi" on a
file, for some reason arch linux's gui is REALLY slow under qemu).

Either gcc or the libc (or ld, or...) got upgraded recently and started
Doing A Thing.

His workaround was to turn "usage: ls --color" into "usage: --color"
(which means it bypasses that entry entirely)...

Post by Patrick Oppenlander
I haven't had time to completely track down the reason for this, but it
seems that under some conditions sym->help is left dangling after memory
// Append trailing lines.
while (tfrom) dlist_add(&anchor, dlist_zap(&tfrom));
Either way, testing sym->enabled appears to fix the problem.

That's a workaround, not a fix. And it means we'd need to rebuild
generated/help.h every time .config changes (which right now we don't).

Lemme look at your other patch more closely, that's probably the start
of the right fix...

Thanks,

Rob

[Patrick Oppenlander]

Post by Rob Landley
But only on a system with all the package upgrades applied, installing
straight from DVD ditn't reproduce it. I've een very slowly debugging it
under a qemu instance (which takes like 15 seconds to pull up "vi" on a
file, for some reason arch linux's gui is REALLY slow under qemu).

Instead of using qemu you could run it under valgrind or try gcc's
address sanitizer. I just checked and valgrind identifies both of
these as "use after free" problems.

Post by Rob Landley
Either gcc or the libc (or ld, or...) got upgraded recently and started
Doing A Thing.

I observed the same behaviour -- this started after a system update.

Post by Rob Landley

Post by Patrick Oppenlander
I haven't had time to completely track down the reason for this, but it
seems that under some conditions sym->help is left dangling after memory
// Append trailing lines.
while (tfrom) dlist_add(&anchor, dlist_zap(&tfrom));
Either way, testing sym->enabled appears to fix the problem.

That's a workaround, not a fix. And it means we'd need to rebuild
generated/help.h every time .config changes (which right now we don't).

True.

Post by Rob Landley
Lemme look at your other patch more closely, that's probably the start
of the right fix...

There may be a better solution than strdup'ing the name. That was the
easiest fix to get it going again.

Patrick