[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Feb 2022 17:56:53 -0500
From: Satadru Pramanik <satadru@...il.com>
To: Rich Felker <dalias@...ifal.cx>
Cc: musl@...ts.openwall.com
Subject: Re: Re: musl getaddr info breakage on older kernels
>
>
>
> 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
Content of type "text/html" skipped
View attachment "gdb.out.txt" of type "text/plain" (5489 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
