Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Quoting Alexandre Rossi (2020-06-08 20:15:32) > > > > Sorry, I was too fast - indeed we don't do the above (we do not > > > > probe for and tie to a specific package version) - but I am > > > > confused: why is it not reliable to use the provided ABI? > > > > > > The uwsgi-plugin-php is a sort of special case, as the > > > phpapi- can be resolved with any SAPI (CLI, CGI, apache2, > > > FCGI) and you need to depend on a specific SAPI. > > > > > > Or just wait for php-default 76 to migrate as that solves the > > > problem > > Then do we depend on libphp7.4-embed (my patch) or do we let the > problem solve itself when php-default migrates? Should I revert my > proposed fix? Oh sorry, I missed your fix - looks good to me! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Maybe keep the patch until the PHP-defaults migrates and then you can drop it? The migration is getting stuck on various different autopkgtests, so I actually don’t know why it hasn’t migrated yet. Ondrej On Mon, 8 Jun 2020 at 20:18, Alexandre Rossi wrote: > Hi, > > > > > Sorry, I was too fast - indeed we don't do the above (we do not > > > > probe for and tie to a specific package version) - but I am > > > > confused: why is it not reliable to use the provided ABI? > > > > > > The uwsgi-plugin-php is a sort of special case, as the phpapi- > > > can be resolved with any SAPI (CLI, CGI, apache2, FCGI) and you need > > > to depend on a specific SAPI. > > > > > > Or just wait for php-default 76 to migrate as that solves the problem > > Then do we depend on libphp7.4-embed (my patch) or do we let the problem > solve itself when php-default migrates? Should I revert my proposed fix? > > Thanks, > > Alex > > -- -- Ondřej Surý
Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Hi, > > > Sorry, I was too fast - indeed we don't do the above (we do not > > > probe for and tie to a specific package version) - but I am > > > confused: why is it not reliable to use the provided ABI? > > > > The uwsgi-plugin-php is a sort of special case, as the phpapi- > > can be resolved with any SAPI (CLI, CGI, apache2, FCGI) and you need > > to depend on a specific SAPI. > > > > Or just wait for php-default 76 to migrate as that solves the problem Then do we depend on libphp7.4-embed (my patch) or do we let the problem solve itself when php-default migrates? Should I revert my proposed fix? Thanks, Alex
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Quoting Ondřej Surý (2020-06-05 17:13:00) > On 5 Jun 2020, at 17:06, Jonas Smedegaard wrote: > > Sorry, I was too fast - indeed we don't do the above (we do not > > probe for and tie to a specific package version) - but I am > > confused: why is it not reliable to use the provided ABI? > > The uwsgi-plugin-php is a sort of special case, as the phpapi- > can be resolved with any SAPI (CLI, CGI, apache2, FCGI) and you need > to depend on a specific SAPI. > > Or just wait for php-default 76 to migrate as that solves the problem > with allowing multiple PHP versions to be installed, so if you depend > on libphp-embed, it will pull php-common and that version has: > > Breaks: […] > php5.6-common, > php5.6-common (<< 5.6.18+dfsg-10~), > php5.6-json (<< 1.3.9-2~), > php7.0-common, > php7.0-common (<< 7.0.3-11~), > php7.1-common, > php7.2-common, > php7.3-common > > So, it ensures that only PHP 7.4 can be installed. Thanks for clarifying (I vaguely recall having this kind of conversation before, but maybe not with you specifically). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
> On 5 Jun 2020, at 17:06, Jonas Smedegaard wrote: > > Sorry, I was too fast - indeed we don't do the above (we do not probe > for and tie to a specific package version) - but I am confused: why is > it not reliable to use the provided ABI? The uwsgi-plugin-php is a sort of special case, as the phpapi- can be resolved with any SAPI (CLI, CGI, apache2, FCGI) and you need to depend on a specific SAPI. Or just wait for php-default 76 to migrate as that solves the problem with allowing multiple PHP versions to be installed, so if you depend on libphp-embed, it will pull php-common and that version has: Breaks: […] php5.6-common, php5.6-common (<< 5.6.18+dfsg-10~), php5.6-json (<< 1.3.9-2~), php7.0-common, php7.0-common (<< 7.0.3-11~), php7.1-common, php7.2-common, php7.3-common So, it ensures that only PHP 7.4 can be installed. Ondrej -- Ondřej Surý ond...@sury.org signature.asc Description: Message signed with OpenPGP
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
[ sent again, 2 mails merged with 7bit headers to please Debian MTAs ]
Hi Ondřej,
Quoting Ondřej Surý (2020-06-05 16:20:21)
> Hi Alex,
>
> you can depend on libphp-embed and then prepare the substvars like this:
>
> echo "libphp-embed:Depends=libphp$(phpquery -V | head -1)-embed“ >
> debian/uwsgi-plugin-php.substvars
>
> and then in debian/control you would use
>
> Depends: ${libphp-embed:Depends}
>
> instead of
>
> Depends: libphp-embed
We (Alex and I) believe that we do similar to the above: Binary package
uwsgi-plugin-php currently in unstable depends on virtual package
phpapi-20190902 which (if I understand correctly) is equivalent of using
above method.
Why is it not reliable to use the provided ABI?
Can we ask you to please look at the package uwsgi-plugin-php and tell
what we do wrong (or tell us if you agree that what we do already is
indeed supposed to be adequate)
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Hi Alex,
you can depend on libphp-embed and then prepare the substvars like this:
echo "libphp-embed:Depends=libphp$(phpquery -V | head -1)-embed“ >
debian/uwsgi-plugin-php.substvars
and then in debian/control you would use
Depends: ${libphp-embed:Depends}
instead of
Depends: libphp-embed
Alternatively
You can of course walk through the full list returned by phpquery -V and build
a separate version
of the plugin for each available PHP version, but you would still have to
prepare the substvars.
Cheers,
Ondrej
--
Ondřej Surý
ond...@sury.org
> On 5 Jun 2020, at 16:02, Alexandre Rossi wrote:
>
>>> I do not have much experience with shared object libraries, but as
>>> libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could
>>> not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so :
>>> passing -lphp7.4 to the linker still goes back to linking to libphp7.so .
>>
>> Don't we already do that by depending on PHP ABI?
>>
>> If phpapi-20190902 is provided by multiple binary incompatible package
>> releases, then it seems to me that there is a bug in PHP packaging!
>>
>> If you agree (i.e. if I haven't again misunderstood the issue) then I
>> think this bug should be reassigned to src:php7.4 as we already follow
>> their mechanism for locking in on a specific ABI.
>
> I agree:
> - uwsgi-plugin-php depends on libphp-embed, phpapi-20190902
> - in bullseye, libphp-embed pulls libphp7.3-embed and phpapi-20190902
> pulls php7.4-cli
> - libphp7.so point to libphp7.3.so
> - uwsgi-plugin-php (built against 7.4) segfaults...
>
> I could not find any way to express that uwsgi-plugin-php depends
> on libphp7.4.so and not libphp7.3-embed, other than depending on
> libphp7.4-embed explicitely.
>
> What do the php folks think?
>
> Alex
>
signature.asc
Description: Message signed with OpenPGP
Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
> > I do not have much experience with shared object libraries, but as > > libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could > > not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so : > > passing -lphp7.4 to the linker still goes back to linking to libphp7.so . > > Don't we already do that by depending on PHP ABI? > > If phpapi-20190902 is provided by multiple binary incompatible package > releases, then it seems to me that there is a bug in PHP packaging! > > If you agree (i.e. if I haven't again misunderstood the issue) then I > think this bug should be reassigned to src:php7.4 as we already follow > their mechanism for locking in on a specific ABI. I agree: - uwsgi-plugin-php depends on libphp-embed, phpapi-20190902 - in bullseye, libphp-embed pulls libphp7.3-embed and phpapi-20190902 pulls php7.4-cli - libphp7.so point to libphp7.3.so - uwsgi-plugin-php (built against 7.4) segfaults... I could not find any way to express that uwsgi-plugin-php depends on libphp7.4.so and not libphp7.3-embed, other than depending on libphp7.4-embed explicitely. What do the php folks think? Alex
Bug#962186: [pkg-uWSGI-devel] Bug#962186: Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Quoting Alexandre Rossi (2020-06-05 12:24:12) > > > The problem seems to be that the PHP plugin is compiled against PHP7.4 > > > and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in > > > sid. > > > > > > $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php > > > libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000) > > > $ ls -l /usr/lib/libphp7.so > > > lrwxrwxrwx 1 root root 25 mai 11 19:41 /usr/lib/libphp7.so -> > > > /etc/alternatives/libphp7 > > > $ ls -l /etc/alternatives/libphp7 > > > lrwxrwxrwx 1 root root 21 mai 11 19:41 /etc/alternatives/libphp7 -> > > > /usr/lib/libphp7.4.so > > > > > > The php plugin should explicitly be linked against /usr/lib/libphp7.4.so > > > > It seems uwsgi gets its information for which library to link against > > from /usr/bin/php-config (see /usr/src/uwsgi/plugins/php/uwsgiplugin.py). > > > > And it seems php-dev and php4.7-dev ships php-config* tools that (I guess) > > both provides that name using the dpkg alternatives systems. > > > > Try check if those varying build tools offer different build hints, > > and if they do then try comeup with a patch for plugins/php/uwsgiplugin.py > > to use php-config only by default, overridable by an environment variable. > > I do not have much experience with shared object libraries, but as > libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could > not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so : > passing -lphp7.4 to the linker still goes back to linking to libphp7.so . Ah, sorry - seems I misunderstood the issue. > The only solution I found is to explicitely depend[1] on > libphp7.4-embed in the dependencies. Don't we already do that by depending on PHP ABI? If phpapi-20190902 is provided by multiple binary incompatible package releases, then it seems to me that there is a bug in PHP packaging! If you agree (i.e. if I haven't again misunderstood the issue) then I think this bug should be reassigned to src:php7.4 as we already follow their mechanism for locking in on a specific ABI. > While debugging this, I found it usefull to have the uwsgi build system do > verbose[2] builds. > > [1] > https://salsa.debian.org/uwsgi-team/uwsgi-plugin-php/-/commit/d031916dfe72cca4831c4eb2efcb2db3058e8533 > [2] > https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/7ba0a0b19818e1e886924fb9227be32e4e0af6f9 Thanks! Packaging builds should indeed be verbose by default. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
> > The problem seems to be that the PHP plugin is compiled against PHP7.4 > > and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid. > > > > $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php > > libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000) > > $ ls -l /usr/lib/libphp7.so > > lrwxrwxrwx 1 root root 25 mai 11 19:41 /usr/lib/libphp7.so -> > > /etc/alternatives/libphp7 > > $ ls -l /etc/alternatives/libphp7 > > lrwxrwxrwx 1 root root 21 mai 11 19:41 /etc/alternatives/libphp7 -> > > /usr/lib/libphp7.4.so > > > > The php plugin should explicitly be linked against /usr/lib/libphp7.4.so > > It seems uwsgi gets its information for which library to link against > from /usr/bin/php-config (see /usr/src/uwsgi/plugins/php/uwsgiplugin.py). > > And it seems php-dev and php4.7-dev ships php-config* tools that (I guess) > both provides that name using the dpkg alternatives systems. > > Try check if those varying build tools offer different build hints, > and if they do then try comeup with a patch for plugins/php/uwsgiplugin.py > to use php-config only by default, overridable by an environment variable. I do not have much experience with shared object libraries, but as libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so : passing -lphp7.4 to the linker still goes back to linking to libphp7.so . The only solution I found is to explicitely depend[1] on libphp7.4-embed in the dependencies. I tested in a bullseye chroot and it works. Actually, libphp7.3.so and libphp7.4.so cannot be installed at the same time: # apt install libphp7.4-embed [...] # apt install libphp7.3-embed Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: php-common : Breaks: php7.3-common but 7.3.15-3 is to be installed While debugging this, I found it usefull to have the uwsgi build system do verbose[2] builds. [1] https://salsa.debian.org/uwsgi-team/uwsgi-plugin-php/-/commit/d031916dfe72cca4831c4eb2efcb2db3058e8533 [2] https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/7ba0a0b19818e1e886924fb9227be32e4e0af6f9 Thanks, Alex
Bug#962186: [pkg-uWSGI-devel] Bug#962186: Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Quoting Alexandre Rossi (2020-06-04 16:08:26) > The problem seems to be that the PHP plugin is compiled against PHP7.4 > and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid. > > $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php > libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000) > $ ls -l /usr/lib/libphp7.so > lrwxrwxrwx 1 root root 25 mai 11 19:41 /usr/lib/libphp7.so -> > /etc/alternatives/libphp7 > $ ls -l /etc/alternatives/libphp7 > lrwxrwxrwx 1 root root 21 mai 11 19:41 /etc/alternatives/libphp7 -> > /usr/lib/libphp7.4.so > > The php plugin should explicitly be linked against /usr/lib/libphp7.4.so It seems uwsgi gets its information for which library to link against from /usr/bin/php-config (see /usr/src/uwsgi/plugins/php/uwsgiplugin.py). And it seems php-dev and php4.7-dev ships php-config* tools that (I guess) both provides that name using the dpkg alternatives systems. Try check if those varying build tools offer different build hints, and if they do then try comeup with a patch for plugins/php/uwsgiplugin.py to use php-config only by default, overridable by an environment variable. If those picking the right build tool doesn't solve this, then try come up with some other patch taking some other more direct environment variable into account (look at other plugins and try mimic upstream style, so that hopefully your patch can be adopted upstream). Then we can have uwsgi-plugin-php pass a suitable environment variable resolved at build time from the package pulled in by its build-dependency on virtual package "php-dev". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
The problem seems to be that the PHP plugin is compiled against PHP7.4 and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid. $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000) $ ls -l /usr/lib/libphp7.so lrwxrwxrwx 1 root root 25 mai 11 19:41 /usr/lib/libphp7.so -> /etc/alternatives/libphp7 $ ls -l /etc/alternatives/libphp7 lrwxrwxrwx 1 root root 21 mai 11 19:41 /etc/alternatives/libphp7 -> /usr/lib/libphp7.4.so The php plugin should explicitly be linked against /usr/lib/libphp7.4.so
Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Package: uwsgi-plugin-php Version: 2.0.18+20200523+1+0.0.8 Severity: normal Hi, CI fails in bullseye. The relevant part of the log[1] is: !!! uWSGI process 13224 got Segmentation Fault !!! *** backtrace of 13224 *** uwsgi(uwsgi_backtrace+0x2a) [0x55f6838d06aa] uwsgi(uwsgi_segfault+0x23) [0x55f6838d0a93] /lib/x86_64-linux-gnu/libc.so.6(+0x3b800) [0x7f94b286c800] /lib/x86_64-linux-gnu/libc.so.6(+0x15e711) [0x7f94b298f711] /lib/libphp7.so(virtual_chdir_file+0x31) [0x7f94b086bd41] /lib/libphp7.so(php_execute_script+0xf5) [0x7f94b07e18d5] /usr/lib/uwsgi/plugins/php_plugin.so(uwsgi_php_request+0xbd3) [0x7f94b0a365b3] uwsgi(wsgi_req_recv+0xad) [0x55f68388105d] uwsgi(simple_loop_run+0xc4) [0x55f6838cc424] uwsgi(simple_loop+0x10) [0x55f6838cc200] uwsgi(uwsgi_ignition+0x294) [0x55f6838d0de4] uwsgi(uwsgi_worker_run+0x266) [0x55f6838d4266] uwsgi(uwsgi_run+0x454) [0x55f6838d47e4] uwsgi(+0x2b68e) [0x55f68388068e] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f94b2857e0b] uwsgi(_start+0x2a) [0x55f6838806ba] *** end of backtrace *** There's something strange as CI pulls both php7.3 and php7.4 in testing... I'll look into it. Alex [1] https://ci.debian.net/data/autopkgtest/testing/amd64/u/uwsgi-plugin-php/57 52337/log.gz -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages uwsgi-plugin-php depends on: ii libapache2-mod-php7.4 [phpapi-20190902] 7.4.5-1+b1 ii libc62.30-8 ii libphp-embed 2:7.4+76 ii libphp7.4-embed [phpapi-20190902]7.4.5-1+b1 ii php7.4-cli [phpapi-20190902] 7.4.5-1+b1 ii uwsgi-core [uwsgi-abi-f79eb498cf60eb651fe70ba0b3678ffa] 2.0.18+20200523-1 uwsgi-plugin-php recommends no packages. uwsgi-plugin-php suggests no packages. -- no debconf information
