hi guys,
a while back I was asking about APC - I have a problem with php
seghfaulting when I use APC and turn on the opcode cache (apc_store()
and apc_fetch() work very well - I'm sticking lots of 'ResultSet' objects
in there for instance and it works very nicely) but turning the
opcode cache on (ini setting "apc.cache_by_default = 1") causes Apache (v2)
to segfault.
now I have got so far as to be able to run apache via gdb and bet some info
back from it which is as follows (it took me months to get this far!):
(apologies for the long email - it's difficult for me to judge what
information is relevant)
0x01201652 in _zend_hash_add_or_update (ht=0x99a0050, arKey=Variable "arKey" is not available.
) at /root/files/php-5.1.1/Zend/zend_hash.c:215
215 if ((p->h == h) && (p->nKeyLength == nKeyLength)) {
(gdb) continue
Continuing.
Couldn't get registers: No such process.
======================================================================
as you might see 'continue' does not work here; funnily enough if gdb is not attached
to apache then a segfault is logged in the apache error log but when it is attached
nothing is logged and everything seems to stop at the point that the output
above is produced. .... I also managed to produce a backtrace ('bt full' & 'bt'):
0x0120d9ca in _zend_hash_add_or_update (ht=0x92a5bc8, arKey=0x8eb3494 "<", nKeyLength=Variable "nKeyLength" is not
available.
)
at /root/files/php-5.1.1/Zend/zend_hash.c:248
248 INIT_DATA(ht, p, pData, nDataSize);
(gdb) bt full
#0 0x0120d9ca in _zend_hash_add_or_update (ht=0x92a5bc8, arKey=0x8eb3494 "<", nKeyLength=Variable "nKeyLength" is not
available.
)
at /root/files/php-5.1.1/Zend/zend_hash.c:248
h = 3676826139
p = Variable "p" is not available.
(gdb) bt
#0 0x0120d9ca in _zend_hash_add_or_update (ht=0x92a5bc8, arKey=0x8eb3494 "<", nKeyLength=Variable "nKeyLength" is not
available.
)
at /root/files/php-5.1.1/Zend/zend_hash.c:248
#1 0x0120db05 in _zend_hash_merge (target=0x92a5bc8, source=0x8eacaf8, pCopyConstructor=0x11f4dac <inherit_static_prop>,
tmp=0x0, size=4, overwrite=0) at /root/files/php-5.1.1/Zend/zend_hash.c:785
#2 0x011f97a5 in zend_do_inheritance (ce=0x92a5b34, parent_ce=0x8eaca64) at /root/files/php-5.1.1/Zend/zend_compile.c:2201
#3 0x011f9812 in do_bind_inherited_class (opline=0x92a2a74, class_table=0x8ccdb70, parent_ce=0x8eaca64, compile_time=1
'\001')
at /root/files/php-5.1.1/Zend/zend_compile.c:2325
#4 0x011f9995 in zend_do_early_binding () at /root/files/php-5.1.1/Zend/zend_compile.c:2382
#5 0x011ebfa2 in zendparse () at Zend/zend_language_parser.c:2742
#6 0x011eca6d in compile_file (file_handle=0xbfba1694, type=8) at Zend/zend_language_scanner.c:3166
#7 0x00f22e64 in my_compile_file (h=0xbfba1694, type=8) at /tmp/tmpnn9Dpf/APC-3.0.8/apc_main.c:281
#8 0x0122a1e2 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (execute_data=0xbfba1820)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:1862
#9 0x01225761 in execute (op_array=0x92a231c) at /root/files/php-5.1.1/Zend/zend_vm_execute.h:88
#10 0x01229f69 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (execute_data=0xbfba19e0)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:1909
#11 0x01225761 in execute (op_array=0x8f27184) at /root/files/php-5.1.1/Zend/zend_vm_execute.h:88
#12 0x012778b1 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER (execute_data=0xbfba2a80)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:7312
#13 0x01225761 in execute (op_array=0x8e0a5cc) at /root/files/php-5.1.1/Zend/zend_vm_execute.h:88
#14 0x01229f69 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (execute_data=0xbfba4200)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:1909
#15 0x01225761 in execute (op_array=0x8ecade4) at /root/files/php-5.1.1/Zend/zend_vm_execute.h:88
#16 0x01205e6f in zend_execute_scripts (type=8, retval=Variable "retval" is not available.
) at /root/files/php-5.1.1/Zend/zend.c:1090
#17 0x011d278e in php_execute_script (primary_file=0xbfba6544) at /root/files/php-5.1.1/main/main.c:1704
#18 0x01287570 in php_handler (r=0x8decb28) at /root/files/php-5.1.1/sapi/apache2handler/sapi_apache2.c:584
#19 0x0015fe8c in ap_run_handler (r=0x8decb28) at /usr/src/debug/httpd-2.0.54/server/config.c:157
#20 0x00160227 in ap_invoke_handler (r=0x8decb28) at /usr/src/debug/httpd-2.0.54/server/config.c:369
#21 0x0015cd6b in ap_process_request (r=0x8decb28) at /usr/src/debug/httpd-2.0.54/modules/http/http_request.c:249
#22 0x00157683 in ap_process_http_connection (c=0x8de68f0) at /usr/src/debug/httpd-2.0.54/modules/http/http_core.c:251
#23 0x0016a9eb in ap_run_process_connection (c=0x8de68f0) at /usr/src/debug/httpd-2.0.54/server/connection.c:43
#24 0x0016ad20 in ap_process_connection (c=0x8de68f0, csd=0x8de6818) at /usr/src/debug/httpd-2.0.54/server/connection.c:176
#25 0x0015dcfe in child_main (child_num_arg=Variable "child_num_arg" is not available.
) at /usr/src/debug/httpd-2.0.54/server/mpm/prefork/prefork.c:610
#26 0x0015df6e in make_child (s=0x8c5fe88, slot=0) at /usr/src/debug/httpd-2.0.54/server/mpm/prefork/prefork.c:650
#27 0x0015e090 in startup_children (number_to_start=16) at /usr/src/debug/httpd-2.0.54/server/mpm/prefork/prefork.c:722
#28 0x0015ea52 in ap_mpm_run (_pconf=0x8c5e0a8, plog=0x8c8a158, s=0x8c5fe88)
at /usr/src/debug/httpd-2.0.54/server/mpm/prefork/prefork.c:941
#29 0x0016577e in main (argc=2, argv=0xbfba6a14) at /usr/src/debug/httpd-2.0.54/server/main.c:619
======================================================================
I don't seem to be able to produce a 'core' file this time round but I seemed
to have a created a couple of core files the last time I tried (before I had
managed to build apache with debug info) - running those core files through gdb
shows that the same issue (APC related segfault) seems to have caused those core
files to be created (I can at least say that activating APC is the only thing
causing segfault around here atm). anyway just in case it helps here are the
backtraces from each of the (five) core files I had produced
in the the mean time if there is anyone who can give me a clue as to
how to go about getting this fixed (including providing enough/correct info
to someone actually capable of working on the php engine!) then I would be very
grateful.
/etc/httpd/core.8030
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(gdb) bt
#0 0x61656c63 in ?? ()
#1 0x006c990e in zif_apc_cache_info (ht=20856672, return_value=0x48, return_value_ptr=0xbfcfe198, this_ptr=0x1d5382,
return_value_used=6307828) at /tmp/tmpnn9Dpf/APC-3.0.8/php_apc.c:258
#2 0x0126ec6b in zend_hash_apply_deleter (ht=0x1269564, p=0xbfcfe178) at /root/files/php-5.1.1/Zend/zend_hash.c:574
#3 0x0126edab in zend_hash_graceful_reverse_destroy (ht=0x13e3f60) at /root/files/php-5.1.1/Zend/zend_hash.c:640
#4 0x01267394 in zend_shutdown () at /root/files/php-5.1.1/Zend/zend.c:709
#5 0x012344c7 in php_module_shutdown () at /root/files/php-5.1.1/main/main.c:1590
#6 0x0123456f in php_module_shutdown_wrapper (sapi_globals=0x13c8320) at /root/files/php-5.1.1/main/main.c:1565
#7 0x012e8c85 in php_apache_server_shutdown (tmp=0x0) at /root/files/php-5.1.1/sapi/apache2handler/sapi_apache2.c:330
#8 0x00db2ed5 in apr_pool_tag () from /usr/lib/libapr-0.so.0
#9 0x00db3c80 in apr_pool_clear () from /usr/lib/libapr-0.so.0
#10 0x00154624 in main (argc=3, argv=0xbfcfe374) at /usr/src/debug/httpd-2.0.54/server/main.c:576
/etc/httpd/core.24782
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#0 0x012d1c7f in php_apache_server_shutdown (tmp=0x0) at /root/files/php-5.1.1/sapi/apache2handler/sapi_apache2.c:330
330 apache2_sapi_module.shutdown(&apache2_sapi_module);
(gdb) bt
#0 0x012d1c7f in php_apache_server_shutdown (tmp=0x0) at /root/files/php-5.1.1/sapi/apache2handler/sapi_apache2.c:330
#1 0x001d3ed5 in apr_pool_tag () from /usr/lib/libapr-0.so.0
#2 0x001d4c80 in apr_pool_clear () from /usr/lib/libapr-0.so.0
#3 0x005f5624 in main (argc=3, argv=0xbf883454) at /usr/src/debug/httpd-2.0.54/server/main.c:576
/etc/httpd/core.20598
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#0 0x012d1841 in zend_isset_isempty_dim_prop_obj_handler_SPEC_VAR_VAR (prop_dim=0, execute_data=0x0)
at /root/files/php-5.1.1/Zend/zend_hash.h:346
346 return zend_hash_find(ht, arKey, nKeyLength, pData);
(gdb) bt
#0 0x012d1841 in zend_isset_isempty_dim_prop_obj_handler_SPEC_VAR_VAR (prop_dim=0, execute_data=0x0)
at /root/files/php-5.1.1/Zend/zend_hash.h:346
#1 0x00581c80 in apr_pool_clear () from /usr/lib/libapr-0.so.0
#2 0x00887624 in main (argc=3, argv=0xbfc73d54) at /usr/src/debug/httpd-2.0.54/server/main.c:576
/etc/httpd/core.23991
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#0 0x012cf26f in ZEND_UNSET_DIM_SPEC_VAR_VAR_HANDLER (execute_data=0x86cf138)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:11890
11890 if (free_op2.var) {zval_ptr_dtor(&free_op2.var);};
(gdb) bt
#0 0x012cf26f in ZEND_UNSET_DIM_SPEC_VAR_VAR_HANDLER (execute_data=0x86cf138)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:11890
#1 0x00eecc80 in apr_pool_clear () from /usr/lib/libapr-0.so.0
#2 0x0024f624 in main (argc=3, argv=0xbf95b1d4) at /usr/src/debug/httpd-2.0.54/server/main.c:576
/etc/httpd/core.21475
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#0 0x01251822 in ldap_str2objectclass () at /root/files/php-5.1.1/Zend/zend_hash.h:345
345 HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_find(ht, idx, pData));
(gdb) bt
#0 0x01251822 in ldap_str2objectclass () at /root/files/php-5.1.1/Zend/zend_hash.h:345
#1 0x20b8009b in ?? ()
#2 0xffff08b8 in ?? ()
#3 0x8238ffff in ?? ()
#4 0x90b408b7 in ?? ()
#5 0x000000c9 in ?? ()
#6 0x00000000 in ?? ()
/etc/httpd/core.5073
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#0 0x012c4748 in zend_isset_isempty_dim_prop_obj_handler_SPEC_VAR_VAR (prop_dim=0, execute_data=0x0)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:11998
11998 if (!isset || !i_zend_is_true(*value)) {
(gdb) bt
#0 0x012c4748 in zend_isset_isempty_dim_prop_obj_handler_SPEC_VAR_VAR (prop_dim=0, execute_data=0x0)
at /root/files/php-5.1.1/Zend/zend_vm_execute.h:11998
#1 0x0075ec80 in apr_pool_clear () from /usr/lib/libapr-0.so.0
#2 0x00cb5624 in main (argc=3, argv=0xbff159c4) at /usr/src/debug/httpd-2.0.54/server/main.c:576
======================================================================
rgds,
Jochem
Jochem Maas wrote:
a while back I was asking about APC - I have a problem with php
seghfaulting when I use APC and turn on the opcode cache (apc_store()
and apc_fetch() work very well - I'm sticking lots of 'ResultSet' objects
in there for instance and it works very nicely)
Note that caching arrays is way faster than caching objects, so if at
all possible, convert your ResultSet object to an associative array
before storing it.
To fix your segfault I'll need a short PHP script that reproduces the
problem. On one hand I bet an <?php echo "hello world"?> script doesn't
crash it, and on the other you have whatever code you are running that
does. Step up from Hello World slowly until it starts crashing and send
me that.
-Rasmus
Rasmus Lerdorf wrote:
Jochem Maas wrote:
a while back I was asking about APC - I have a problem with php
seghfaulting when I use APC and turn on the opcode cache (apc_store()
and apc_fetch() work very well - I'm sticking lots of 'ResultSet'
objects
in there for instance and it works very nicely)Note that caching arrays is way faster than caching objects, so if at
all possible, convert your ResultSet object to an associative array
before storing it.
I need the object at run time to make the whole lot transparent.
but given the speed increase I get from not having to make crazy
database calls (my lack of skill/foresight coupled with
strange/impossible/arcane marketing/sales driven requirements :-)
I'm still happy - thanks for the tip though! noted for future use.
To fix your segfault I'll need a short PHP script that reproduces the
problem. On one hand I bet an <?php echo "hello world"?> script doesn't
crash it, and on the other you have whatever code you are running that
does. Step up from Hello World slowly until it starts crashing and send
me that.
I know the problem lies somewhere in the 194 classes I have in the project.
I have been trying to reproduce the problem in a short case for months, having
just found out that its the classes ->
apc.filters = -.*.class.php
that line allows me to use apc; so now apc has saved my neck. thank you btw.
anyway I'll try to figure out a way to test the classes in as near to isolation
as I can get to figure out what is going wrong - once you know that the reproduce
script is usually quite easy.
(any examples for apc.filters in the docs would be super, also an quick
explaination on apc.dynamic_errors)
kind regards,
Jochem
ps - IIRC (forgive me if I'm wrong) you yourself asked for the backtrace, but it
took a while for me to figure out how to create one and successfully do it,
2 months :-P
-Rasmus
Rasmus,
I have a quick question which if you are able to
give an answer to will hopefully help to (finally)
create a repro. script for the afore mentioned apc segfault.
I am 99.9% sure that the apc opcode cache is not likely some/one
of my classes. but that leaves 194 odd files to check (upto 200,000
lines of code) and I have no idea where to begin. so the question is
do you know of any class related syntax (or whatever) that is likely
to be causing the segfaulting?
a hint about the most likely place to start looking (e.g.
inheritance, interface implementation, method visibility, etc)
would be very welcome. of course I can understand if you felt that
there was no one 'thing' more likely to be the culprit than another.
kind rgds,
Jochem
Rasmus Lerdorf wrote:
Jochem Maas wrote:
a while back I was asking about APC - I have a problem with php
seghfaulting when I use APC and turn on the opcode cache (apc_store()
and apc_fetch() work very well - I'm sticking lots of 'ResultSet'
objects
in there for instance and it works very nicely)Note that caching arrays is way faster than caching objects, so if at
all possible, convert your ResultSet object to an associative array
before storing it.To fix your segfault I'll need a short PHP script that reproduces the
problem. On one hand I bet an <?php echo "hello world"?> script doesn't
crash it, and on the other you have whatever code you are running that
does. Step up from Hello World slowly until it starts crashing and send
me that.
-Rasmus
Yes, I'd be interested in this, too. I filed a bug report for a
segfault under similar conditions and I'd be happy to help find the
bug if I had any idea how to help...
Alan
Rasmus,
I have a quick question which if you are able to
give an answer to will hopefully help to (finally)
create a repro. script for the afore mentioned apc segfault.I am 99.9% sure that the apc opcode cache is not likely some/one
of my classes. but that leaves 194 odd files to check (upto 200,000
lines of code) and I have no idea where to begin. so the question is
do you know of any class related syntax (or whatever) that is likely
to be causing the segfaulting?a hint about the most likely place to start looking (e.g.
inheritance, interface implementation, method visibility, etc)
would be very welcome. of course I can understand if you felt that
there was no one 'thing' more likely to be the culprit than another.kind rgds,
JochemRasmus Lerdorf wrote:
Jochem Maas wrote:
a while back I was asking about APC - I have a problem with php
seghfaulting when I use APC and turn on the opcode cache
(apc_store()
and apc_fetch() work very well - I'm sticking lots of
'ResultSet' objects
in there for instance and it works very nicely)
Note that caching arrays is way faster than caching objects, so if
at all possible, convert your ResultSet object to an associative
array before storing it.
To fix your segfault I'll need a short PHP script that reproduces
the problem. On one hand I bet an <?php echo "hello world"?>
script doesn't crash it, and on the other you have whatever code
you are running that does. Step up from Hello World slowly until
it starts crashing and send me that.-Rasmus