Mention that GNU sed is needed for MacOS

[amakukha]

Building with make fails with errors from clang on MacOS. The reason is that gsed is not found and there is no warning or instruction to install it.

I think, that either a warning should be added (possibly into scripts/portability.sh) or a note into the "Building toybox" section of README. Better both.

P.S. Also, to compile toybox I had to set CPUS=1, comment #include "generated/newtoys.h" in lib/help.c, and comment quite a few commands in .config, ending up with 136 of them. (Maybe it helps someone out there.)

OS version: MacOS Mojave 10.14.6

[enh-google]

I had to set CPUS=1

really? i thought i'd fixed the nproc issue? i was forced to switch to 10.15 this week, but i'd been building on 10.14 before then. and building on 10.15 works for me [with just a GNU sed added to my path] right now.

comment quite a few commands in .config

yeah, unfortunately make defconfig doesn't do the right thing on macOS. you need make macos_defconfig. (though there's one line of bitrot in there atrm. i sent a patch to fix that to the list...)

[amakukha]

I tried one more time, but with macos_defconfig. Now it builds without CPUS=1, though previously it had a specific error associated with it.

The only problem that I still get is this:

In file included from lib/help.c:5:

./generated/help.h:577:19: warning: missing terminating '"' character [-Winvalid-pp-token]
#define HELP_date "usage: date [-u] [-r FILE] [-d DATE] [+DISPLAY_FORMAT] [-D SET_FORMAT] [SET]\n\nSet/ge
^
In file included from lib/help.c:16:
./generated/newtoys.h:14:70: error: expected ';' after top level declarator
USE_BASE64(NEWTOY(base64, "diw#<0=76[!dw]", TOYFLAG_USR|TOYFLAG_BIN))

A quick temporary fix that I use is to replace:

static char *help_data =
#include "generated/newtoys.h"
;

with:

static char *help_data = "no help"
//#include "generated/newtoys.h"
;

P.S. 26 more tools compiled for me, compared to macos_defconfig. Including df, arch, bunzip2, gunzip, bzcat, zcat. My .config file is on Gist for comparison, if anybody wants to use fuller toybox on Mac.

[enh-google]

i suspect that's because you didn't make clean and your bad sed left things in a bad state? it's working fine for me.

i don't see any nproc error if i build on 10.15 with the regular linux defconfig; just the expected build failures from linux-specific tools. can you reproduce the error and include it here?

[enh-google]

(also note that while you can build df on macos, it doesn't list all the file systems.)

[amakukha]

@enh-google , you might be right, thank you.

But to confirm your idea I wrote a script:

#!/bin/bash

#Compile toybox
git clone https://github.com/landley/toybox
cd toybox
make defconfig
cp ~/.config.macos .config
make
./toybox help bunzip2

#Remove toybox
cd ..
rm -rf toybox/

It did work first four times without any issues. Fifth time, however, it produced this error:

generated/flags.h generated/globals.h generated/tags.h generated/help.h
scripts/make.sh: line 267: 36786 Segmentation fault: 11 generated/config2help Config.in $KCONFIG_CONFIG > generated/help.h
make: *** [toybox] Error 1

It might be the problem that I got previously, before adding CPUS=1 into scripts/make.sh.

I ran this Bash script six more times. Sixth time I got the same error.

So, for me it fails to compile roughly 15-20% of the time.

[landley]

Wait, config2help segfaulted? It shouldn't...

This was on mac?

[amakukha]

@landley , yes. This is the command that fails:

generated/config2help Config.in .config

Yes, I am using Mac.

When I go and run config2help 1000 times separately:

c=0; for i in {1..1000}; do generated/config2help Config.in .config > /dev/null; if [ $? -ne 0 ]; then c=$((c+1)); echo "ERROR! $c/$i"; fi; done

– it segfaults 22–34% of the time. Which is consistent with my previous observation that building toybox on my machine fails roughly every fifth time on average.

(Also, CPUS=1 is actually not a remedy.)

[enh-google]

if you're wondering "why haven't we seen this in asan builds?"...

it's because the config2help build doesn't use $CFLAGS, so it doesn't get the ASan flags. i've sent a patch to enable asan for the host binaries too to the mailing list. (i've also sent a fix for the trivial mkflags bug it finds.)

with ASan, this config2help crash is a 100% reproducible use-after-free on Linux:

=================================================================
==124747==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030000018b0 at pc 0x558b3005ad4e bp 0x7ffe7fd9b3f0 sp 0x7ffe7fd9b3e8
READ of size 8 at 0x6030000018b0 thread T0
    #0 0x558b3005ad4d in main scripts/config2help.c:496
    #1 0x7f5c2761abba in __libc_start_main ../csu/libc-start.c:308
    #2 0x558b300582c9 in _start (/tmp/toybox/generated/config2help+0x22c9)

0x6030000018b0 is located 16 bytes inside of 24-byte region [0x6030000018a0,0x6030000018b8)
freed by thread T0 here:
    #0 0x7f5c278bb187 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x107187)
    #1 0x558b30058a94 in dlist_zap scripts/config2help.c:149
    #2 0x558b3005a605 in main scripts/config2help.c:432
    #3 0x7f5c2761abba in __libc_start_main ../csu/libc-start.c:308

previously allocated by thread T0 here:
    #0 0x7f5c278bb538 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x107538)
    #1 0x558b30058433 in xmalloc scripts/config2help.c:32
    #2 0x558b300588b3 in dlist_add scripts/config2help.c:102
    #3 0x558b30059397 in parse scripts/config2help.c:262
    #4 0x558b3005937d in parse scripts/config2help.c:255
    #5 0x558b30059762 in main scripts/config2help.c:314
    #6 0x7f5c2761abba in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-use-after-free scripts/config2help.c:496 in main
Shadow bytes around the buggy address:
  0x0c067fff82c0: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
  0x0c067fff82d0: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
  0x0c067fff82e0: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
  0x0c067fff82f0: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
  0x0c067fff8300: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
=>0x0c067fff8310: fd fa fa fa fd fd[fd]fa fa fa fd fd fd fa fa fa
  0x0c067fff8320: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
  0x0c067fff8330: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
  0x0c067fff8340: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
  0x0c067fff8350: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x0c067fff8360: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==124747==ABORTING
make: *** [Makefile:19: toybox] Error 1

[landley]

Ok, allocated in parse(), freed on line 432 (marshalling data between lists) then used on 496. The marshalling data between lists is freeing the list wrapper structure but not the string, so something is still pointing to the old wrapper structure and didn't get updated for the new list? But dlist_zap() calls dlist_pop() which should adjust the list, is ->help pointing to an old list head? (In which case it should output noticeably wrong data? And this implies it's an entry with no usage: line it's generating help text for?)

Hmmm, I inserted a memset(dd, 0xaa, sizeof(struct double_list)); at line 149 right before the free() and "make defconfig" still isn't breaking for me on Linux? (If it follows any of those pointers after the memset it should segfault. I tried "make macos_defconfig" and ran "make clean && make" five times to be sure, then did your 1000 calls loop and still didn't hit it.)

[landley]

No, grab_dashlines() uses a double_list ** and passes it to zap_blank_lines() which passes it to dlist_zap() which passes it to dlist_pop() meaning if ->help needs to be adjusted it should be adjusted. How is this pointing to an old list entry?

I've reproduced the asan complaint with the android ndk, but I don't understand how it's supposed to actually happen in the code, and I have yet to make it happen by poisoning the freed memory? Hmmm...

[enh-google]

poisoning works for me. this is a 100% reproducible SIGSEGV crash on Linux without ASan:

diff --git a/scripts/config2help.c b/scripts/config2help.c
index 0eff7087..c141a2bc 100644
--- a/scripts/config2help.c
+++ b/scripts/config2help.c
@@ -146,7 +146,8 @@ char *dlist_zap(struct double_list **help)
   struct double_list *dd = dlist_pop(help);
   char *s = dd->data;
 
-  free(dd);
+  dd->data = 0;
+  //free(dd);
   
   return s;
 }

(but i can't see the bug either.)

[landley]

Sigh, did gcc "optimize out" the memset if I didn't remove the free()? (Is there a way to get it to STOP DOING THAT? -fdowhatIsaynotwhatyouthinkImean)

[jmakip]

#103

does this ticket relate to this?

[landley]

Did 16c0ba5 fix it? (Well, work around. I should do a proper fix, but that's what was triggering it.)

[landley]

After a month on no reply to whether the previous commit worked around it, I'm assuming it did closing this.

[enh-google]

(i can confirm that with the workaround i no longer see this on Linux with ASAN=1 or on macOS.)