Comment # 8 on bug 1206780 from Benjamin Zeller

(In reply to Martin Wilck from comment #6)
> Trying to run qemu-aarch64 with debug options:
> 
> > > podman run -v /usr/bin/qemu-aarch64:/usr/bin/qemu-aarch64 -v /tmp:/tmp --arch arm64 -it --rm registry.opensuse.org/opensuse/tumbleweed:latest
> > :/ # /usr/bin/qemu-aarch64 -d int,strace,tid -D /tmp/z%d.str /usr/bin/zypper --verbose ref

Thanks I will try that locally too!

> 
> There are two alive threads when the SEGV occurs. One (123) is calling
> ppoll(), read(), and write(), the other one (120, main thread) is doing more
> work.

Yes, one of the threads that does the poll is the log thread, waiting for new
log lines on a unix domain socket where the main ( and possibly other
threads/subprocesses ) can write into.

> The main thread opens a geoip-related file and sends several pieces of data
> to the other thread, which receives them (118, 125, and 102 bytes,
> respectively), forwards them to another fd (10) and triggers an eventfd (fd
> 7).

The segfault is not related to the geoip file, even running
> zypper --version
will show a segfault

> 
> The main thread receives SIGSEGV twice (??). The first time while the main
> thread has called futex() and the other thread ppoll().

I was trying to figure out where the futex() call comes from, judging from the
log file of the zypper --version call I currently suspect it is triggered by
throwing a exception, since the C++ throw (at least on x86) uses a futex call
and it crashes right after that. 

> 
> The futex() call is probably the most likely candidate for causing the issue.
> Loooking at the futex() calls made by the main thread, it appears that the
> first argument (futex address) is always distinct. Not sure why these futex
> calls happen at all.

I'm not sure this is issue, as previously mentioned throw() uses a futex, so
every time zypp throws or rethrows a exception you probably will see one of
those. Also there are other stdlib functions / syscalls that use it, setlocale
for example.