Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1513816 - APCu segfaults at PHP-FPM startup
Summary: APCu segfaults at PHP-FPM startup
Keywords:
Status: CLOSED DUPLICATE of bug 1502303
Alias: None
Product: Fedora
Classification: Fedora
Component: php-pecl-apcu
Version: 27
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Remi Collet
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-16 02:30 UTC by David Strauss
Modified: 2017-11-16 07:20 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-16 07:20:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Strauss 2017-11-16 02:30:33 UTC
Description of problem:
Starting up PHP-FPM fails with APCu (php-pecl-apcu) enabled.

Version-Release number of selected component (if applicable):
5.1.8-4.fc27

How reproducible:
Every time.

Steps to Reproduce:
1. Install: dnf install php-fpm and php-pecl-apcu
2. Start: systemctl start php-fpm

Actual results:
[straussd@t560 ~]$ sudo systemctl restart php-fpm
Job for php-fpm.service failed because a fatal signal was delivered causing the control process to dump core.
See "systemctl  status php-fpm.service" and "journalctl  -xe" for details.
[straussd@t560 ~]$ sudo systemctl  status php-fpm.service
● php-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled)
   Active: failed (Result: core-dump) since Wed 2017-11-15 18:20:04 PST; 2s ago
  Process: 30609 ExecStart=/usr/sbin/php-fpm --nodaemonize (code=dumped, signal=SEGV)
 Main PID: 30609 (code=dumped, signal=SEGV)

Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: Starting The PHP FastCGI Process Manager...
Nov 15 18:20:04 t560.davidstrauss.net php-fpm[30609]: [15-Nov-2017 18:20:04] NOTICE: PHP message: PHP Fatal error:  PHP Startup: apc_mmap: mmap failed: in Unknown on line 0
Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: php-fpm.service: Main process exited, code=dumped, status=11/SEGV
Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: Failed to start The PHP FastCGI Process Manager.
Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: php-fpm.service: Unit entered failed state.
Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: php-fpm.service: Failed with result 'core-dump'.


Expected results:
Successful PHP-FPM startup with APCu.

Additional info:
Removing or disabling APCu fixes the issue. Commenting out "apc.mmap_file_mask=/tmp/apc.XXXXXX" in /etc/php.d/40-apcu.ini switches APCu to using an anonymous mmap and also works around the issue.

Abrt seems unable to create a suitable backtrace (either on my machine or on the hosted Fedora backtrace servers):

--- Running report_uReport ---
('report_uReport' completed successfully)

--- Running analyze_CCpp ---
Ok to upload core dump? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. (It may download a huge amount of data). 'NO'
Analyzing coredump 'coredump'
All debuginfo files are available
Generating backtrace
Backtrace is generated and saved, 32881 bytes

--- Running analyze_BodhiUpdates ---
Looking for similar problems in bugzilla

A notice below says:

Reporting disabled because the backtrace is unusable.

coredumpctl has more success:

[straussd@t560 ~]$ coredumpctl info
           PID: 28165 (php-fpm)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Wed 2017-11-15 18:06:31 PST (23min ago)
  Command Line: /usr/sbin/php-fpm --nodaemonize
    Executable: /usr/sbin/php-fpm
 Control Group: /system.slice/php-fpm.service
          Unit: php-fpm.service
         Slice: system.slice
       Boot ID: 25eb6c2a86544ff8ada94f8964dd7685
    Machine ID: 090dfce8e91946609388331241a392a1
      Hostname: t560.davidstrauss.net
       Storage: /var/lib/systemd/coredump/core.php-fpm.0.25eb6c2a86544ff8ada94f8964dd7685.28165.1510797991000000.lz4 (inaccessible)
       Message: Process 28165 (php-fpm) of user 0 dumped core.
                
                Stack trace of thread 28165:
                #0  0x00007f5728d8e48e pthread_rwlock_init (libpthread.so.0)
                #1  0x00007f5714191480 apc_lock_create (apcu.so)
                #2  0x00007f5714195f34 apc_sma_api_init (apcu.so)
                #3  0x00007f57141923b7 zm_startup_apcu (apcu.so)
                #4  0x000056251973b0c4 zend_startup_module_ex (php-fpm)
                #5  0x000056251973b19c zend_startup_module_zval (php-fpm)
                #6  0x0000562519748b6a zend_hash_apply (php-fpm)
                #7  0x000056251973b48a zend_startup_modules (php-fpm)
                #8  0x00005625196d2b93 php_module_startup (php-fpm)
                #9  0x00005625197e68c5 php_cgi_startup (php-fpm)
                #10 0x00005625195aa160 main (php-fpm)
                #11 0x00007f57291c503a __libc_start_main (libc.so.6)
                #12 0x00005625195ab63a _start (php-fpm)

Comment 1 Remi Collet 2017-11-16 07:20:41 UTC

*** This bug has been marked as a duplicate of bug 1502303 ***


Note You need to log in before you can comment on or make changes to this bug.