>
>
>
> OK, then in that case it's surely Docker's seccomp filters that are
> the problem. I think --security-opt seccomp=unconfined is the part you
> need to work around it.

 That's the command line I was using, which leads to the application NOT
breaking, and thus doesn't allow me to replicate the problem:
 docker run --security-opt seccomp=unconfined  --platform linux/386
--cap-add SYS_PTRACE --rm -v $(pwd)/pkg_cache:/usr/local/tmp/packages -v
$(pwd):/output -h $(hostname)-i686 -it satmandu/crewbuild:alex-i686.m58
/usr/local/bin/setarch i686 sudo -i -u chronos /usr/local/bin/bash -i

The goal with docker was to try to replicate the breakage on the actual
hardware, which is the place we are having this problem.

I ran the process through gdb on the hardware, and stepped through it with
the timeit function from here: https://stackoverflow.com/a/48412363

Of note perhaps is the very long time it takes for some of these calls to
return in gdb? (The program does run in gdb when stepping through the
function, but not when run without the break point)
my commands were in essence the following in gdb:
add symbol table from file "/usr/local/share/musl/lib/libc.so"
break main
run google.com 2>>gdb.out.txt
ti (repeated until the program exited)
(I ran this twice, and both runs succeed with long delays)
Then I ran (this, which fails):
clear main
run google.com 2>>gdb.out.txt

Any other suggestions on how to track down this issue?

Regards,

Satadru