php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18044 apache child segfaults on page using sessions
Submitted: 2002-06-28 10:24 UTC Modified: 2002-10-24 01:00 UTC
Votes:44
Avg. Score:5.0 ± 0.3
Reproduced:43 of 43 (100.0%)
Same Version:8 (18.6%)
Same OS:4 (9.3%)
From: mgriego at utdallas dot edu Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.2.1 OS: RedHat Linux 7.2
Private report: No CVE-ID: None
 [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).

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-17 10:58 UTC] david+php dot net at blue-labs dot org
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.
 [2002-07-17 11:36 UTC] sniper@php.net
Try this snapshot:

http://snaps.php.net/php4-latest.tar.gz

 [2002-08-13 12:46 UTC] darkfire at yourmojo dot com
I am using the snapshot "php4-200207240900".

And this problem is still occurring.

This is an extremely serious bug. I have to restart Apache every 2 to 3 days.

Please look into this.
 [2002-08-13 12:47 UTC] rasmus@php.net
Does it happen with Zend Optimizer turned off?
 [2002-08-13 19:40 UTC] glerma at dal dot dset dot com
I'm having similar problem. Here is a backtrace of my Apache Core file.  I had originally reported to bugzilla.apache.org, but they referred the backtrace to php.

Basically, the systems are the same as mgriego's. Seg Faults occur after about a day or sometimes even several hours of running apache w/PHP 4.2.2 parsed-pages.

Here are my build specs:

I am using the following components with Apache Web Server 1.3.26 on a Solaris 
9 platform:
openssl-engine-0.9.6d
mm-1.1.3
mod_ssl-2.8.10-1.3.26
php-4.2.2

I will also include backtrace given to apache dudes:
Output from gdb backtrace:

#0  ps_mm_destroy (data=0x1091b8) at mod_mm.c:241
#1  0xfeca8348 in zm_shutdown_ps_mm (type=0, module_number=10) at mod_mm.c:293
#2  0xfec56eac in module_destructor (module=0x113650) at zend_API.c:1127
#3  0xfec59014 in zend_hash_destroy (ht=0xfed6ee7c) at zend_hash.c:541
#4  0xfec53d98 in zend_shutdown () at zend.c:490
#5  0xfec6289c in php_module_shutdown () at main.c:1050
#6  0xfec6284c in php_module_shutdown_wrapper (sapi_globals=0x0) at main.c:1027
#7  0xfec5fd48 in apache_php_module_shutdown_wrapper () at mod_php4.c:795
#8  0x1a9f0 in run_cleanups ()
#9  0x1825c in ap_clear_pool ()
#10 0x182f0 in ap_destroy_pool ()
#11 0x18244 in ap_clear_pool ()
#12 0x182f0 in ap_destroy_pool ()
#13 0x2e9c8 in clean_parent_exit ()
#14 0x32a7c in standalone_main ()
#15 0x33278 in main ()


I would like to further investigation of this problem. Seems maybe to me mm-releted to me at this point. I too am using sessions (session_start())

If more tracing is needed, please reply. THanks
-George
 [2002-08-14 12:34 UTC] glerma at dal dot dset dot com
I also wanted to point out that I'm not using Zend Optimizer as mgriego.

I had opened a new ticket on this, but was told to use this ticket as a reference.

I hope to stimulate more discusstion on this.Is there anything that can be seen with the backtrace I provided, or is more tracing needed????
 [2002-08-14 17:38 UTC] darkfire at yourmojo dot com
I am also not using the Zend Optimizer.

Trying out snapshot 'php4-200208130900'.

I'll let you know what happens.
 [2002-08-16 11:54 UTC] glerma at dal dot dset dot com
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 main
 [2002-08-16 11:58 UTC] kalowsky@php.net
There have been some bug fixes in the CVS non-STABLE version, can you please try them and see if this continues for you?
 [2002-08-20 14:23 UTC] glerma at dal dot dset dot com
Which 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.
 [2002-08-23 13:04 UTC] darkfire at yourmojo dot com
With build "php4-200208130900" the seg faults are still occuring.
 [2002-08-30 15:58 UTC] glerma at dal dot dset dot com
Anybody have any updates on this? I was just wondering if there have been any new developments regarding the seg faults when using mm_mod to store session data?
 [2002-09-03 16:18 UTC] darkfire at yourmojo dot com
Yep.

Here's an update.

The segfaults are still happening.
 [2002-09-17 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2002-09-17 13:34 UTC] james dot jones at firstinvestors dot com
This appears to be similar to my submitted bug #19456, except that mine occurs on ODBC calls. Is this still being looked at?
 [2002-09-17 15:15 UTC] kalowsky@php.net
changing this back to Open as there was feedback, but the user didn't update things.
 [2002-09-19 13:10 UTC] kalowsky@php.net
So this is happening with 4.2.3?
 [2002-10-08 21:41 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-10-24 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Oct 05 03:01:28 2024 UTC