Skip to content

Segmentation fault, probaby on string operation #18611

Open
@tobihille

Description

@tobihille

Description

Hi,

when running a lenghty process I encounter an issue in PHP 8.3.21.
I can confirm, that in PHP 8.3.19 (with ddev 1.24.4) everything was fine.

As the process takes time (roughly one hour until it crashes) I sadly can not exactly pinpoint the location of the issue in my PHP-Code.
To hopefully make up for that I investigated the issue with gdb, I hope this can help you find out what is happening.

This is the backtrace I got:

thille@shop-web:/var/www/html$ gdb --args php shell/integernet-solr.php -reindex -stores 1 -types all -emptyindex
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from php...
Reading symbols from /usr/lib/debug/.build-id/fa/09641e6ffcc22ab1527a6ab25e5188ce46c6df.debug...
(gdb) run
Starting program: /usr/bin/php shell/integernet-solr.php -reindex -stores 1 -types all -emptyindex
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 3878]

Program received signal SIGSEGV, Segmentation fault.
zend_mm_alloc_small (bin_num=3, heap=0x722bcc600040) at ./Zend/zend_alloc.c:1312
1312    ./Zend/zend_alloc.c: No such file or directory.
(gdb) bt
#0  zend_mm_alloc_small (bin_num=3, heap=0x722bcc600040) at ./Zend/zend_alloc.c:1312
#1  zend_mm_alloc_heap (size=<optimized out>, heap=0x722bcc600040) at ./Zend/zend_alloc.c:1383
#2  _emalloc (size=<optimized out>) at ./Zend/zend_alloc.c:2613
#3  0x00005aebb50c061e in zend_string_alloc (persistent=false, len=<optimized out>) at ./Zend/zend_string.h:174
#4  zend_string_init (persistent=false, len=<optimized out>, str=0x4107986b "Store") at ./Zend/zend_string.h:196
#5  zend_string_init_fast (len=<optimized out>, str=0x4107986b "Store") at ./Zend/zend_string.h:206
#6  zif_substr (execute_data=0x722bcc615270, return_value=0x722bcc6151a0) at ./ext/standard/string.c:2086
#7  0x00005aebb51d364d in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at ./Zend/zend_vm_execute.h:1337
#8  execute_ex (ex=0x15cd2420) at ./Zend/zend_vm_execute.h:57246
#9  0x00005aebb51d86c5 in zend_execute (op_array=0x722bcc68e000, return_value=0x0) at ./Zend/zend_vm_execute.h:61634
#10 0x00005aebb5164118 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at ./Zend/zend.c:1895
#11 0x00005aebb50f82ee in php_execute_script (primary_file=primary_file@entry=0x7ffdf2dcda00) at ./main/main.c:2529
#12 0x00005aebb52507dd in do_cli (argc=8, argv=0x5aebc82129f0) at ./sapi/cli/php_cli.c:966
#13 0x00005aebb4f85b77 in main (argc=8, argv=0x5aebc82129f0) at ./sapi/cli/php_cli.c:1341
(gdb)

I don't know if this is relevant but I'm using PHP inside of ddev (https://github.com/ddev/ddev). The used version there is 1.24.6.

To be able to provide a (hopefully) meaningful stack I altered the provided ddev container with these command: sudo apt install gdb php8.3-cli-dbgsym

I am by no means an expert in debugging C or running something with GDB so if I missed something and you need further information please let me know.

Sadly the code I'm using is not open source so I feel not comfortable to provide any code examples here (in addition to it being a time consuming process to even provide this information). But in essence what is running is a modified version of OpenMage (https://github.com/OpenMage/magento-lts/tree/v21.0.0-beta2) together with a modified commercial version of the Integernet Solr Module (https://github.com/integer-net/solr-magento1). Would it be helpful to try triggering the issue with this open source setup?

PHP Version

PHP 8.3.21 (cli) (built: May  9 2025 06:38:45) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.21, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.21, Copyright (c), by Zend Technologies

Operating System

Debian GNU/Linux 12 (bookworm) in ddev

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions