php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #59763 Segmentation fault in mmc_ascii_end_get
Submitted: 2011-05-11 17:57 UTC Modified: 2021-02-21 04:22 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: martin at ringehahn dot de Assigned: cmb (profile)
Status: No Feedback Package: memcache (PECL)
PHP Version: 5.3.4 OS: FreeBSD 8.2-RELEASE
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2011-05-11 17:57 UTC] martin at ringehahn dot de
Description:
------------
Segmentation Fault. Dereferencing a null pointer.


#0  mmc_ascii_end_get (request=0x0) at 
/usr/local/src/memcache-3.0.6/memcache_ascii_protocol.c:247
247             smart_str_appendl(&(request->sendbuf.value), 
"\r\n", sizeof("\r\n")-1);

(gdb) bt
#0  mmc_ascii_end_get (request=0x0) at 
/usr/local/src/memcache-3.0.6/memcache_ascii_protocol.c:247
#1  0x29330e81 in mmc_pool_run (pool=0x31b59a34) at 
/usr/local/src/memcache-3.0.6/memcache_pool.c:1664
#2  0x2932b723 in php_mmc_store (ht=Variable "ht" is not 
available.
) at /usr/local/src/memcache-3.0.6/memcache.c:521
#3  0x28964e99 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x31a08cc4) at zend_vm_execute.h:316
#4  0x2893e850 in execute (op_array=0x31b15174) at 
zend_vm_execute.h:107
#5  0x2891a884 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/local/src/php-5.3.4/Zend/zend.c:1266
#6  0x288c8439 in php_execute_script 
(primary_file=0x7fbfe7a0) at /usr/local/src/php-
5.3.4/main/main.c:2280
#7  0x2899cb5e in php_handler (r=0x298b5058) at 
/usr/local/src/php-
5.3.4/sapi/apache2handler/sapi_apache2.c:673
#8  0x08078319 in ap_run_handler (r=0x298b5058) at 
config.c:157
#9  0x0807b5ee in ap_invoke_handler (r=0x298b5058) at 
config.c:376
#10 0x080b2af0 in ap_process_request (r=0x298b5058) at 
http_request.c:282
#11 0x080afc6b in ap_process_http_connection (c=0x2988b1f0) 
at http_core.c:190
#12 0x0807f609 in ap_run_process_connection (c=0x2988b1f0) 
at connection.c:43
#13 0x080cef4e in child_main (child_num_arg=Variable 
"child_num_arg" is not available.
) at prefork.c:662
#14 0x080cf237 in make_child (s=0x28415870, slot=19) at 
prefork.c:763
#15 0x080cfbe7 in ap_mpm_run (_pconf=0x2840f018, 
plog=0x2845b018, s=0x28415870) at prefork.c:898
#16 0x08065ad5 in main (argc=675336216, argv=0x29889018) at 
main.c:739

details on the mmc_t item it popped off the pending queue 
and tries to process:

print *(mmc_t *) pool.pending.items[pool.pending.tail-1]
$18 = {
  tcp = {
    stream = 0x0, 
    fd = 0, 
    port = 8080, 
    chunk_size = 32768, 
    status = -1, 
    failed = 1305144371, 
    retry_interval = -1, 
    buffer = {
      value = {
        c = 0x0, 
        len = 0, 
        a = 0
      }, 
      idx = 0
    }, 
    read = 0x2932e690 <mmc_stream_read_wrapper>, 
    readline = 0x2932eca0 <mmc_stream_readline_wrapper>, 
    input = {
      value = '\0' <repeats 4095 times>, 
      idx = 0
    }
  }, 
  udp = {
    stream = 0x0, 
    fd = 0, 
    port = 0, 
    chunk_size = 32768, 
    status = -1, 
    failed = 1305144371, 
    retry_interval = 2, 
    buffer = {
      value = {
        c = 0x0, 
        len = 0, 
        a = 0
      }, 
      idx = 0
    }, 
    read = 0, 
    readline = 0, 
    input = {
      value = '\0' <repeats 4095 times>, 
      idx = 0
    }
  }, 
  sendreq = 0x0, 
  readreq = 0x0, 
  buildreq = 0x0, 
  sendqueue = {
    items = 0x0, 
    alloc = 0, 
    head = 0, 
    tail = 0, 

    len = 0
  }, 
  readqueue = {
    items = 0x0, 
    alloc = 0, 
    head = 0, 
    tail = 0, 
    len = 0
  }, 
  host = 0x319ad2a0 "192.168.1.143", 
  timeout = {
    tv_sec = 1, 
    tv_usec = 0
  }, 
  persistent = 0, 
  reqid = 0, 
  error = 0x31b17640 "Network timeout", 
  errnum = 0
}

Yes, port 8080 is correct. There is a memcached running 
there.

Reproduce code:
---------------
Don't have code to reproduce, since it happens very rarely. Hoping the gdb dump helps.

We _do_ sometimes have network connectivity issues. By looking at the bt, we can see this happens in a store() call. I assume there were successful get() calls on that pool before the store(), so the connection worked at some point during the request.

Blind assumption: closing of the socket after the tcp connection has been established is not being handled correctly.

Expected result:
----------------
Fail gracefully.

Actual result:
--------------
Signal 11

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-12 01:29 UTC] hradtke@php.net
Thank you for the insight.  I will take a look.
 [2017-10-24 06:59 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: hradtke +Assigned To:
 [2021-02-12 09:48 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-02-12 09:48 UTC] cmb@php.net
Does this still happen to you with any of the latest memcache
versions?
 [2021-02-21 04:22 UTC] pecl-dev at lists dot php dot net
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 "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 09:01:29 2024 UTC