debugging APC - bit over my head; clue desired

php.internals

Jochem Maas

20 years ago
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

Rasmus Lerdorf

20 years ago
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

Jochem Maas

20 years ago
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

Jochem Maas

20 years ago
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:

Alan Pinstein

20 years ago
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 On Jan 5, 2006, at 7:44 AM, Jochem Maas wrote: