php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #62929 Segmentation fault on Zend Framework application
Submitted: 2012-08-25 17:33 UTC Modified: 2012-08-31 11:02 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: sergiu dot ionescu at gmail dot com Assigned:
Status: Open Package: *General Issues
PHP Version: PHP 5.3.16 OS: Ubuntu 10.04.4 LTS
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-08-25 17:33 UTC] sergiu dot ionescu at gmail dot com
Description:
------------
I randomly get segmentation faults while running cli scripts.
The fault occurs at the end of the script run and happens in more than 50% of the cases.



Expected result:
----------------
No seg fault.

Actual result:
--------------
syslog: [24766.653698] php[8084]: segfault at 30 ip 00000000006b7241 sp 00007fff508cc110 error 4 in php5[400000+70e000]

The GDB backtrace is:

#0  0x00000000006b7241 in ?? ()
#1  0x00000000006b771b in ?? ()
#2  0x00000000006a3a38 in zend_hash_destroy ()
#3  0x0000000000696a3f in _zval_dtor_func ()
#4  0x000000000068aa9d in _zval_ptr_dtor ()
#5  0x00000000006a3a38 in zend_hash_destroy ()
#6  0x0000000000696a3f in _zval_dtor_func ()
#7  0x000000000068aa9d in _zval_ptr_dtor ()
#8  0x00000000006a3a38 in zend_hash_destroy ()
#9  0x0000000000696a3f in _zval_dtor_func ()
#10 0x000000000068aa9d in _zval_ptr_dtor ()
#11 0x00000000006a3a38 in zend_hash_destroy ()
#12 0x00000000006b8a89 in zend_object_std_dtor ()
#13 0x00000000006b8aa9 in zend_objects_free_object_storage ()
#14 0x00000000006bc16c in zend_objects_store_free_object_storage ()
#15 0x000000000068ae95 in ?? ()
#16 0x0000000000697782 in ?? ()
#17 0x0000000000643165 in php_request_shutdown ()
#18 0x00000000007273e4 in ?? ()
#19 0x00007ffff52a5c4d in __libc_start_main (main=<value optimized out>,
    argc=<value optimized out>, ubp_av=<value optimized out>, init=<value optimized out>,
    fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffffffe6a8)
    at libc-start.c:226
#20 0x000000000042c6f9 in _start ()

The php version i am running is PHP 5.3.2-1ubuntu4.17 with Suhosin-Patch (cli) (built: Jun 19 2012 03:21:35).
What is your recommendation.
Thanks.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-08-25 17:41 UTC] rasmus@php.net
-Status: Open +Status: Feedback
 [2012-08-25 17:41 UTC] rasmus@php.net
The PHP version is not irrelevant at all. We can't possibly do anything with this 
bug unless you tell us which version you are seeing it in.
 [2012-08-25 17:42 UTC] rasmus@php.net
-PHP Version: Irrelevant +PHP Version: PHP 5.3.2
 [2012-08-25 17:42 UTC] rasmus@php.net
Ah, I see the version at the bottom of your report now. I have fixed it in the 
report. 5.3.2 is from March 2010. Please upgrade to something more recent.
 [2012-08-26 05:26 UTC] sergiu dot ionescu at gmail dot com
Can you please point me to the change-log note for this fix?
I want to be 100% sure that it's  the same issue, as we are trying to be as conservative as possible with environment updates.

Thanks!
 [2012-08-26 05:26 UTC] sergiu dot ionescu at gmail dot com
-Status: Feedback +Status: Open
 [2012-08-26 05:54 UTC] rasmus@php.net
There is no changelog entry for it. Your report is not specific enough, but we 
need to know if it is happening in a current version before we bother spending 
any time looking for it. chasing fixed bugs isn't the best use of our time.
 [2012-08-27 14:55 UTC] sergiu dot ionescu at gmail dot com
Hello,
I have compiled PHP 5.3.16(http://kr.php.net/get/php-5.3.16.tar.bz2) and i am experiencing similar issues.

The new back-trace is:

[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x000000000068a7fb in zend_mm_remove_from_free_list (heap=0xe73290, mm_block=0x2ee4168) at /home/vagrant/php-5.3.16/Zend/zend_alloc.c:845
845                     if (UNEXPECTED(prev->next_free_block != mm_block) || UNEXPECTED(next->prev_free_block != mm_block)) {
(gdb) bt
#0  0x000000000068a7fb in zend_mm_remove_from_free_list (heap=0xe73290, mm_block=0x2ee4168) at /home/vagrant/php-5.3.16/Zend/zend_alloc.c:845
#1  0x000000000068a9ab in _zend_mm_free_int (heap=0xe73290, p=0x2ee4128) at /home/vagrant/php-5.3.16/Zend/zend_alloc.c:2029
#2  0x000000000069fcd0 in destroy_zend_class (pce=<value optimized out>) at /home/vagrant/php-5.3.16/Zend/zend_opcode.c:187
#3  0x00000000006b43d5 in zend_hash_apply_deleter (ht=0xe73be0, p=0x142dda0) at /home/vagrant/php-5.3.16/Zend/zend_hash.c:612
#4  0x00000000006b44e9 in zend_hash_reverse_apply (ht=0xe73be0, apply_func=0x69aed0 <clean_non_persistent_class>) at /home/vagrant/php-5.3.16/Zend/zend_hash.c:762
#5  0x000000000069bbbe in shutdown_executor () at /home/vagrant/php-5.3.16/Zend/zend_execute_API.c:312
#6  0x00000000006a85c2 in zend_deactivate () at /home/vagrant/php-5.3.16/Zend/zend.c:891
#7  0x0000000000654305 in php_request_shutdown (dummy=<value optimized out>) at /home/vagrant/php-5.3.16/main/main.c:1661
#8  0x0000000000733dfa in main (argc=<value optimized out>, argv=<value optimized out>) at /home/vagrant/php-5.3.16/sapi/cli/php_cli.c:1368

I am still using some on the old php5.3.2 extensions but i am upgrading the one by one - just in case i catch the culprit.

Please let me know if i can provide additional details.

Thanks.
 [2012-08-27 14:55 UTC] sergiu dot ionescu at gmail dot com
-PHP Version: PHP 5.3.2 +PHP Version: PHP 5.3.16
 [2012-08-27 16:15 UTC] sergiu dot ionescu at gmail dot com
After updating all the extensions i still get the same thing.

I extra detail i can provide is that i occasionally get 
zend_mm_heap corrupted
instead of segmentation fault

and the line where the segfault occurs is the condition line from:

#if ZEND_MM_SAFE_UNLINKING
                if (UNEXPECTED(prev->next_free_block != mm_block) || UNEXPECTED(next->prev_free_block != mm_block)) {
                        zend_mm_panic("zend_mm_heap corrupted");
                }
#endif
 [2012-08-28 02:47 UTC] laruence@php.net
could you give us a reproducable script, or scripts?  thanks, :)
 [2012-08-28 07:02 UTC] sergiu dot ionescu at gmail dot com
I could, but i think it won't help much. As i stated initially it's a cli script form a Magento/ZF application with quite a few contributed modules.

If i can get to a one file script that produces the error i will post it.
Is there anything else you can do while you don't have that?
 [2012-08-28 08:04 UTC] laruence@php.net
if I don't get a script to reproduce it, then I think,, I can do nothing.. since 
there is not much info can get from the backtrace
 [2012-08-30 16:13 UTC] sergiu dot ionescu at gmail dot com
Setting apc.enable_cli=0 so far has eliminated the issue.

I don't this fixed the underlying issue but at least it gets rid of the nasty exit code at the end on the script.
 [2012-08-30 16:39 UTC] laruence@php.net
so, this is related to apc?
 [2012-08-30 17:03 UTC] sergiu dot ionescu at gmail dot com
apc alone does not generate this.
It's related to apc+Magento+a Multi-location module for Magento...

That's why it's hard to give you a script to reproduce it.
All i can say that the specific module uses allot of weird obfuscation: eval's and other stuff you don't necessarily need.
 [2012-10-09 16:53 UTC] ahebert at pubnix dot net
I can confirm this issue happening in this situation:

. FreeBSD 8.2-p2 amd64
. Compiled ports
. PHP 5.4.6 (from ports)
. Magento 1.5.1.0

The effect we're noticing is, in the /admin section of Magento, is that while you navigate, it will stop responding:

. on the server side nothing is noticeable
. after the usual 30s timeout you will get the page back
. then you may or may not have a core dump

Digging further, it seems to come from a flock issue since I can find this sequence in all my dumps.  The stack at #28 is most likely the 30s timeout and the flock caused a dead lock.

#27 0x00000000004481bb in just_die (sig=Variable "sig" is not available.
) at prefork.c:328
#28 <signal handler called>
#29 0x000000080141f8fc in flock () from /lib/libc.so.7

More to come...
 [2012-10-10 16:38 UTC] ahebert at pubnix dot net
1 day and no core dump after changing Magento session handling from file to database.

In that case it might be related to the change to flock in 5.3.2.

Good luck
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sat Dec 05 00:01:23 2020 UTC