Any chance to get some code reproducing this?

Unfortunately i cannot pinpoint any part in the code that causes this.  The 
segfault also occurs in shutdown so there is no specific code "causing" the 
issue. What i noticed though is that the bug only occurs when the request has 
been issued a second time. The first execution is fine. I retried with php 5.4.5 
and APC 3.1.11 and i still get the same error:
#0  _zend_mm_free_int (heap=0x1a8b330, p=0x30fcb38) at /usr/local/src/php/php-
5.4.5/php-5.4.5/Zend/zend_alloc.c:2100
#1  0x00000000007a9ae5 in _zval_dtor (zval_ptr=0x3162088) at 
/usr/local/src/php/php-5.4.5/php-5.4.5/Zend/zend_variables.h:35
#2  _zval_ptr_dtor (zval_ptr=0x3162088) at /usr/local/src/php/php-5.4.5/php-
5.4.5/Zend/zend_execute_API.c:438
#3  0x00007fc18f45e64f in apc_free_class_entry_after_execution (src=0x315fe50) 
at /usr/local/src/php/php-5.4-extensions/APC-3.1.11/apc_compile.c:1836
#4  0x00007fc18f46168c in apc_deactivate () at /usr/local/src/php/php-5.4-
extensions/APC-3.1.11/apc_main.c:956
#5  apc_request_shutdown () at /usr/local/src/php/php-5.4-extensions/APC-
3.1.11/apc_main.c:1012
#6  0x00007fc18f457fb5 in zm_deactivate_apc (type=27833136, 
module_number=51366712) at /usr/local/src/php/php-5.4-extensions/APC-
3.1.11/php_apc.c:407
#7  0x00000000007bc404 in zend_deactivate_modules () at /usr/local/src/php/php-
5.4.5/php-5.4.5/Zend/zend_API.c:2333
#8  0x000000000075bb35 in php_request_shutdown (dummy=<value optimized out>) at 
/usr/local/src/php/php-5.4.5/php-5.4.5/main/main.c:1750
#9  0x000000000085d3fa in main (argc=<value optimized out>, argv=<value 
optimized out>) at /usr/local/src/php/php-5.4.5/php-
5.4.5/sapi/cgi/cgi_main.c:2498

Is apc_bin_dump() function used in your code?

no this function is not used anywhere

ok, could you please post your APC config as well?

we do not have any special config, currently only:
apc.shm_size=128M

is set.

I should be asking for this at once, but ... could you also post the APC 
configure options and phpinfo? :)

sure :)
APC was just compiled with --enable-apc and no further special options. 
PHPinfo APC info:
apc

APC Support	enabled
Version	3.1.11
APC Debugging	Disabled
MMAP Support	Enabled
MMAP File Mask	no value
Locking type	pthread mutex Locks
Serialization Support	php
Revision	$Revision: 325875 $
Build Date	Jul 26 2012 11:35:03

Directive	Local Value	Master Value
apc.cache_by_default	On	On
apc.canonicalize	On	On
apc.coredump_unmap	Off	Off
apc.enable_cli	Off	Off
apc.enabled	On	On
apc.file_md5	Off	Off
apc.file_update_protection	2	2
apc.filters	no value	no value
apc.gc_ttl	3600	3600
apc.include_once_override	Off	Off
apc.lazy_classes	Off	Off
apc.lazy_functions	Off	Off
apc.max_file_size	1M	1M
apc.mmap_file_mask	no value	no value
apc.num_files_hint	1000	1000
apc.preload_path	no value	no value
apc.report_autofilter	Off	Off
apc.rfc1867	Off	Off
apc.rfc1867_freq	0	0
apc.rfc1867_name	APC_UPLOAD_PROGRESS	APC_UPLOAD_PROGRESS
apc.rfc1867_prefix	upload_	upload_
apc.rfc1867_ttl	3600	3600
apc.serializer	default	default
apc.shm_segments	1	1
apc.shm_size	128M	128M
apc.shm_strings_buffer	4M	4M
apc.slam_defense	On	On
apc.stat	On	On
apc.stat_ctime	Off	Off
apc.ttl	0	0
apc.use_request_time	On	On
apc.user_entries_hint	4096	4096
apc.user_ttl	0	0
apc.write_lock	On	On

Thank you very much )

I'll try to make a reproduce case based on your traces. May be you could also try 
it - just a small test case not exposing your real code.

As a hint - it appears from the traces, that the crash is caused by freeing of 
the class properties. There is almost always a php code which makes a bug 
visible. In this case some code is cached but not properly freed.

Using sessions? There is a known chicken+egg problem with PHP+APC that can cause 
problems with session objects. The fix is to call session_write_close() when you 
no longer need anything from the session to force session closure before request 
shutdown.

We tried to place session_write_close() at the end of our code, The issue still 
occurs though.

Please produce a fresh BT with the current APC trunk.

Program received signal SIGSEGV, Segmentation fault.
_zend_mm_free_int (heap=0x10b4330, p=0x2077f88) at /usr/local/src/php/php-
5.4.5/php-5.4.5/Zend/zend_alloc.c:2100
2100		if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0  _zend_mm_free_int (heap=0x10b4330, p=0x2077f88) at /usr/local/src/php/php-
5.4.5/php-5.4.5/Zend/zend_alloc.c:2100
#1  0x00000000007a9ae5 in _zval_dtor (zval_ptr=0x19070d8) at 
/usr/local/src/php/php-5.4.5/php-5.4.5/Zend/zend_variables.h:35
#2  _zval_ptr_dtor (zval_ptr=0x19070d8) at /usr/local/src/php/php-5.4.5/php-
5.4.5/Zend/zend_execute_API.c:438
#3  0x00007fe6cda1e25f in apc_free_class_entry_after_execution (src=0x212a278) 
at /usr/local/src/php/php-5.4-extensions/apc-svn/apc_compile.c:2015
#4  0x00007fe6cda217ec in apc_deactivate () at /usr/local/src/php/php-5.4-
extensions/apc-svn/apc_main.c:948
#5  apc_request_shutdown () at /usr/local/src/php/php-5.4-extensions/apc-
svn/apc_main.c:1042
#6  0x00007fe6cda17585 in zm_deactivate_apc (type=17515312, 
module_number=34045832) at /usr/local/src/php/php-5.4-extensions/apc-
svn/php_apc.c:407
#7  0x00000000007bc404 in zend_deactivate_modules () at /usr/local/src/php/php-
5.4.5/php-5.4.5/Zend/zend_API.c:2333
#8  0x000000000075bb35 in php_request_shutdown (dummy=<value optimized out>) at 
/usr/local/src/php/php-5.4.5/php-5.4.5/main/main.c:1750
#9  0x000000000085d3fa in main (argc=<value optimized out>, argv=<value 
optimized out>) at /usr/local/src/php/php-5.4.5/php-
5.4.5/sapi/cgi/cgi_main.c:2498 

this is the new backtrace with apc-trunk

Thanks for the new trace. Hardly trying to repro this but still no result.

I've made some tests with trait and class inheritance mixing default properties. 
May be you could give me a little hint looking through your code where default 
class properties are defined some tricky way.

Also you've mentioned the patch from #62190 - is this part essential for your 
app? May be the bug is hidden in the part of the code using DOM.

Looks like some boringly normal code can't repro this. But as the last trace 
says - that's definitely something inside class default props. Of course it 
might be some internal class.

Thanks for your help, will try more myself.

Thanks for taking a further look. The Fix mentioned in 62190 was required to run 
our code properly, but this occurred in another part of the code.

Yep, which part of the application? The information like how the default class 
properties are defined (may be something tricky), may be if there are some 
classes which extend internal classes, are traits used and so on. It could aim at 
a potential bug source, as I had no luck reproducing that using some regular 
snippets.

we verified again with php 5.4.7 and apc 3.1.13. The Bug still occurs:

#0  _zend_mm_free_int (heap=0x125c330, p=0x199c1d8) at /usr/local/src/php/php-
5.4.7/Zend/zend_alloc.c:2100
#1  0x00000000007c59ad in zend_hash_update_current_key_ex (ht=0x199c0d0, 
key_type=1, str_index=0x1a2e860 "hostnameDashCharacter", str_length=<value 
optimized out>, num_index=0, mode=<value optimized out>, pos=0x0) at 
/usr/local/src/php/php-5.4.7/Zend/zend_hash.c:1394
#2  0x00000000007acf7b in zend_symtable_update_current_key_ex (pp=<value 
optimized out>, arg=<value optimized out>, scope=0x0) at /usr/local/src/php/php-
5.4.7/Zend/zend_hash.h:378
#3  zval_update_constant_ex (pp=<value optimized out>, arg=<value optimized 
out>, scope=0x0) at /usr/local/src/php/php-5.4.7/Zend/zend_execute_API.c:662
#4  0x00000000007bf582 in zend_update_class_constants (class_type=0x1ab5a20) at 
/usr/local/src/php/php-5.4.7/Zend/zend_API.c:1037
#5  0x00000000007bf779 in _object_and_properties_init (arg=0x1a62898, 
class_type=0x1ab5a20, properties=0x0) at /usr/local/src/php/php-
5.4.7/Zend/zend_API.c:1124
#6  0x0000000000805c7b in ZEND_NEW_SPEC_HANDLER (execute_data=0x7fa1df8e4760) at 
/usr/local/src/php/php-5.4.7/Zend/zend_vm_execute.h:813
#7  0x000000000081db40 in execute (op_array=0x1ab68d8) at 
/usr/local/src/php/php-5.4.7/Zend/zend_vm_execute.h:410
#8  0x00000000007b72ae in zend_execute_scripts (type=8, retval=<value optimized 
out>, file_count=3) at /usr/local/src/php/php-5.4.7/Zend/zend.c:1286
#9  0x000000000075c2ee in php_execute_script (primary_file=<value optimized 
out>) at /usr/local/src/php/php-5.4.7/main/main.c:2473
#10 0x000000000085e620 in main (argc=<value optimized out>, argv=<value 
optimized out>) at /usr/local/src/php/php-5.4.7/sapi/cgi/cgi_main.c:2447

we are still trying to create a small testcase

That backtrace has some useful info to help make your testcase. It is dealing 
with a class constant named hostnameDashCharacter

Here's a "small" test case. Extract, point your webserver to ./apccrash/pub and navigate your browser to index.php. This reliably produces the trace above.
It's a little bigger because it contains Agavi and Zend.
https://docs.google.com/open?id=0B61tGWnMjpxqWm8zcU0zVXVSeGs

As a workaround, try to replace the INVALID constant in the $messageTemplates 
array in Zend_Validate_Hostname (or in Zend\Validator\Hostname in ZF2) with a 
string representation.


Like this:

diff --git 
a/vendor/zendframework/zendframework/library/Zend/Validator/Hostname.php 
b/vendor/zendframework/zendframework/library/Zend/Validator/Hostname.php
index d780cd5..a7d1153 100644
--- a/vendor/zendframework/zendframework/library/Zend/Validator/Hostname.php
+++ b/vendor/zendframework/zendframework/library/Zend/Validator/Hostname.php
@@ -44,7 +44,7 @@ class Hostname extends AbstractValidator
      */
     protected $messageTemplates = array(
         self::CANNOT_DECODE_PUNYCODE  => "The input appears to be a DNS hostname 
but the given punycode notation cannot be decoded",
-        self::INVALID                 => "Invalid type given. String expected",
+        'hostnameInvalid'             => "Invalid type given. String expected",
         self::INVALID_DASH            => "The input appears to be a DNS hostname 
but contains a dash in an invalid position",
         self::INVALID_HOSTNAME        => "The input does not match the expected 
structure for a DNS hostname",
         self::INVALID_HOSTNAME_SCHEMA => "The input appears to be a DNS hostname 
but cannot match against hostname schema for TLD '%tld%'",

Hi

I got this problem as well, and surprisingly the fix lstrojny@php.net posted 
works...

I am testing this with the ZF2 Skeleton Application 
(https://github.com/zendframework/ZendSkeletonApplication), which I just 
downloaded and ran without any code modifications.

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 "Open". Thank you.