PHP 8 PDO_INFORMIX Error on ARM Linux

Published on Jun 28, 2023
Topics: PHP, ARM, Informix

This information is from back in 2021 when I got my first ARM based Mac (an M1 Macbook Air), but the bug looks like it is till present. First step was setting up my dev environment on it. Normally I would move my existing Linux development virtual machine over to the new machine. But we're moving from x86 to ARM so I can't do that this time. I have to set up a new Debian 11 ARM VM. No big deal, steps are 99% the same.

For work reasons I regularly have to connect to an Informix database using the PDO_INFORMIX driver. Not a big deal, I have compiled and installed it lots of times.

Problem

I never compiled it on ARM though. Configure worked fine, running make test would throw a seg fault like and an error like BORK Termsig=11 [tests/fvt_001.phpt] reason: invalid output from SKIPIF BORK Termsig=11 [tests/fvt_002.phpt] reason: invalid output from SKIPIF

I ran a backtrace on it with GDB to try and confirm it wasn't a problem with my set up. The backtrace was useless to me.

root@php8deb:~/PDO_INFORMIX-1.3.4# gdb /usr/bin/php
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
This GDB was configured as "aarch64-linux-gnu".
Reading symbols from /usr/bin/php...
(No debugging symbols found in /usr/bin/php)
(gdb) run -v
Starting program: /usr/bin/php -v
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
__strlen_generic () at ../sysdeps/aarch64/multiarch/../strlen.S:98
98	../sysdeps/aarch64/multiarch/../strlen.S: No such file or directory.
(gdb) bt
#0  __strlen_generic () at ../sysdeps/aarch64/multiarch/../strlen.S:98
#1  0x0000aaaaaad56b60 in zend_register_functions ()
#2  0x0000aaaaaad573cc in zend_register_module_ex ()
#3  0x0000aaaaaac88d28 in php_load_extension ()
#4  0x0000aaaaaad44e10 in zend_llist_apply ()
#5  0x0000aaaaaacf22ec in ?? ()
#6  0x0000aaaaaacea8ec in php_module_startup ()
#7  0x0000aaaaaadf1808 in ?? ()
#8  0x0000aaaaaab9fcb0 in ?? ()
#9  0x0000fffff7763218 in __libc_start_main (main=0xaaaaaab9fab0, argc=2, argv=0xfffffffffb18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=<optimized out>) at ../csu/libc-start.c:308
#10 0x0000aaaaaab9fff0 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Solution

At a loss for what to do I posted bug report 81470 to get some help. Very quickly I got a solution to the problem.

In the pdo_informix.c file, lines 45-51 I had to change this:

zend_function_entry pdo_informix_functions[] =
{
//	PHP_FE(confirm_pdo_informix_compiled, NULL)	/* For testing, remove later. */
//	{
//		NULL, NULL, NULL
//	}	/* Must be the last line in pdo_informix_functions[] */
};

To this:

zend_function_entry pdo_informix_functions[] =
{
    PHP_FE_END
};

Reconfigure and compile and everything works.