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.

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.

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!

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.

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.

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

could you give us a reproducable script, or scripts?  thanks, :)

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?

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

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.

so, this is related to apc?

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.

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...

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

Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>

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.