|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #81470 Seg fault on Arm processoer
Submitted: 2021-09-23 14:07 UTC Modified: 2021-09-23 14:39 UTC
From: ahollandmoritz at glastender dot com Assigned:
Status: Closed Package: PDO_INFORMIX (PECL)
PHP Version: 8.0.10 OS: debian 11/fedora 34 ARM
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: ahollandmoritz at glastender dot com
New email:
PHP Version: OS:


 [2021-09-23 14:07 UTC] ahollandmoritz at glastender dot com
Installed ibm.csdk.4.50.FC3.ARMV8, downloaded PDO_INFORMIX and compiled. Running make test reports segemenation fault, and "BORK Termsig=11 [tests/fvt_001.phpt] reason: invalid output from SKIPIF
BORK Termsig=11 [tests/fvt_002.phpt] reason: invalid output from SKIPIF".

Attempting to use the PHP after enabling the extension (eg php -v or php -i) just causes segmentation fault. Using gdb outputs...

root@php8deb:~/PDO_INFORMIX-1.3.4# gdb /usr/bin/php
GNU gdb (Debian 10.1-1.7)
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/".
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?)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-09-23 14:10 UTC] ahollandmoritz at glastender dot com
Iust want to note that if I set up ODBC against the installed informix it works fine (use 'isql' to query the server works). So I do not think the issue is with my Informix install. 

I also tried on Fedora 34 on arm with their stock php 7.4 install and I get the same results (backtrace is almost identical).
 [2021-09-23 14:12 UTC] ahollandmoritz at glastender dot com
-Operating System: debian 11 +Operating System: debian 11/fedora 34 ARM
 [2021-09-23 14:12 UTC] ahollandmoritz at glastender dot com
update OS
 [2021-09-23 14:23 UTC]
Assuming you have PDO_INFORMIX 1.3.4 from PECL, please have a look
at pdo_informix.c.  Line 45-51 is:

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

but should probably be:

zend_function_entry pdo_informix_functions[] =

Would that solve the issue?

I would submit a PR, but I don't know where the sources are
hosted.  The GH repo[1] appears to be abandoned for years.

[1] <>
 [2021-09-23 14:39 UTC] ahollandmoritz at glastender dot com
-Status: Open +Status: Closed
 [2021-09-23 14:39 UTC] ahollandmoritz at glastender dot com
That worked!

Thanks so much for the help, I'll see if I can get in touch with the maintainers to release an update.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jun 18 22:01:29 2024 UTC