[pkg-uWSGI-devel] Bug#900174: uwsgi: Segmentation fault with searx and even simple python3 application

[Johannes 'josch' Schauer]

Package: uwsgi
Version: 2.0.15-10.4
Severity: normal

Control: affects -1 + searx

Hi,

this might not even be a uwsgi bug, but filing it here anyways, because
it leads to a segmentation fault in uwsgi (and no logs being written)
which shouldn't happen.

I found this bug when #900068 was filed against my package src:searx.
Searx uses uwsgi to run and because of this issue, its autopkgtest
doesn't complete anymore since the end of April:

https://ci.debian.net/packages/s/searx/unstable/amd64/

I'm also able to reproduce this bug without searx, though. Steps to
reproduce:

    $ sudo debootstrap sid debian-sid http://snapshot.debian.org/archive/debian/20180424T000000Z
    $ sudo chroot debian-sid passwd
    $ sudo systemd-nspawn -bD ~/debian-sid

login with root and chosen password and then:

    # apt install uwsgi uwsgi-plugin-python3 nginx
    # cat > /var/www/hello.py << END
def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    return [b"Hello World"]
END
    # cat > /etc/uwsgi/apps-enabled/hello.ini << END
[uwsgi]
uid = www-data
gid = www-data
chdir = /var/www
module = python3
master = true
END
    # systemctl restart uwsgi
    # systemctl status uwsgi

Convince yourself that everything works just fine. Now upgrade the
system to some new package versions of six days later:

    # echo 'deb http://snapshot.debian.org/archive/debian/20180430T000000Z sid main' > /etc/apt/sources.list
    # apt update -o Acquire::Check-Valid-Until=false
    # apt upgrade -o Acquire::Check-Valid-Until=false

The following packages will be upgraded:

file gcc-8-base ifupdown libargon2-0 libaudit-common libaudit1
libcap-ng0 libgcc1 liblognorm5 libmagic-mgc libmagic1 libncurses5
libncursesw5 libnorm1 libreadline7 libseccomp2 libstdc++6 libtinfo5
libzstd1 ncurses-base ncurses-bin perl-base vim-common vim-tiny xxd
zlib1g

After this upgrade, try restarting uwsgi and witness that it now fails
to start:

    # systemctl restart uwsgi
    # systemctl status uwsgi
● uwsgi.service - LSB: Start/stop uWSGI server instance(s)
   Loaded: loaded (/etc/init.d/uwsgi; generated)
   Active: failed (Result: exit-code) since Sun 2018-05-27 06:59:20 CEST; 10min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 38 ExecStart=/etc/init.d/uwsgi start (code=exited, status=1/FAILURE)

May 27 06:59:17 hoothoot systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)...
May 27 06:59:20 hoothoot uwsgi[38]: Starting app server(s): uwsgi -> ! failed!
May 27 06:59:20 hoothoot systemd[1]: uwsgi.service: Control process exited, code=exited status=1
May 27 06:59:20 hoothoot systemd[1]: uwsgi.service: Failed with result 'exit-code'.
May 27 06:59:20 hoothoot systemd[1]: Failed to start LSB: Start/stop uWSGI server instance(s).

The root cause for this might be a segmentation fault. Try running the
following which (I hope) correctly simulates what the init.d script
does:

    # UWSGI_DEB_CONFNAME=hello UWSGI_DEB_CONFNAMESPACE=app uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/hello.ini
[...]
Sun May 27 07:10:47 2018 - spawned uWSGI worker 1 (pid: 282, cores: 1)
Sun May 27 07:10:47 2018 - !!! uWSGI process 282 got Segmentation Fault !!!
Sun May 27 07:10:47 2018 - spawned uWSGI worker 2 (pid: 283, cores: 1)
Sun May 27 07:10:47 2018 - !!! uWSGI process 283 got Segmentation Fault !!!
[...]

Funnily, these segmentation faults also occur when only using
default.ini:

    # UWSGI_DEB_CONFNAME=hello UWSGI_DEB_CONFNAMESPACE=app uwsgi --ini /usr/share/uwsgi/conf/default.ini

I'm at a loss at how to debug this problem further.

Thanks!

cheers, josch