# apache24 with mod_php82 won't start up.



## kazuya.fukushima (Oct 16, 2022)

Could you anyone help me to solve the following probleｍ.
I've installed apache24 and mod_php82. But apache won't start up at all.
I show you general idea of my FreeBSD machine as follows.


```
# uname -a
FreeBSD sun.ptld.net 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC i386

# pkg info |grep apache24
apache24-2.4.54                Version 2.4.x of Apache web server

# pkg info | grep mod_php82
mod_php82-8.2.0.r4_1           PHP Scripting Language (8.2.X branch)

root@sun:/usr/local/etc/apache24 # cat httpd.conf | grep "php_module"
LoadModule php_module         libexec/apache24/libphp.so

root@sun:/usr/local/etc/rc.d # ./apache24 start
Performing sanity check on apache24 configuration:
Syntax OK
Starting apache24.

root@sun:/usr/local/etc/rc.d # tail -n 2 /var/log/messages
Oct 16 21:46:12 sun su[33894]: chris to root on /dev/pts/0
Oct 16 21:52:31 sun kernel: pid 33917 (httpd), jid 0, uid 0: exited on signal 11(core dumped)
```

When I remove(or make commented) the following line from the httpd.conf, apache will start up successfully.

```
LoadModule php_module         libexec/apache24/libphp.so
```

Is there anything I can submit to solve my problem?


----------



## Alain De Vos (Oct 18, 2022)

My mod_php version is,
mod_php80-8.0.24
Here apache starts fine.


----------



## Voltaire (Oct 18, 2022)

I'm using mod_php81 and that version works too with apache24. 

I don't think it is strange that php 8.2 gives problems:





						PHP: News Archive - 2022
					






					www.php.net
				




*Please DO NOT use this version in production, it is an early test version.*


----------



## kazuya.fukushima (Oct 19, 2022)

Alain and Voltaire, thank both of you for your replies.
I tested on both mod_php80 and mod_php81 in vain.
I began to think that this problem is something due to the hardware on my FreeBSD13.1.
For example, the followings are some of the hardware devices.
  1. CPU: the 12th generation CORE-i5 (i5-12400F, 18MB Cache, LGA1700)
  2. mother-board: ASUS PRIME H610M-A D4 (Intel H610 chipset)

I think that mod_php is working on the newwer version of the hardware while it thinks that it is working on older version of the hardware.
That's why core dump occurs.

I will report the result after I test apahce24 with mod_php82 on older version of hardware like the 11th generation CPU the suitable mother-board.


----------



## Voltaire (Oct 19, 2022)

I saw today that I am using mod_php80 and not mod_php81 but I think the latter will work too. 

You have a configuration file of the Apache server and I think you should mention mod_php in it correctly. It could be that your apache configuration file contains errors. Often when I can't get Apache to run it's because of a configuration error.


----------



## Voltaire (Oct 19, 2022)

Some things I see in the configuration file that seem important to me.
/usr/local/etc/apache24/httpd.conf

```
LoadModule php_module         libexec/apache24/libphp.so
LoadModule php7_module        libexec/apache24/libphp7.so

# Third party modules
IncludeOptional etc/apache24/modules.d/[0-9][0-9][0-9]_*.conf

<IfModule dir_module>
    DirectoryIndex index.php index.html
</IfModule>

 AddType application/x-httpd-php .php
    AddType application/x-httpd-php-source .phps
    <FilesMatch "\.php$">
    SetHandler application/x-httpd-php
    </FilesMatch>
    <FilesMatch "\.phps$">
    SetHandler application/x-httpd-php-source
    </FilesMatch>
</IfModule>

<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>

Include etc/apache24/Includes/*.conf
```

Anyway this configuration worked the last time I tried to use Adminer to manage PostgreSQL and MySQL databases.
It's not my complete httpd.conf but the things you may have done wrong.


----------



## SirDice (Oct 19, 2022)

Voltaire said:


> ```
> LoadModule php_module libexec/apache24/libphp.so
> LoadModule php7_module libexec/apache24/libphp7.so
> ```


Maybe you shouldn't try to load both mod_php74 and mod_php82?

Again an issue with having conflicting ports installed. It's not possible to have both www/mod_php74 _and_ www/mod_php82 installed.


----------



## Voltaire (Oct 19, 2022)

SirDice said:


> Maybe you shouldn't try to load both mod_php74 and mod_php82?
> 
> Again an issue with having conflicting ports installed. It's not possible to have both www/mod_php74 _and_ www/mod_php82 installed.


When I run the *pkg info* command I see that the following two packages are present on my system.

mod_php74-7.4.32_1            PHP Scripting Language
mod_php80-8.0.24               PHP Scripting Language

I'll check tonight which PHP version Apache is using with this configuration, but I'm sure Apache used to work correctly with this configuration.


----------



## SirDice (Oct 19, 2022)

Voltaire said:


> When I run the `pkg info` command I see that the following two packages are present on my system.
> 
> mod_php74-7.4.32_1 PHP Scripting Language
> mod_php80-8.0.24 PHP Scripting Language


This isn't possible unless you forcefully installed them. There's something seriously wrong with the way you install ports/packages. mod_php80 conflicts with mod_php74.


----------



## Voltaire (Oct 19, 2022)

SirDice said:


> This isn't possible unless you forcefully installed them. There's something seriously wrong with the way you install ports/packages. mod_php80 conflicts with mod_php74.


I don't have that many duplicate packages on my system with different versions. I think you got the wrong impression purely by chance because of the ldap problem. But we don't know why I had this ldap problem. 

I couldn't start Apache, and I thought it needed a different PHP version to work. Anyway, I was able to simply install it with *pkg install* xxx Shouldn't it throw an error if both packages can't coexist? For example with PostgreSQL it will also give an error if you have installed version 13 and then order to install another version.


----------



## SirDice (Oct 19, 2022)

Voltaire said:


> Shouldn't it throw an error if both packages can't coexist?


It should, yes. But apparently it doesn't. At least not for mod_phpXX. I distinctly remember this was certainly the case in the past. It does correctly detect the conflict for phpXX. 

```
Checking integrity... done (1 conflicting)
  - php80-8.0.24 conflicts with php74-7.4.32 on /usr/local/bin/php
```
A mod_phpXX without the accompanied phpXX is pretty useless. Having mod_php80 and php74 (or mod_php74 and php80) isn't going to work either.


----------



## Voltaire (Oct 19, 2022)

If I uncomment the *LoadModule php7_module libexec/apache24/libphp7.so* in /usr/local/etc/apache24/httpd.conf I get the following error message:


```
service apache24 onestart
Performing sanity check on apache24 configuration:
Syntax OK
Starting apache24.
Segmentation fault (core dumped)
/usr/local/etc/rc.d/apache24: WARNING: failed to start apache24
```

If I comment this line, Apache can start:


----------



## Alain De Vos (Oct 19, 2022)

Voltaire are you certain you have only one, and only one version of php ?
I.e. mod_phpXY & phpXY-... as packages installed ?


----------



## _martin (Oct 19, 2022)

While others are helping with the configuration part of the problem can you share the reason of the fault? For that you need to have `gdb` installed though. Run the following code `gdb /usr/local/sbin/httpd /path/to/corefile`. Then within gdb run the following command: `bt`. Once I have more time I'll try to reproduce this in my setup.

edit: apache24 and mod_php80 works just fine with me. So the dump is really needed to see what's going on there.


----------



## covacat (Oct 19, 2022)

SirDice said:


> A mod_phpXX without the accompanied phpXX is pretty useless.


why ?


----------



## SirDice (Oct 19, 2022)

As most, if not all, PHP applications depend on one or more modules. Those modules all depend on the phpXX port, nothing depends on mod_phpXX because you can run your PHP applications through PHP-FPM instead of mod_php.


----------



## Voltaire (Oct 20, 2022)

Alain De Vos said:


> Voltaire are you certain you have only one, and only one version of php ?
> I.e. mod_phpXY & phpXY-... as packages installed ?


When I run *pkg info* I can see that the following packages are installed:
php80-8.0.24 
mod_php74-7.4.32_1         
mod_php80-8.0.24 

So php has only one version installed but mod_php has two different versions installed, you know what I mean. However, I noticed something interesting in my test last night.


```
LoadModule php_module libexec/apache24/libphp.so
#LoadModule php7_module libexec/apache24/libphp7.so
```

With the above configuration, apache24 will start up successfully and you will see the php version you saw in the screenshot of my previous post.
But I can also configure it in the following way:

```
#LoadModule php_module libexec/apache24/libphp.so
LoadModule php7_module libexec/apache24/libphp7.so
```

In the above case, apache24 will also start up successfully. When I browse to localhost/info.php with this adapted configuration it says PHP Version 7.4.32 (instead of 8.0.24)
What I think is that SirDice has a lot more technical knowledge than I do. I can only describe what it looks like to me and not say for sure how it is. 

It seems for me that things may depend on mod_php74. (which contradicts SirDice). It also seems like you can install only php80-8.0.24 and mod_php74-7.4.32_1 and then you can use this mod_php74 in apache24 without any problems. 

The latter also seems interesting to the OP, that mod_php74 still seems to work fine.


----------



## Alain De Vos (Oct 20, 2022)

I think you best remove all packages mod_php74*.
Then you have a system only running php80 and normally that will work fine.


----------



## Voltaire (Oct 20, 2022)

Alain De Vos said:


> I think you best remove all packages mod_php74*.
> Then you have a system only running php80 and normally that will work fine.


PHP 7.4 will get security updates until November 28: https://kinsta.com/wp-content/uploads/2018/06/supported-php-versions-for-wordpress-1.png

In production you can only use it until that date.

For local use on a system that is not connected to the internet, I suspect that you can continue to use PHP 7.4 for a few more years without this being a problem.

I have uninstalled the mod_php74-7.4.32_1 package currently.

The best practice would probably be to use PHP 8.1 instead of PHP 8.0 for the following reason:
_A release that is being *actively* supported. *Reported bugs and security issues* are fixed and regular point releases are made._

PHP 8.0 is almost in the _Security fixes only_ phase:
_A release that is supported for *critical* security issues only. Releases are only made on an as-needed basis._


----------



## _martin (Oct 20, 2022)

You can have more versions of php running on a same web server. You can configure multiple vhosts running different php versions if required or desired. The ModuleIdentifier in LoadModule makes it possible to distinguish between these versions. 
Of course you can't have conflict and install both versions to the same location.

It would be interesting to see why the crash occurs assuming you have both modules and apache installed from binary packages.


----------



## veryfoot (Oct 23, 2022)

Hi, thanks for all your posts, because since a "`pkg update -y`", I have face exactly the same issue and couldn't find the problem.

My server is an old Inter Core2duo :  
> FreeBSD 13.1-RELEASE-p2 GENERIC i386

After this update, PHP, switch from 7.4.30 to 7.4.32. 
Before that everything was working perfectly.

Details :
Oct 22 00:59:36 HOST pkg[65952]: php74-sqlite3 upgraded: 7.4.30 -> 7.4.32
Oct 22 01:00:19 HOST pkg[65952]: php74-pdo_sqlite upgraded: 7.4.30 -> 7.4.32
Oct 22 01:02:31 HOST pkg[65952]: mod_php74 upgraded: 7.4.30 -> 7.4.32_1
.../...

The difference in my case is that I have only one version of PHP, witch is now after update :

Details :
`# pkg info | grep php`
- php74-7.4.32
- mod_php74-7.4.32_1
.../...

And a Nextcloud :
- nextcloud-php74-24.0.5

My Apache config looks like this :

# `cat /usr/local/etc/apache24/httpd.conf | grep php | grep so$`
LoadModule php7_module libexec/apache24/libphp7.so

So when this line is commented, Apache starts properly.

I tryed to "truss" the startup of Apache :
`truss -o Debug_apache3.txt -f -s 1000 /usr/local/etc/rc.d/apache24 start`

but no revelant info on it for my small knowledge.

I will try to rollback and re install the 7.4.30 and test again. I let you know the result.

Thanks again for your posts. I was becoming crazy !

Vince


----------



## _martin (Oct 23, 2022)

In the generic setup make sure you don't have conflict with the modules, i.e. you're not trying to install different versions of php from ports/binary packages. Your pkg output shows you don't have it, so it should be fine.
The best thing would be to show or share the core dump. That's the best way to determine what's happening.


----------



## veryfoot (Oct 23, 2022)

Thanks for you reply

Can you tell me how to make this verification ? (make sure you don't have conflict with the modules)

`httpd -M` ?

My `pkg info | grep php` only show on version.

No im not trying to install different versions of php. I would like to have my Cloud back online. Evrything was working perfectly before that pkg update.

Since the pkg update, Apache is no longer starting if this line is not commented in my httpd.conf :

LoadModule php7_module libexec/apache24/libphp7.so

I have try to switch to PHP8 by installing mod-php8, but im having the same issue when trying to start Apache.

Maybe it is a problem of my architecture who is under i386.... just guessing.

Here is the dump file generated under PHP7 and the truss output when lauching. 

Thanks for the help.


----------



## veryfoot (Oct 23, 2022)

Correction

My `pkg info | grep php` only show one version > php74 > 7.4.32


----------



## veryfoot (Oct 23, 2022)

It is a `pkg upgrade -y` and not a `pkg update`.... sorry for the mistake.


----------



## _martin (Oct 23, 2022)

Please share also `cksum /usr/local/sbin/httpd` so I know you have the same httpd version. I'll have a look later today.


----------



## veryfoot (Oct 23, 2022)

Thanks !


```
cksum /usr/local/sbin/httpd
1728080431 596412 /usr/local/sbin/httpd
```


```
pkg which /usr/local/sbin/httpd
/usr/local/sbin/httpd was installed by package apache24-2.4.54
```


```
pkg info apache24-2.4.54
apache24-2.4.54
Name           : apache24
Version        : 2.4.54
Installed on   : Sat Oct 22 14:44:51 2022 CEST
Origin         : www/apache24
Architecture   : FreeBSD:13:i386
Prefix         : /usr/local
Categories     : www
Licenses       : APACHE20
Maintainer     : [email]apache@FreeBSD.org[/email]
WWW            : [URL]https://httpd.apache.org/[/URL]
Comment        : Version 2.4.x of Apache web server
Options        :
        ACCESS_COMPAT  : on
        ACTIONS        : on
        ALIAS          : on
        ALLOWMETHODS   : on
        ASIS           : on
        AUTHNZ_FCGI    : on
        AUTHNZ_LDAP    : off
        AUTHN_ANON     : on
        AUTHN_CORE     : on
        AUTHN_DBD      : on
        AUTHN_DBM      : on
        AUTHN_FILE     : on
        AUTHN_SOCACHE  : on
        AUTHZ_CORE     : on
        AUTHZ_DBD      : on
        AUTHZ_DBM      : on
        AUTHZ_GROUPFILE: on
        AUTHZ_HOST     : on
        AUTHZ_OWNER    : on
        AUTHZ_USER     : on
        AUTH_BASIC     : on
        AUTH_DIGEST    : on
        AUTH_FORM      : on
        AUTOINDEX      : on
        BROTLI         : off
        BUCKETEER      : off
        BUFFER         : on
        CACHE          : on
        CACHE_DISK     : on
        CACHE_SOCACHE  : on
        CASE_FILTER    : off
        CASE_FILTER_IN : off
        CERN_META      : on
        CGI            : on
        CGID           : on
        CHARSET_LITE   : on
        DATA           : on
        DAV            : on
        DAV_FS         : on
        DAV_LOCK       : on
        DBD            : on
        DEFLATE        : on
        DIALUP         : on
        DIR            : on
        DOCS           : on
        DUMPIO         : on
        ECHO           : off
        ENV            : on
        EXAMPLE_HOOKS  : off
        EXAMPLE_IPC    : off
        EXPIRES        : on
        EXT_FILTER     : on
        FILE_CACHE     : on
        FILTER         : on
        HEADERS        : on
        HEARTBEAT      : on
        HEARTMONITOR   : on
        HTTP2          : on
        IDENT          : off
        IMAGEMAP       : on
        INCLUDE        : on
        INFO           : on
        IPV4_MAPPED    : off
        LBMETHOD_BYBUSYNESS: on
        LBMETHOD_BYREQUESTS: on
        LBMETHOD_BYTRAFFIC: on
        LBMETHOD_HEARTBEAT: on
        LDAP           : off
        LOGIO          : on
        LOG_DEBUG      : on
        LOG_FORENSIC   : on
        LUA            : off
        LUAJIT         : off
        MACRO          : on
        MD             : on
        MIME           : on
        MIME_MAGIC     : on
        MPM_EVENT      : off
        MPM_PREFORK    : on
        MPM_SHARED     : on
        MPM_WORKER     : off
        NEGOTIATION    : on
        OPTIONAL_FN_EXPORT: off
        OPTIONAL_FN_IMPORT: off
        OPTIONAL_HOOK_EXPORT: off
        OPTIONAL_HOOK_IMPORT: off
        PROXY          : on
        PROXY_AJP      : on
        PROXY_BALANCER : on
        PROXY_CONNECT  : on
        PROXY_EXPRESS  : on
        PROXY_FCGI     : on
        PROXY_FDPASS   : on
        PROXY_FTP      : on
        PROXY_HCHECK   : on
        PROXY_HTML     : on
        PROXY_HTTP     : on
        PROXY_HTTP2    : on
        PROXY_SCGI     : on
        PROXY_UWSGI    : on
        PROXY_WSTUNNEL : on
        RATELIMIT      : on
        REFLECTOR      : on
        REMOTEIP       : on
        REQTIMEOUT     : on
        REQUEST        : on
        REWRITE        : on
        SED            : on
        SESSION        : on
        SESSION_COOKIE : on
        SESSION_CRYPTO : on
        SESSION_DBD    : on
        SETENVIF       : on
        SLOTMEM_PLAIN  : on
        SLOTMEM_SHM    : on
        SOCACHE_DBM    : on
        SOCACHE_DC     : off
        SOCACHE_MEMCACHE: on
        SOCACHE_REDIS  : off
        SOCACHE_SHMCB  : on
        SPELING        : on
        SSL            : on
        STATUS         : on
        SUBSTITUTE     : on
        SUEXEC         : off
        SUEXEC_SYSLOG  : off
        UNIQUE_ID      : on
        USERDIR        : on
        USERTRACK      : on
        VERSION        : on
        VHOST_ALIAS    : on
        WATCHDOG       : on
        XML2ENC        : on
Shared Libs required:
        libxml2.so.2
        libpcre2-8.so.0
        libnghttp2.so.14
        libjansson.so.4
        libgdbm.so.6
        libexpat.so.1
        libdb-5.3.so.0
        libcurl.so.4
        libaprutil-1.so.0
        libapr-1.so.0
Annotations    :
        FreeBSD_version: 1301000
        cpe            : cpe:2.3:a:apache:http_server:2.4.54:::::freebsd13:x86
        repo_type      : binary
        repository     : FreeBSD
Flat size      : 26.8MiB
Description    :
The Apache HTTP Server Project is an effort to develop and maintain an
open-source HTTP server for various modern desktop and server operating
systems, such as UNIX and Windows NT. The goal of this project is to
provide a secure, efficient and extensible server which provides HTTP
services in sync with the current HTTP standards.
The 2.x branch of Apache Web Server includes several improvements like
threading, use of APR, native IPv6 and SSL support, and many more.

WWW: https://httpd.apache.org/
```


----------



## _martin (Oct 23, 2022)

Mhm, so you are on i386 system? Don't have i386 machine at hand, need to set that up.



veryfoot said:


> Can you tell me how to make this verification ? (make sure you don't have conflict with the modules)


Yes, the `-M` switch is a good way. Also you can check your config you are not loading php and php7 at the same time. I actually did quick debug when OP asked this question and the crash that is happening when both php and php7 are loaded is due to this. It seems these modules are stepping into each other.

But if you have only one module loaded something else is happening. Interestingly enough I can't even check 32b dump with 64b gdb (and there's no such thing as gdb-multiarch on FreeBSD).


----------



## veryfoot (Oct 23, 2022)

> Mhm, so you are on i386 system ?



Yes I am, and OP is under I386 as well. 

It is an old machine... Inter Core2 Duo. It can handle a 64bits, but I never took the time to re install it... It was working very good for my little needs... for 10 years now... Upgrades always working perfectly. First time I have a problem.

I confirm that i dont have multiple version of php. The previous version of PHP before the upgrade was 7.4.30. 


```
php --version
PHP 7.4.32 (cli) (built: Oct  2 2022 01:19:28) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.32, Copyright (c), by Zend Technologies
```


```
locate php | grep bin | grep -ve ports -ve www
/usr/local/bin/php
/usr/local/bin/php-cgi
/usr/local/bin/php-config
/usr/local/bin/phpize
/usr/local/include/php/ext/apc/apc_bin.h
/usr/local/sbin/php-fpm
```


```
pkg info | grep ^php
php74-7.4.32                   PHP Scripting Language
php74-bcmath-7.4.32            The bcmath shared extension for php
php74-bz2-7.4.32               The bz2 shared extension for php
php74-ctype-7.4.32             The ctype shared extension for php
php74-curl-7.4.32              The curl shared extension for php
php74-dom-7.4.32               The dom shared extension for php
php74-exif-7.4.32              The exif shared extension for php
php74-extensions-1.0           "meta-port" to install PHP extensions
php74-fileinfo-7.4.32          The fileinfo shared extension for php
php74-filter-7.4.32            The filter shared extension for php
php74-gd-7.4.32                The gd shared extension for php
php74-gmp-7.4.32               The gmp shared extension for php
php74-iconv-7.4.32             The iconv shared extension for php
php74-intl-7.4.32              The intl shared extension for php
php74-json-7.4.32              The json shared extension for php
php74-ldap-7.4.32              The ldap shared extension for php
php74-mbstring-7.4.32          The mbstring shared extension for php
php74-opcache-7.4.32           The opcache shared extension for php
php74-openssl-7.4.32           The openssl shared extension for php
php74-pcntl-7.4.32             The pcntl shared extension for php
php74-pdo-7.4.32               The pdo shared extension for php
php74-pdo_mysql-7.4.32         The pdo_mysql shared extension for php
php74-pdo_sqlite-7.4.32        The pdo_sqlite shared extension for php
php74-pecl-APCu-5.1.21         APC User Caching
php74-pecl-imagick-3.5.1       PHP wrapper to the ImageMagick/GraphicsMagick library version 6
php74-phar-7.4.32              The phar shared extension for php
php74-posix-7.4.32             The posix shared extension for php
php74-session-7.4.32           The session shared extension for php
php74-simplexml-7.4.32         The simplexml shared extension for php
php74-sqlite3-7.4.32           The sqlite3 shared extension for php
php74-tokenizer-7.4.32         The tokenizer shared extension for php
php74-xml-7.4.32               The xml shared extension for php
php74-xmlreader-7.4.32         The xmlreader shared extension for php
php74-xmlwriter-7.4.32         The xmlwriter shared extension for php
php74-xsl-7.4.32               The xsl shared extension for php
php74-zip-7.4.32_1             The zip shared extension for php
php74-zlib-7.4.32              The zlib shared extension for php
```
Alors have installed : `nextcloud-php74-24.0.5`

And for the modules :


```
httpd -M
Loaded Modules:
 core_module (static)
 so_module (static)
 http_module (static)
 mpm_prefork_module (shared)
 authn_file_module (shared)
 authn_core_module (shared)
 authz_host_module (shared)
 authz_groupfile_module (shared)
 authz_user_module (shared)
 authz_core_module (shared)
 access_compat_module (shared)
 auth_basic_module (shared)
 reqtimeout_module (shared)
 filter_module (shared)
 mime_module (shared)
 log_config_module (shared)
 env_module (shared)
 headers_module (shared)
 setenvif_module (shared)
 version_module (shared)
 ssl_module (shared)
 unixd_module (shared)
 status_module (shared)
 autoindex_module (shared)
 dir_module (shared)
 alias_module (shared)
 php7_module (shared)
```
Thanks a lot to take some time for helping me. 

And just for my knowledge... what is "gbd" ?

Vince


----------



## veryfoot (Oct 23, 2022)

Forgot this : 

`pkg info | grep ^mod`
mod_php74-7.4.32_1             PHP Scripting Language

Thks


----------



## _martin (Oct 23, 2022)

veryfoot said:


> And just for my knowledge... what is "gbd" ?


It's gdb(1) - very neat debugger. With that you can do either post-mortem analysis of a crash or even do a live debugging of a process.

I've installed i386 VM and I can reproduce the crash. Let me see if I can find something.


----------



## veryfoot (Oct 23, 2022)

_martin said:


> It's gdb(1) - very neat debugger. With that you can do either post-mortem analysis of a crash or even do a live debugging of a process.
> 
> I've installed i386 VM and I can reproduce the crash. Let me see if I can find something.



Good news ^^ 

It seems that I havent done something wrong. Thansk again for the help !


----------



## _martin (Oct 23, 2022)

This is an interesting problem. Crash occurs within very first function apache calls from this module: create_php_config. But problem is not the source code itself (C code) but rather the assembly code. Long story short -- it fails to jump properly to memset (your core dump shows that too) because ebx register is bogus. But even if I manually set it to a proper value (which I can determine if I read the init part of module in assembly) it crashes elsewhere because other modules and even httpd core has problem with it. i386 architecture in general suffers from lack of generic purpose registers, maybe clang is doing something here which screw things up. Personally I've not seen this issue ever, such behavior among loaded libraries.

Having that in my mind I tried gcc11 and built the port this way:
	
	



```
pkg install gcc
cd /usr/ports/www/mod_php74/
export CC=/usr/local/bin/gcc
make install clean
```
And I was able to start apache properly.

Side note: I built apache, apr, mod_php74 from ports with debug symbols so I can navigate myself easier around the debugger. Funny enough apache24 won't build as is. I had to modify the source code of apache ; trivial modification of snprintf() because compiler flags were too strict (time_t vs long int) but still .. well, tier 2.

For the sake of test I did install apache from a binary package and built mod_php74 from ports. It works ok. This way you don't need to care about the apache24 source code.

The obligatory phpinfo() snippet:


PHP Version 7.4.32​




SystemFreeBSD fbsd13i 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC i386Build DateOct 23 2022 22:52:04Configure Command'./configure'   '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--with-libxml' '--with-password-argon2=/usr/local' '--program-prefix=' '--disable-cgi' '--disable-cli' '--enable-mysqlnd' '--with-apxs2=/usr/local/sbin/apxs' '--prefix=/usr/local' '--localstatedir=/var' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=i386-portbld-freebsd13.1' 'build_alias=i386-portbld-freebsd13.1' 'PKG_CONFIG=pkgconf' 'PKG_CONFIG_LIBDIR=/usr/ports/www/mod_php74/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig' 'CPP=cpp' 'CXXFLAGS=-g -O0 -fstack-protector-strong -fno-strict-aliasing '


----------



## veryfoot (Oct 24, 2022)

Hi Martin !

Thanks for the return !

And many thanks for the solution !

The Cloud is back online ! 

Resume of what I did :


```
pkg delete mod_php74
pkg install gcc
cd /usr/ports/www/mod_php74/
bash
export CC=/usr/local/bin/gcc
make install clean
exit
/usr/local/etc/rc.d/apache24 start
```

Everything works perfectly ! BIG thank you !

I wish u the best my friend.

Vince (France)


----------



## veryfoot (Oct 24, 2022)

SOLVED !


----------



## _martin (Oct 24, 2022)

veryfoot said:


> And many thanks for the solution !


Glad I could help. Yeah I assumed you're using posix shell where variable is set that way. Instead of bash you can use `sh` from base. That was left as homework for a reader.


----------



## kazuya.fukushima (Nov 3, 2022)

Sorry to keep you waiting for my report so long.
After my trying to start apache24 with mod_php82 on FreeBSD13.1 and an older hardware, I failed.
================================================================
hardware environment:
                              motherboard: ASUS TUF B360-PLUS GAMING
                              CPU: 8th Generation core-i5
                              chipset: B360
--------------------------------------------------------------------------------------------------------------
software environment:

```
# uname -a
     FreeBSD sun.ptld.net 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC i386
    #pkg info |  grep apache24
    apache24-2.4.54
     #pkg info | grep  mod_php82
     mod_php82-8.0.2.r2_1
```
I couldn't detect the real reason that the combination of apache24 and mod_php82 is not good, but I succeeded in starting them up
as follows.

```
hardware environment:
     motherboard: ASUS PRIME H610M-A D4
     CPU: the 12th generation intel Core i-5 processor
     chipset: H610
software environment:
    # uname -a
    FreeBSD 12.3 sun.ptld.net 12.3-RELEASE r371126 GENERIC amd64 
    #pkg info |  grep apache24
    apache24-2.4.54
     #pkg info | grep  mod_php82
     mod_php82-8.0.2.r2_1
```
So I conclude that the problem lies in the combination of FreeBSD13.1 and mod_php74 - mod_php82.


----------



## _martin (Nov 3, 2022)

kazuya.fukushima Please read my answers and solution to the problem. Try that out. If that doesn't work please share the coredump, I can have a look to see why it crashes in your case.


----------



## PatchyFog (Dec 28, 2022)

I've been running FreeBSD in a lousy i386 GENERIC VM at RootBSD (now NetVantage) for 10+ years and have been fighting this problem all day. This thread finally spurred me on to finally registering for the forum. _martin's solution worked for me too, so wanted to say thanks -- I was stumped. As a retired embedded engineer of some 40 years, a compiler problem is the last thing I look for since, in all that time, I've only encountered a handful; maybe less than 10. And one involving clang is surprising too, as I consider it to be a much better compiler than gcc in all the respects that generally matter. And yet, here we are. I guess those optimized memory intrinsics can still bite you!

I had not updated my PHP in ages, and I had 7.4 core installed but a few php 5 modules (oh the shame). So this morning I stopped apache 24 and deleted everything and put 8.2 on. Boom! Signal 11. Deleted that and went to 8.1. Boom! Signal 11. Tried to go back to 7.4. Boom! Signal 11. AGHH!

Pulled out everything except php and mod_php. Boom! Signal 11. Updated FreeBSD. Rebuilt PKG dependencies. Forced reinstall of Apache. Updated every PKG. Boom! Signal 11.

`/usr/local/sbin/httpd -X` showed it was crashing inside `LoadModule php_module  libexec/apache24/libphp.so`. 

`gdb` of the coredump revealed this:


```
(gdb) bt
#0  0x73696874 in ?? ()
#1  0x21717da5 in ?? () from /usr/local/libexec/apache24/libphp.so
#2  0x216a600a in zend_register_functions () from /usr/local/libexec/apache24/libphp.so
#3  0x216a5e50 in zend_register_module_ex () from /usr/local/libexec/apache24/libphp.so
#4  0x216b4e5e in ?? () from /usr/local/libexec/apache24/libphp.so
#5  0x2169eb19 in ?? () from /usr/local/libexec/apache24/libphp.so
#6  0x2163e901 in php_module_startup () from /usr/local/libexec/apache24/libphp.so
#7  0x21771932 in ?? () from /usr/local/libexec/apache24/libphp.so
#8  0x21771310 in ?? () from /usr/local/libexec/apache24/libphp.so
#9  0x0045447c in ap_run_post_config ()
#10 0x00450509 in main ()
```

I was stumped. Had to be a library mismatch or something! Never a COMPILER PROBLEM!

BUT...yeah, switched to GCC, built mod_php 8.2 and all is working (actually built the Q3 22 Alpha 1 version, so need to switch to HEAD and do it again I guess, but it does work.) Anyway, the usual trivia below to close the loop, but thanks again (and it sure would be nice if clang was adjusted to correct the "official" pkg.)

But at least my system is now completely up to date! 

Best and happy new year.

-- Ward

`pkg info | grep php
mod_php82-8.2.0.a1             PHP Scripting Language (8.2.X branch)
php82-8.2.0.r2                 PHP Scripting Language (8.2.X branch)`

`[/usr/local/etc/apache24] -> uname -a
FreeBSD redacted.com 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC i386`

`Name           : apache24
Version        : 2.4.54
Installed on   : Tue Dec 27 15:48:23 2022 PST
Origin         : www/apache24
Architecture   : FreeBSD:13:i386`


```
[/usr/local/etc/apache24] -> php -i
phpinfo()
PHP Version => 8.2.0RC2

System => FreeBSD redacted.com 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC i386
Build Date => Dec  1 2022 07:42:59
Build System => FreeBSD 131i386-quarterly-job-11 13.1-RELEASE-p5 FreeBSD 13.1-RELEASE-p5 i386
Configure Command =>  './configure'  '--disable-all' '--program-prefix=' '--with-config-file-scan-dir=/usr/local/etc/php' '--with-layout=GNU' '--with-libxml' '--with-openssl' '--with-password-argon2=/usr/local' '--enable-dtrace' '--enable-embed' '--enable-fpm' '--with-fpm-group=www' '--with-fpm-user=www' '--enable-mysqlnd' '--prefix=/usr/local' '--localstatedir=/var' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=i386-portbld-freebsd13.1' 'build_alias=i386-portbld-freebsd13.1' 'PKG_CONFIG=pkgconf' 'PKG_CONFIG_LIBDIR=/wrkdirs/usr/ports/lang/php82/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig' 'CFLAGS=-O2 -pipe -fstack-protector-strong -fno-strict-aliasing ' 'LDFLAGS=-L/usr/lib -lcrypto -lssl -fstack-protector-strong -Wl,-z,notext' 'CPP=cpp' 'CXXFLAGS=-O2 -pipe -fstack-protector-strong -fno-strict-aliasing ' 'OPENSSL_CFLAGS=-I/usr/include' 'OPENSSL_LIBS=-L/usr/lib -lssl -lcrypto'
```


----------



## Alain De Vos (Dec 28, 2022)

Try php80. It's the default in quarterly


----------



## richardtoohey2 (Dec 28, 2022)

Do you have to run i386 at RootBSD - 64-bit is more common these days. So if you are upgrading everything might be an idea to move off 32-bit at the same time.


----------



## PatchyFog (Jan 1, 2023)

richardtoohey2 said:


> Do you have to run i386 at RootBSD - 64-bit is more common these days. So if you are upgrading everything might be an idea to move off 32-bit at the same time.


Yeah, I've decided to move to Contabo and save $200+ a year to boot. (Plus, pick up an additional 180GB of storage and 3GB of memory.) Should have left RootBSD/NetAcutate years ago. The new instance is amd64 and fast as blazes.


----------

