|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2002-06-28 10:24 UTC] mgriego at utdallas dot edu
Unfortunately, I can't provide a GDB backtrace, because this bug takes a while to manifest itself. It always seems to start about a day after apache has been started up. When using the apache PHP module, I get Segmentation Fault errors in the error_log, but the page is sent to the browser, so I'm guessing the fault happens when PHP tries to serialize the data. I'm using MM for my session handler. I was, however, able to get an strace of an apache child right before it crashed, and here's a snippet right before the SIGSEGV:
[pid 10975] connect(9, {sin_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("129.110.21.10")}}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 10975] select(1024, NULL, [9], NULL, NULL) = 1 (out [9])
[pid 10975] getpeername(9, {sin_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("129.110.21.10")}}, [16]) = 0
[pid 10975] fcntl64(0x9, 0x3, 0x40688842, 0) = 2050
[pid 10975] fcntl64(0x9, 0x4, 0x2, 0) = 0
[pid 10975] getpeername(9, {sin_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("129.110.21.10")}}, [16]) = 0
[pid 10975] socket(PF_UNIX, SOCK_STREAM, 0) = 10
[pid 10975] connect(10, {sin_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = 0
[pid 10975] write(10, "\2\0\0\0\6\0\0\0\4\0\0\0", 12) = 12
[pid 10975] write(10, "\201n\25\n", 4) = 4
[pid 10975] read(10, "\0\0\0\0\1\0\0\0\22\0\0\0\0\0\0\0\2\0\0\0\4\0\0\0\2\0\0"..., 32) = 32
[pid 10975] readv(10, [{"ldap.utdallas.edu\0", 18}, {"", 0}, {"\201n\25\n\201n\25\1", 8}], 3) = 26
[pid 10975] read(10, NULL, 0) = 0
[pid 10975] close(10) = 0
[pid 10975] uname({sys="Linux", node="hebron", ...}) = 0
[pid 10975] time(NULL) = 1025273360
[pid 10975] write(9, "0B\2\1\1`=\2\1\2\4.jamsid=1000007408,ou"..., 68) = 68
[pid 10975] select(1024, [9], [], NULL, NULL) = 1 (in [9])
[pid 10975] read(9, "0\f\2\1\1a\7\n\1\0\4\0\4\0", 16384) = 14
[pid 10975] time(NULL) = 1025273360
[pid 10975] fcntl64(0x6, 0x7, 0x4008753c, 0) = 0
[pid 10975] fcntl64(0x6, 0x7, 0x4008755c, 0x4282f034) = 0
[pid 10975] time([1025273360]) = 1025273360
[pid 10975] fcntl64(0x6, 0x7, 0x4008754c, 0x1) = 0
[pid 10975] --- SIGSEGV (Segmentation fault) ---
Basicall, what's happening here, is that the page is doing an authentication off a local LDAP server. That last fcntl64 right before the process segfaults is done on file descriptor 6, which according to /proc/10975/fd is /tmp/session_mm_apache0.sem, the MM session handler semaphore. I'm at a loss here as it, like I said, does not manifest itself until about a day apache is started (which could be because it receives a certain number if hits to the session shared memory segment).
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Nov 02 19:00:02 2025 UTC |
Please help, this is rather urgent. All session pages cause a child segfault in apache. Code needed: <? session_start(); ?> Apache 1.3.26, PHP 4.2.1 (and 4.3.0 w/ zend opt on front page of php.net) Backtrace: Program received signal SIGSEGV, Segmentation fault. php_url_scanner_ex_activate () at url_scanner_ex.c:826 826 url_scanner_ex.c: No such file or directory. in url_scanner_ex.c (gdb) bt #0 php_url_scanner_ex_activate () at url_scanner_ex.c:826 #1 0x404b3a1d in posix_class_maps () from /usr/local/apache/libexec/libphp4.so #2 0x403b2900 in zif_session_start (ht=0, return_value=0x40536a60, this_ptr=0x0, return_value_used=0) at session.c:1349 #3 0x403354aa in execute (op_array=0x823e02c) at zend_execute.c:1598 #4 0x40344b4f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #5 0x40357f21 in php_execute_script (primary_file=0xbffff240) at main.c:1381 #6 0x403535d7 in apache_php_module_main (r=0x812b3a4, display_source_mode=0) at sapi_apache.c:90 #7 0x40353fe6 in send_php (r=0x812b3a4, display_source_mode=0, filename=0x0) at mod_php4.c:575 #8 0x40354225 in send_parsed_php (r=0x812b3a4) at mod_php4.c:590 #9 0x080844c3 in ap_invoke_handler (r=0x812b3a4) at http_config.c:517 #10 0x080962e4 in process_request_internal (r=0x812b3a4) at http_request.c:1308 #11 0x08096564 in ap_process_request (r=0x812b3a4) at http_request.c:1324 #12 0x0808ee0e in child_main (child_num_arg=0) at http_main.c:4681 #13 0x0808f058 in make_child (s=0x0, slot=0, now=0) at http_main.c:4805 #14 0x0808f0cf in startup_children (number_to_start=30) at http_main.c:4887 #15 0x0808fb6a in standalone_main (argc=3, argv=0xbffff6d4) at http_main.c:5195 #16 0x080900b8 in main (argc=0, argv=0x1e) at http_main.c:5558 I can provide build scripts for both apache and php. Again, please look into this promptly -- I'll help all I can. I have several sites that rely on sessions and they are all broken at the moment.Yeah. I've downloaded as well. I guess Im going to try it out for a day or two to see if all goes well. I sure would like to keep mm in my config profile, because of the way it stores the session info in shared memory rather than using a plain text(non-encrypted) file, but if things don't pan out, i guess i wont. I dont seem to have any core dumps from Apache when I compile PHP without the --enable-mm option BTW - Here is my latest backtrace. If any light can be shed, that would be great. (gdb) bt #0 ps_gc_mm (mod_data=0x109118, maxlifetime=1000, nrdels=0xffbfc80c) at mod_mm.c:414 #1 0xfeca5970 in php_session_start () at session.c:960 #2 0xfeca70c4 in zif_session_start (ht=0, return_value=0x38ca08, this_ptr=0x0, return_value_used=0) at session.c:1349 #3 0xfec44f38 in execute () from /data2/www/i-webdev1/apache/libexec/libphp4.so #4 0xfec476ac in execute () from /data2/www/i-webdev1/apache/libexec/libphp4.so #5 0xfec54888 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #6 0xfec63748 in php_execute_script (primary_file=0xffbff408) at main.c:1381 #7 0xfec5ebb8 in apache_php_module_main (r=0xffffffff, display_source_mode=0) at sapi_apache.c:90 #8 0xfec5f6e8 in send_php (r=0x11dc90, display_source_mode=0, filename=0x0) at mod_php4.c:575 #9 0x1f780 in ap_invoke_handler () #10 0x3eae0 in process_request_internal () #11 0x3eb68 in ap_process_request () #12 0x31760 in child_main () #13 0x31b04 in make_child () #14 0x31c18 in startup_children () #15 0x3262c in standalone_main () ---Type <return> to continue, or q <return> to quit--- #16 0x33278 in mainWhich bug fixes is this? Where can I find the CVS "non-stable" build? Incidentally, I have tried the PHP-Latest build dated php4-200208131500, compiled using same configure parameters as above. I recieved the same segmenation faults with this build(php4-200208131500). Here is my bt of the apache core file: (gdb) bt #0 ps_sd_lookup (data=0x11efd0, key=0x2b1288 "cfb22d50a65ce80d4af8df54f837ea90", rw=0) at mod_mm.c:187 #1 0xfe9a83cc in ps_read_mm (mod_data=0x11efd0, key=0x2b1288 "cfb22d50a65ce80d4af8df54f837ea90", val=0xffbfc7ac, vallen=0xffbfc7a8) at mod_mm.c:326 #2 0xfe9a4938 in php_session_initialize () at session.c:557 #3 0xfe9a5904 in php_session_start () at session.c:953 #4 0xfe9a70c4 in zif_session_start (ht=0, return_value=0x234da8, this_ptr=0x0, return_value_used=0) at session.c:1349 #5 0xfe944f38 in execute () from /data2/www/e-webdev1/apache/libexec/libphp4.so #6 0xfe9476ac in execute () from /data2/www/e-webdev1/apache/libexec/libphp4.so #7 0xfe954888 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #8 0xfe963748 in php_execute_script (primary_file=0xffbff420) at main.c:1381 #9 0xfe95ebb8 in apache_php_module_main (r=0xffffffff, display_source_mode=0) at sapi_apache.c:90 #10 0xfe95f6e8 in send_php (r=0x141ef8, display_source_mode=0, filename=0x0) at mod_php4.c:575 #11 0x1f780 in ap_invoke_handler () #12 0x3eae0 in process_request_internal () #13 0x3eb68 in ap_process_request () ---Type <return> to continue, or q <return> to quit--- #14 0x31760 in child_main () #15 0x31b04 in make_child () #16 0x31c18 in startup_children () #17 0x3262c in standalone_main () #18 0x33278 in main () Please advise. Thanks in advance.