[arch-general] uwsgi-2.0.14-15 segfaults with php plugin

[Damjan Georgievski]

https://bugs.archlinux.org/task/52406

the packager is a bit irresponsible

On 17 January 2017 at 17:14, David Runge <dave at sleepmap.de> wrote:
> Hey all,
>
> ran into the issue, that after updating from uwsgi 2.0.14-1 to uwsgi
> 2.0.14-5 (php plugin of the same version), all php based webapps make
> uwsgi segfault (tested with wordpress and stikked)!
>
> Something like the below will happen (including after reboot):
>
> Jan 17 16:24:20 frqrec systemd[1]: Starting uWSGI service unit...
> Jan 17 16:24:20 frqrec uwsgi[2370]: [uWSGI] getting INI configuration
> from /etc/uwsgi/wordpress.ini
> Jan 17 16:24:20 frqrec uwsgi[2370]: *** Starting uWSGI 2.0.14 (64bit) on
> [Tue Jan 17 16:24:20 2017] ***
> Jan 17 16:24:20 frqrec uwsgi[2370]: compiled with version: 6.3.1
> 20170109 on 10 January 2017 00:34:54
> Jan 17 16:24:20 frqrec uwsgi[2370]: os: Linux-4.8.13-1-ARCH #1 SMP
> PREEMPT Fri Dec 9 07:24:34 CET 2016
> Jan 17 16:24:20 frqrec uwsgi[2370]: nodename: frqrec
> Jan 17 16:24:20 frqrec uwsgi[2370]: machine: x86_64
> Jan 17 16:24:20 frqrec uwsgi[2370]: clock source: unix
> Jan 17 16:24:20 frqrec uwsgi[2370]: pcre jit disabled
> Jan 17 16:24:20 frqrec uwsgi[2370]: detected number of CPU cores: 2
> Jan 17 16:24:20 frqrec uwsgi[2370]: current working directory: /
> Jan 17 16:24:20 frqrec uwsgi[2370]: detected binary path: /usr/bin/uwsgi
> Jan 17 16:24:20 frqrec uwsgi[2370]: setgid() to 33
> Jan 17 16:24:20 frqrec uwsgi[2370]: setuid() to 33
> Jan 17 16:24:20 frqrec uwsgi[2370]: your processes number limit is 15780
> Jan 17 16:24:20 frqrec uwsgi[2370]: your memory page size is 4096 bytes
> Jan 17 16:24:20 frqrec uwsgi[2370]: detected max file descriptor number:
> 1024
> Jan 17 16:24:20 frqrec uwsgi[2370]: lock engine: pthread robust mutexes
> Jan 17 16:24:20 frqrec uwsgi[2370]: thunder lock: disabled (you can
> enable it with --thunder-lock)
> Jan 17 16:24:20 frqrec uwsgi[2370]: *** Cache "wordpress" initialized:
> 64MB (key: 2136 bytes, keys: 2136000 bytes, data: 65536000 bytes,
> bitmap: 0 bytes) preallocated ***
> Jan 17 16:24:20 frqrec uwsgi[2370]: - SystemD socket activation detected
> -
> Jan 17 16:24:20 frqrec uwsgi[2370]: uwsgi socket 1 attached to UNIX
> address /run/uwsgi/wordpress.sock fd 3
> Jan 17 16:24:20 frqrec uwsgi[2370]: !!! uWSGI process 2370 got
> Segmentation Fault !!!
> Jan 17 16:24:20 frqrec uwsgi[2370]: *** backtrace of 2370 ***
> Jan 17 16:24:20 frqrec uwsgi[2370]: /usr/bin/uwsgi(uwsgi_backtrace+0x2c)
> [0x466eec]
> Jan 17 16:24:20 frqrec uwsgi[2370]: /usr/bin/uwsgi(uwsgi_segfault+0x21)
> [0x4672b1]
> Jan 17 16:24:20 frqrec uwsgi[2370]: /usr/lib/libc.so.6(+0x330b0)
> [0x7f9a019ea0b0]
> Jan 17 16:24:20 frqrec uwsgi[2370]:
> /usr/lib/uwsgi/php_plugin.so(+0x53ca) [0x7f9a001fa3ca]
> Jan 17 16:24:20 frqrec uwsgi[2370]: *** end of backtrace ***
> Jan 17 16:24:20 frqrec systemd[1]: uwsgi-private at wordpress.service: Main
> process exited, code=exited, status=1/FAILURE
> Jan 17 16:24:20 frqrec systemd[1]: Failed to start uWSGI service unit.
> Jan 17 16:24:20 frqrec systemd[1]: uwsgi-private at wordpress.service: Unit
> entered failed state.
> Jan 17 16:24:20 frqrec systemd[1]: uwsgi-private at wordpress.service:
> Failed with result 'exit-code'.
>
> Reverting back to uwsgi 2.0.14-1 fixes the problem (after restarting the
> socket, that activates the webapp).
>
> As a sidenote: I'm using the hardening and socket activation options as
> explained here, which shouldn't have much of an effect on the uwsgi
> itself though):
> https://wiki.archlinux.org/index.php/UWSGI#Socket_activation
> https://wiki.archlinux.org/index.php/UWSGI#Hardening_uWSGI
>
> Has anyone had the same issue?
> I can't seem to find out, what has changed between revision 1 and 5 or
> if it needs another rebuild.
>
> Best,
> David
>
>
> --
> https://sleepmap.de



-- 
damjan