php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #72183 Segmentation fault in zend_objects_store_call_destructors
Submitted: 2016-05-09 19:27 UTC Modified: 2021-07-18 04:22 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: tom60 at op dot pl Assigned: cmb (profile)
Status: No Feedback Package: opcache
PHP Version: 7.0.6 OS: Debian Jessie 64 bit
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2016-05-09 19:27 UTC] tom60 at op dot pl
Description:
------------
I've attached a stack trace of a segmentation fault that occured to me on PHP 7.0.6. Perhaps it's related to a bug that was recently fixed in PHP 7.0.4? https://bugs.php.net/bug.php?id=71859

Actual result:
--------------
Reading symbols from /opt/apache2/sbin/apache2...done.
[New LWP 32334]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/opt/apache2/sbin/apache2 -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fcbe202dc48 in zend_objects_store_call_destructors (objects=objects@entry=0x7fcbe295fa70 <executor_globals+816>)
    at /src/php-7.0.6/Zend/zend_objects_API.c:49
49                              zend_object *obj = objects->object_buckets[i];

(gdb) bt
#0  0x00007fcbe202dc48 in zend_objects_store_call_destructors (objects=objects@entry=0x7fcbe295fa70 <executor_globals+816>)
    at /src/php-7.0.6/Zend/zend_objects_API.c:49
#1  0x00007fcbe1fe5013 in shutdown_destructors () at /src/php-7.0.6/Zend/zend_execute_API.c:242
#2  0x00007fcbe1ff41d4 in zend_call_destructors () at /src/php-7.0.6/Zend/zend.c:952
#3  0x00007fcbe1f97495 in php_request_shutdown (dummy=dummy@entry=0x0) at /src/php-7.0.6/main/main.c:1780
#4  0x00007fcbe20867df in php_apache_request_dtor (r=<optimized out>) at /src/php-7.0.6/sapi/apache2handler/sapi_apache2.c:518
#5  php_handler (r=<optimized out>) at /src/php-7.0.6/sapi/apache2handler/sapi_apache2.c:690
#6  0x00007fcbe495dcf0 in ap_run_handler (r=r@entry=0x7fcbe6776dc0) at config.c:170
#7  0x00007fcbe495e239 in ap_invoke_handler (r=r@entry=0x7fcbe6776dc0) at config.c:434
#8  0x00007fcbe497e02c in ap_internal_redirect (new_uri=<optimized out>, r=<optimized out>) at http_request.c:730
#9  0x00007fcbe49b9fc2 in handler_redirect (r=0x7fcbe676e580) at mod_rewrite.c:5176
#10 0x00007fcbe495dcf0 in ap_run_handler (r=r@entry=0x7fcbe676e580) at config.c:170
#11 0x00007fcbe495e239 in ap_invoke_handler (r=0x7fcbe676e580) at config.c:434
#12 0x00007fcbe497ed92 in ap_process_async_request (r=0x7fcbe676e580) at http_request.c:410
#13 0x00007fcbe497ef30 in ap_process_request (r=0x7fcbe676e580) at http_request.c:445
#14 0x00007fcbe497b0de in ap_process_http_sync_connection (c=0x7fcbe6758240) at http_core.c:210
#15 ap_process_http_connection (c=0x7fcbe6758240) at http_core.c:251
#16 0x00007fcbe49673a0 in ap_run_process_connection (c=0x7fcbe6758240) at connection.c:42
#17 0x00007fcbe49c1dd2 in child_main (child_num_arg=-493487504, child_bucket=-1718062336) at prefork.c:723
#18 0x00007fcbe49c2050 in make_child (s=0x7fcbe64359b8, slot=7, bucket=0) at prefork.c:824
#19 0x00007fcbe49c2ea5 in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:932
#20 prefork_run (_pconf=0x7fcbe295fa70 <executor_globals+816>, plog=0x7ffc999873d4, s=0x7ffc999873b0) at prefork.c:1128
#21 0x00007fcbe494289e in ap_run_mpm (pconf=0x7fcbe6400138, plog=0x7fcbe6439818, s=0x7fcbe64359b8) at mpm_common.c:94
#22 0x00007fcbe493be15 in main (argc=3, argv=0x7ffc99987688) at main.c:778

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-05-10 05:22 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2016-05-10 05:22 UTC] laruence@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2016-05-17 09:28 UTC] tom60 at op dot pl
The bug usually occurs after calling opcache_reset() (but not always). So far I have been unable to prepare a script that would reliably reproduce it.
 [2016-05-22 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2017-03-30 15:06 UTC] requinix@php.net
-Status: No Feedback +Status: Re-Opened -Package: Reproducible crash +Package: opcache
 [2017-03-30 15:07 UTC] requinix@php.net
Also happens in 7.1.3 with the same backtrace (cf. bug #74342).
 [2021-07-08 12:08 UTC] cmb@php.net
-Status: Re-Opened +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-07-08 12:08 UTC] cmb@php.net
Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>
 [2021-07-18 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 02:01:28 2024 UTC