Original post is here: eklausmeier.goip.de
Task at hand: Call Cobol (=GnuCOBOL) from PHP. I used FFI for this:
1<?php
2 $cbl = FFI::cdef("int phpsqrt(void); void cob_init_nomain(int,char**); int cob_tidy(void);", "/srv/http/phpsqrt.so");
3 $ffj0 = FFI::cdef("double j0(double);", "libm.so.6");
4
5 $cbl->cob_init_nomain(0,null);
6 $ret = $cbl->phpsqrt();
7 printf("\tret = %d<br>\n",$ret);
8 echo "Before calling cob_tidy():<br>\n";
9 echo "\tReturn: ", $cbl->cob_tidy(), "<br>\n";
10 printf("j0(2) = %f<br>\n", $ffj0->j0(2));
11?>
The Cobol program is:
1000010 IDENTIFICATION DIVISION.
2000020 PROGRAM-ID. phpsqrt.
3000030 AUTHOR. Elmar Klausmeier.
4000040 DATE-WRITTEN. 01-Jul-2004.
5000050
6000060 DATA DIVISION.
7000070 WORKING-STORAGE SECTION.
8000080 01 i PIC 9(5).
9000090 01 s usage comp-2.
10000100
11000110 PROCEDURE DIVISION.
12000120* DISPLAY "Hello World!".
13000130 PERFORM VARYING i FROM 1 BY 1 UNTIL i > 10
14000140 move function sqrt(i) to s
15000150* DISPLAY i, " ", s
16000160 END-PERFORM.
17000170
18000180 move 17 to return-code.
19000190 GOBACK.
20000200
Config in php.ini file has to be changed:
1extension=ffi
2ffi.enable=true
To call GnuCOBOL from C, you have to first call cob_init() or cob_init_nomain(), which initializes GnuCOBOL. I tried both initialization routines, and both resulted in PHP crashing after running above program, i.e., segmentation fault.
I created a bug for this: FFI crashes with segmentation fault when calling cob_init().
1. I compiled PHP 8.0.3 from source. For this I had to add below packages:
1pacman -S tidy freetds c-client
I grep'ed my current configuration:
1php -i | grep "Configure Comman"
2Configure Command => './configure' '--srcdir=../php-8.0.3' '--config-cache' '--prefix=/usr' '--sbindir=/usr/bin' '--sysconfdir=/etc/php' '--localstatedir=/var' '--with-layout=GNU' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/conf.d' '--disable-rpath' '--mandir=/usr/share/man' '--enable-cgi' '--enable-fpm' '--with-fpm-systemd' '--with-fpm-acl' '--with-fpm-user=http' '--with-fpm-group=http' '--enable-embed=shared' '--enable-bcmath=shared' '--enable-calendar=shared' '--enable-dba=shared' '--enable-exif=shared' '--enable-ftp=shared' '--enable-gd=shared' '--enable-intl=shared' '--enable-mbstring' '--enable-pcntl' '--enable-shmop=shared' '--enable-soap=shared' '--enable-sockets=shared' '--enable-sysvmsg=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--with-bz2=shared' '--with-curl=shared' '--with-db4=/usr' '--with-enchant=shared' '--with-external-gd' '--with-external-pcre' '--with-ffi=shared' '--with-gdbm' '--with-gettext=shared' '--with-gmp=shared' '--with-iconv=shared' '--with-imap-ssl' '--with-imap=shared' '--with-kerberos' '--with-ldap=shared' '--with-ldap-sasl' '--with-mhash' '--with-mysql-sock=/run/mysqld/mysqld.sock' '--with-mysqli=shared,mysqlnd' '--with-openssl' '--with-password-argon2' '--with-pdo-dblib=shared,/usr' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-pgsql=shared' '--with-pdo-sqlite=shared' '--with-pgsql=shared' '--with-pspell=shared' '--with-readline' '--with-snmp=shared' '--with-sodium=shared' '--with-sqlite3=shared' '--with-tidy=shared' '--with-unixODBC=shared' '--with-xsl=shared' '--with-zip=shared' '--with-zlib'
To this I added --enable-debug. Command configure needs two minutes. Then make -j8 needs another two minutes.
I copied php.ini to local directory, changed it to activated FFI. Whenever I called
1$BUILD/sapi/cli/php
I had to add -c php.ini, when I called an extension written by me, stored in ext/.
2. The fix for segmentation fault is actually pretty easy: Just set environment variable ZEND_DONT_UNLOAD_MODULES:
1ZEND_DONT_UNLOAD_MODULES=1 $BUILD/sapi/cli/php -c php.ini -r 'test1();'
Reason for this: see valgrind output below.
Some additional information on this environment variable from GitHub PHP source:
Since PHP 5.3.11 it is possible to prevent shared extensions from unloading so that valgrind can correctly track the memory leaks in shared extensions. For this there is the
ZEND_DONT_UNLOAD_MODULESenvironment variable. If set, thenDL_UNLOAD()is skipped during the shutdown of shared extensions.
3. Before I had figured out the "trick" with ZEND_DONT_UNLOAD_MODULES, I wrote a PHP extension. The extension is:
1/* {{{ void test1() */
2PHP_FUNCTION(test1)
3{
4 ZEND_PARSE_PARAMETERS_NONE();
5
6 php_printf("test1(): The extension %s is loaded and working!\r\n", "callcob");
7 cob_init(0,NULL);
8}
9/* }}} */
Unfortunately, running this extension resulted in:
1Module compiled with build ID=API20200930,NTS
2PHP compiled with build ID=API20200930,NTS,debug
3These options need to match
I solved this by adding below string:
1/* {{{ callcob_module_entry */
2zend_module_entry callcob_module_entry = {
3 STANDARD_MODULE_HEADER,
4 //sizeof(zend_module_entry), ZEND_MODULE_API_NO, 1, USING_ZTS,
5 "callcob", /* Extension name */
6 ext_functions, /* zend_function_entry */
7 NULL, /* PHP_MINIT - Module initialization */
8 NULL, /* PHP_MSHUTDOWN - Module shutdown */
9 PHP_RINIT(callcob), /* PHP_RINIT - Request initialization */
10 NULL, /* PHP_RSHUTDOWN - Request shutdown */
11 PHP_MINFO(callcob), /* PHP_MINFO - Module info */
12 PHP_CALLCOB_VERSION, /* Version */
13 STANDARD_MODULE_PROPERTIES
14 ",debug"
15};
16/* }}} */
I guess this is not the recommend approach.
4. Valgrind shows the following:
1==37350== Process terminating with default action of signal 11 (SIGSEGV): dumping core
2==37350== Access not within mapped region at address 0x852AD20
3==37350== at 0x852AD20: ???
4==37350== by 0x556EF7F: ??? (in /usr/lib/libc-2.33.so)
5==37350== by 0x5570DCC: getenv (in /usr/lib/libc-2.33.so)
6==37350== by 0x76BB43: module_destructor (zend_API.c:2629)
7==37350== by 0x75EE31: module_destructor_zval (zend.c:782)
8==37350== by 0x7777A1: _zend_hash_del_el_ex (zend_hash.c:1330)
9==37350== by 0x777880: _zend_hash_del_el (zend_hash.c:1353)
10==37350== by 0x779188: zend_hash_graceful_reverse_destroy (zend_hash.c:1807)
11==37350== by 0x769390: zend_destroy_modules (zend_API.c:1992)
12==37350== by 0x75F582: zend_shutdown (zend.c:1078)
13==37350== by 0x6C3F17: php_module_shutdown (main.c:2359)
14==37350== by 0x84E46D: main (php_cli.c:1351)
15==37350== If you believe this happened as a result of a stack
16==37350== overflow in your program's main thread (unlikely but
17==37350== possible), you can try to increase the size of the
18==37350== main thread stack using the --main-stacksize= flag.
19==37350== The main thread stack size used in this run was 8388608.
20. . .
21zsh: segmentation fault (core dumped) valgrind $BUILD/sapi/cli/php -c $BUILD/php.ini -r 'test1();'
As shown above, the relevant code in question is Zend/zend_API.c in line 2629. This is shown below:
1void module_destructor(zend_module_entry *module) /* {{{ */
2{
3. . .
4 module->module_started=0;
5 if (module->type == MODULE_TEMPORARY && module->functions) {
6 zend_unregister_functions(module->functions, -1, NULL);
7 }
8
9#if HAVE_LIBDL
10 if (module->handle && !getenv("ZEND_DONT_UNLOAD_MODULES")) {
11 DL_UNLOAD(module->handle);
12 }
13#endif
14}
15/* }}} */
It is the DL_UNLOAD, which is a #define for dlclose, which actually provokes the crash.
According PHP Internals Book -- Zend Extensions:
Here, we are loaded as a PHP extension. Look at the hooks. When hitting MSHUTDOWN(), the engine runs our MSHUTDOWN(), but it unloads us just after that ! It calls for dlclose() on our extension, look at the source code, the solution is as often located in there.So what happens is easy, just after triggering our RSHUTDOWN(), the engine unloads our pib.so ; when it comes to call our Zend extension part shutdown(), we are not part of the process address space anymore, thus we badly crash the entire PHP process.
What is still not understood: Why does FFI not crash with those simple functions, like printf(), or sqrt()?