Thanks. This is really strange. I don't get how we could ever end up with a blocking socket on OS side.
Regards Rüdiger > -----Original Message----- > From: Joachim Achtzehnter [mailto:joac...@kraut.ca] > Sent: Donnerstag, 4. Februar 2016 09:17 > To: dev@httpd.apache.org > Subject: Re: HTTPS connections lock-up with 2.4.18 > > Here is the backtrace: > > > #0 0xb7fddc40 in __kernel_vsyscall () > > #1 0xb7e05f03 in __read_nocancel () at ../sysdeps/unix/syscall- > template.S:81 > > #2 0xb7f39589 in apr_socket_recv (sock=sock@entry=0x8156d18, > > buf=buf@entry=0x8168750 "html, body {\n font-family: arial, > helvetica, sans-serif;\n font-size: 12px;\n height: 100%;\n > margin:0;\n padding:0;\n height:100%;\n}\nbody a, a:hover {\n text- > decoration: underline;\n border:"..., len=len@entry=0xbffff5e4) at > network_io/unix/sendrecv.c:81 > > #3 0xb7f744d5 in socket_bucket_read (a=0x8160fc8, str=0xbffff5e0, > > len=0xbffff5e4, block=APR_NONBLOCK_READ) > > at buckets/apr_buckets_socket.c:36 > > #4 0x08086a98 in ap_core_input_filter (f=0x8165770, b=0x8165730, > > mode=AP_MODE_READBYTES, block=APR_NONBLOCK_READ, readbytes=5) > > at core_filters.c:235 > > #5 0xb7ce732a in bio_filter_in_read (bio=0x81666d8, in=0x816bc83 "", > inlen=5) > > at ssl_engine_io.c:487 > > #6 0xb7b1bc66 in BIO_read () > > from /home/joachima/httpd-2.4.18/lib/libcrypto.so.1.0.0 > > #7 0xb7c8e040 in ssl3_read_n () > > from /home/joachima/httpd-2.4.18/lib/libssl.so.1.0.0 > > #8 0xb7c8fa75 in ssl3_read_bytes () > > from /home/joachima/httpd-2.4.18/lib/libssl.so.1.0.0 > > #9 0xb7c8c211 in ssl3_read () > > from /home/joachima/httpd-2.4.18/lib/libssl.so.1.0.0 > > #10 0xb7ca8679 in SSL_read () > > from /home/joachima/httpd-2.4.18/lib/libssl.so.1.0.0 > > #11 0xb7ce80d7 in ssl_io_input_read (inctx=inctx@entry=0x81636e8, > > buf=buf@entry=0x8163710 "GET /css/subpage.css HTTP/1.1\r\nUser- > Agent: curl/7.40.0\r\nHost: na171\r\nAccept: */*\r\n\r\n", > len=len@entry=0xbffff8f8) > > at ssl_engine_io.c:611 > > #12 0xb7cea36c in ssl_io_filter_input (f=0x8165718, bb=0x81660d8, > > mode=AP_MODE_SPECULATIVE, block=APR_NONBLOCK_READ, readbytes=1) > > at ssl_engine_io.c:1407 > > #13 0x080a013f in check_pipeline (bb=0x81660d8, c=0x8156eb0) > > at http_request.c:244 > > #14 ap_process_request_after_handler (r=0x817e2d8) at http_request.c:367 > > #15 0x080a1229 in ap_process_async_request (r=r@entry=0x817e2d8) > > at http_request.c:448 > > #16 0x080a1575 in ap_process_request (r=r@entry=0x817e2d8) > > at http_request.c:458 > > #17 0x0809d547 in ap_process_http_sync_connection (c=0x8156eb0) > > at http_core.c:210 > > #18 ap_process_http_connection (c=0x8156eb0) at http_core.c:251 > > #19 0x0809549d in ap_run_process_connection (c=0x8156eb0) at > connection.c:41 > > #20 0x0809589d in ap_process_connection (c=c@entry=0x8156eb0, > csd=0x8156d18) > > at connection.c:213 > > #21 0x080a7849 in child_main (child_num_arg=child_num_arg@entry=0, > > child_bucket=child_bucket@entry=0) at prefork.c:723 > > #22 0x080a7a9f in make_child (s=0x80f9f38, slot=slot@entry=0, > > bucket=bucket@entry=0) at prefork.c:767 > > #23 0x080a9091 in prefork_run (_pconf=0x80d50a8, plog=0x80fd9b8, > s=0x80f9f38) > > at prefork.c:979 > > #24 0x08070959 in ap_run_mpm (pconf=pconf@entry=0x80d50a8, > plog=0x80fd9b8, > > s=0x80f9f38) at mpm_common.c:94 > > #25 0x08069f23 in main (argc=4, argv=0xbffffd54) at main.c:777 > > > On 2016-02-03 11:50 PM, Plüm, Rüdiger, Vodafone Group wrote: >
