Re: are the .exp files still needed?
On 1/16/2011 7:35 PM, Guenter Knauf wrote: > Hi Jeff, > currently we have 34 .exp files for modules in source tree which mostly you > commited way > back at 2.0.x start times for AIX - do you know if we still need them? If so > we would > probably need a bunch more since we have about 90+ modules now ... .exp files are likely only relevant if more functions than simply 'foo_module' are exposed, or if non-static functions must not be exported (and could be by an automatic export of all symbols). But I could be offbase on that. Note libtool on AIX really sucked back in those days... in the intervening years it now sucks less :)
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
On Sun, Jan 16, 2011 at 11:34:29AM +0100, Kaspar Brand wrote: > On 13.12.2010 15:24, Jim Jagielski wrote: > > At this late in the game, I would prefer to do this post-2.3.10... > > safer that way. > > Polite reminder, according to [1]... :-) I feel it's important because > it addresses PR 49784 and a few additional improvements for the OCSP > checking code (for client auth). > > Patch v2 from December is attached again, for the sake of easier reference. Thanks a lot for the patch & the prod... I've merged the config options changes with some minor tweaks (OpenSSL seems to stomp on the OCSP_* namespace so I renamed the macros): http://svn.apache.org/viewvc?rev=1059917&view=rev w.r.t. the change to skip OCSP validation for valid self-signed certs, I brought this up a while back: http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html and Stephen said it probably be configurable. Has common practice evolved here such that hard-coding the less strict behaviour is reasonable? Regards, Joe
Re: Prepare for large proxy commit...
On Jan 17, 2011, at 2:23 AM, Ruediger Pluem wrote: > > > On 01/15/2011 05:01 PM, Joe Orton wrote: >> On Wed, Jan 12, 2011 at 03:30:01PM -0500, Jim Jagielski wrote: >>> My current migration of mod_proxy away from the scoreboard >>> and to slotmem is done. All that remains is some final >>> testing. >>> >>> This will serve as the basis for adding in members during >>> runtime. Currently, the idea is that we only change the >>> number of workers, but nothing really prevents us from >>> also doing it with balancers themselves at some point. >>> >>> I'll be committing most likely tomorrow... >> >> With prefork I am seeing erratic results for the mod_rewrite proxy tests >> in t/modules/rewrite.t, though I've no reason to believe it is directly >> caused by this set of changes. Is anybody else seeing this? >> >> I get either: >> >> t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 2) >> Failed tests: 28-29 >> >> or >> >> t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 1) >> Failed test: 27 >> >> and have not dug further. Sometimes all the tests pass. > > Same for me. Just thought it was something weird on my side. > What OS?
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
Joe Orton wrote: > ... > w.r.t. the change to skip OCSP validation for valid self-signed certs, I > brought this up a while back: > > http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html > > and Stephen said it probably be configurable. Has common practice > evolved here such that hard-coding the less strict behaviour is > reasonable? > Are you referring to support for responders which sign responses using a key which is trusted by some out of band means (such as with a self-signed cert)? The main OCSP responders in the U.S. DoD have been signing with a self-signed cert for some time (an *expired* self-signed cert, no less!). Just recently I was checking an OCSP problem and noted that I was getting responses signed by an intermediate (to the CA) certificate, but since there any many such responders I can't be sure they are all now doing that. So, I'd like to see support for out-of-band responder keys. As it is I've had to hack in a fix to ignore the expired self-signed cert. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
Re: svn commit: r1059910 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_io.c
On 17 Jan 2011, at 3:14 PM, jor...@apache.org wrote: Author: jorton Date: Mon Jan 17 13:14:21 2011 New Revision: 1059910 URL: http://svn.apache.org/viewvc?rev=1059910&view=rev Log: * modules/ssl/ssl_engine_io.c: Revamp output buffering: add a "coalesce" filter which buffers the plaintext, and remove buffering of the SSL records -- i.e. buffer before the SSL output filter, rather than after it. This aims to reduce the network overhead imposed by the output of many small brigades (such as produced by chunked HTTP response), which can now be transformed into a few large TLS records rather than many small ones. Is this not a duplicate of the BUFFER filter in mod_buffer? Regards, Graham --
RE: Prepare for large proxy commit...
> -Original Message- > From: Jim Jagielski > Sent: Montag, 17. Januar 2011 14:58 > To: dev@httpd.apache.org > Subject: Re: Prepare for large proxy commit... > > > On Jan 17, 2011, at 2:23 AM, Ruediger Pluem wrote: > > > > > > > On 01/15/2011 05:01 PM, Joe Orton wrote: > >> On Wed, Jan 12, 2011 at 03:30:01PM -0500, Jim Jagielski wrote: > >>> My current migration of mod_proxy away from the scoreboard > >>> and to slotmem is done. All that remains is some final > >>> testing. > >>> > >>> This will serve as the basis for adding in members during > >>> runtime. Currently, the idea is that we only change the > >>> number of workers, but nothing really prevents us from > >>> also doing it with balancers themselves at some point. > >>> > >>> I'll be committing most likely tomorrow... > >> > >> With prefork I am seeing erratic results for the > mod_rewrite proxy tests > >> in t/modules/rewrite.t, though I've no reason to believe > it is directly > >> caused by this set of changes. Is anybody else seeing this? > >> > >> I get either: > >> > >> t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 2) > >> Failed tests: 28-29 > >> > >> or > >> > >> t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 1) > >> Failed test: 27 > >> > >> and have not dug further. Sometimes all the tests pass. > > > > Same for me. Just thought it was something weird on my side. > > > > What OS? > RHEL 4 64 Bit. Regards Rüdiger
Re: mod_ssl OCSP tuning (Re: T&R of 2.3.10)
On 17/01/2011 13:39, Joe Orton wrote: > On Sun, Jan 16, 2011 at 11:34:29AM +0100, Kaspar Brand wrote: >> On 13.12.2010 15:24, Jim Jagielski wrote: >>> At this late in the game, I would prefer to do this post-2.3.10... >>> safer that way. >> >> Polite reminder, according to [1]... :-) I feel it's important because >> it addresses PR 49784 and a few additional improvements for the OCSP >> checking code (for client auth). >> >> Patch v2 from December is attached again, for the sake of easier reference. > > Thanks a lot for the patch & the prod... > > I've merged the config options changes with some minor tweaks (OpenSSL > seems to stomp on the OCSP_* namespace so I renamed the macros): > > http://svn.apache.org/viewvc?rev=1059917&view=rev > > w.r.t. the change to skip OCSP validation for valid self-signed certs, I > brought this up a while back: > > http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html > > and Stephen said it probably be configurable. Has common practice > evolved here such that hard-coding the less strict behaviour is > reasonable? > I still believe it should be configurable. A root CA can be revoked for a number of reasons although key compromise has security issues if the responder certificate is part of the chain (i.e. cases #1 and #2 in that message). Apache OCSP AFAIK currently doesn't handle case #3 at all (trusting responders with keys trusted by some out of band means). There is a fix/enhancement for this (which also addresses the issue Steve Marquess brought up) in PR46037. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: svn commit: r1059910 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_io.c
On Mon, Jan 17, 2011 at 04:14:24PM +0200, Graham Leggett wrote: > On 17 Jan 2011, at 3:14 PM, jor...@apache.org wrote: > > >Author: jorton > >Date: Mon Jan 17 13:14:21 2011 > >New Revision: 1059910 > > > >URL: http://svn.apache.org/viewvc?rev=1059910&view=rev > >Log: > >* modules/ssl/ssl_engine_io.c: Revamp output buffering: add a > > "coalesce" filter which buffers the plaintext, and remove buffering > > of the SSL records -- i.e. buffer before the SSL output filter, > > rather than after it. This aims to reduce the network overhead > > imposed by the output of many small brigades (such as produced by > > chunked HTTP response), which can now be transformed into a few > > large TLS records rather than many small ones. > > Is this not a duplicate of the BUFFER filter in mod_buffer? Ah, I forgot that was in the tree. It is similar, but that's a content filter which requires manual user configuration, this is a connection-level filter which does not. Yes, it would certainly be very nice to have a more abstract buffering filter with an API. Regards, Joe
Startup crash for trunk on Solaris after proxy refactoring
Hi,
I get a crash on Solaris Sparc during startup in the test suite after
the proxy refactoring. Since it is a "Bus error" I wildly guess the root
cause is an alignment issue in the shared memory. Sparc ist sensible to
that and the only other Bus error or httpd I remember was wrong
alignment in shm for mod_ssl shmcb (long ago).
GDB output:
#0 0xfdfdd028 in ap_proxy_initialize_worker (worker=0x3cf6f8,
s=0x3ceb90, p=0x8a9a8)
at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/modules/proxy/proxy_util.c:1760
1760worker->s->retry =
apr_time_from_sec(PROXY_WORKER_DEFAULT_RETRY);
(gdb) bt full
#0 0xfdfdd028 in ap_proxy_initialize_worker (worker=0x3cf6f8,
s=0x3ceb90, p=0x8a9a8)
at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/modules/proxy/proxy_util.c:1760
rv = 0
mpm_threads = -27836648
#1 0xfdef4b54 in balancer_child_init (p=0x50e040, s=0x3ceb90) at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/modules/proxy/mod_proxy_balancer.c:122
size = 472
num = 2
balancer = (proxy_balancer *) 0x3e8d58
i = 0
sconf = (void *) 0x0
conf = (proxy_server_conf *) 0x3e8c48
rv = 0
#2 0x000448d8 in ap_run_child_init (pchild=0x50e040, s=0x8f478) at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/server/config.c:160
pHook = (ap_LINK_child_init_t *) 0xfdef6370
n = 10
#3 0xfdb625b8 in child_main (child_num_arg=0) at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/server/mpm/prefork/prefork.c:509
thd = (apr_thread_t *) 0x50e080
osthd = 1
ptrans = (apr_pool_t *) 0x510050
allocator = (apr_allocator_t *) 0x4d7fa8
status = 0
i = -38310956
lr = (ap_listen_rec *) 0xfdb76be4
pollset = (apr_pollset_t *) 0x0
sbh = (ap_sb_handle_t *) 0x0
bucket_alloc = (apr_bucket_alloc_t *) 0x0
last_poll_idx = 0
lockfile = 0x0
#4 0xfdb62d7c in make_child (s=0x0, slot=0) at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/server/mpm/prefork/prefork.c:708
pid = -38394916
#5 0xfdb639e0 in prefork_run (_pconf=0x7f33c, plog=0xbb288, s=0x8f478)
at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/server/mpm/prefork/prefork.c:932
status = -27184100
pid = {pid = 520952, in = 0x6, out = 0xffbff698, err = 0x44c10}
child_slot = 586872
exitwhy = 4267715968
processed_status = 766600
index = 766600
remaining_children_to_start = -4196752
#6 0x00030cd4 in ap_run_mpm (pconf=0x8a9a8, plog=0xbb288, s=0x8f478) at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/server/mpm_common.c:90
pHook = (ap_LINK_mpm_t *) 0x0
n = 0
rv = 567720
#7 0x0002bb74 in main (argc=8, argv=0xffbff82c) at
/shared/build/dev/httpd/sources/httpd/trunk/r1059644/server/main.c:737
exit_status = 0
c = 88 'X'
configtestonly = 387072
showcompile = 389800
confname = 0xffbffa03
"/shared/build/dev/httpd/test/httpd/trunk/r1059644/prefork-solaris10.sparc-1.4.2-1-1.3.10-2-all-default/t/conf/httpd.conf"
def_server_root = 0xffbff997
"/shared/build/dev/httpd/test/httpd/trunk/r1059644/prefork-solaris10.sparc-1.4.2-1-1.3.10-2-all-default/t"
temp_error_log = 0x7ec00 ""
error = 0x8a9a8 ""
pconf = (apr_pool_t *) 0x8a9a8
plog = (apr_pool_t *) 0xbb288
ptemp = (apr_pool_t *) 0xbfca0
pcommands = (apr_pool_t *) 0x8c9b0
opt = (apr_getopt_t *) 0x8ca50
rv = 520192
mod = (module **) 0x7f000
opt_arg = 0x0
signal_server = (apr_OFN_ap_signal_server_t *) 0x2
(gdb) print worker->s
$1 = (proxy_worker_shared *) 0xfe49000c
Regards,
Rainer
Re: Prepare for large proxy commit...
On 17.01.2011 08:23, Ruediger Pluem wrote: On 01/15/2011 05:01 PM, Joe Orton wrote: On Wed, Jan 12, 2011 at 03:30:01PM -0500, Jim Jagielski wrote: My current migration of mod_proxy away from the scoreboard and to slotmem is done. All that remains is some final testing. This will serve as the basis for adding in members during runtime. Currently, the idea is that we only change the number of workers, but nothing really prevents us from also doing it with balancers themselves at some point. I'll be committing most likely tomorrow... With prefork I am seeing erratic results for the mod_rewrite proxy tests in t/modules/rewrite.t, though I've no reason to believe it is directly caused by this set of changes. Is anybody else seeing this? I get either: t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 2) Failed tests: 28-29 or t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 1) Failed test: 27 and have not dug further. Sometimes all the tests pass. Same for me. Just thought it was something weird on my side. Same here. Proxy returns 502 # testing : proxy/QSA test appended args correctly # expected: (?s-xim:QUERY_STRING = foo=bar&bloo=blar\n) # received: HTTP/1.1 502 Proxy Error # Connection: close # Date: Mon, 17 Jan 2011 17:03:30 GMT # Server: Apache/2.3.11-dev (Unix) mod_ssl/2.3.11-dev OpenSSL/0.9.8q DAV/2 # Content-Length: 439 # Content-Type: text/html; charset=iso-8859-1 # Client-Date: Mon, 17 Jan 2011 17:03:30 GMT # Client-Peer: 127.0.0.1:8529 # Title: 502 Proxy Error #· # # # 502 Proxy Error # # Proxy Error # The proxy server received an invalid^M # response from an upstream server.^M # The proxy server could not handle the request href="/modules/rewrite/proxy-qsa.html">GET /modules/rewrite/proxy-qsa.html. # Reason: Error reading from remote server # [Mon Jan 17 18:03:30.954082 2011] [proxy:debug] [pid 21205] mod_proxy.c(1079): Running scheme http handler (attempt 0) [Mon Jan 17 18:03:30.954121 2011] [proxy:debug] [pid 21205] proxy_util.c(2087): proxy: HTTP: has acquired connection for (*) [Mon Jan 17 18:03:30.954153 2011] [proxy:debug] [pid 21205] proxy_util.c(2140): proxy: connecting http://localhost:8529/modules/cgi/env.pl?foo=bar&bloo=blar to localhost:8529 [Mon Jan 17 18:03:30.954195 2011] [proxy:debug] [pid 21205] proxy_util.c(2266): proxy: connected /modules/cgi/env.pl?foo=bar&bloo=blar to localhost:8529 [Mon Jan 17 18:03:30.957360 2011] [proxy_http:error] [pid 21205] (20014)Internal error: [client 127.0.0.1:53088] proxy: error reading status line from remote server localhost:8529 [Mon Jan 17 18:03:30.957433 2011] [proxy_http:debug] [pid 21205] mod_proxy_http.c(1531): [client 127.0.0.1:53088] proxy: NOT Closing connection to client although reading from backend server localhost:8529 failed. [Mon Jan 17 18:03:30.957467 2011] [proxy:error] [pid 21205] [client 127.0.0.1:53088] proxy: Error reading from remote server returned by /modules/rewrite/proxy-qsa.html [Mon Jan 17 18:03:30.957490 2011] [proxy:debug] [pid 21205] proxy_util.c(2102): proxy: HTTP: has released connection for (*) The backend request is not contained in the access log. I couldn't reproduce above LogLevel trace4, but maybe I simply wasn't patient enough. Regards, Rainer
Test suite crash for trunk in mod_setenvif using trace8
It looks like a confusion between array and table:
Program terminated with signal 11, Segmentation fault.
#0 0xff032198 in strlen () from /lib/libc.so.1
(gdb) bt full
#0 0xff032198 in strlen () from /lib/libc.so.1
No symbol table info available.
#1 0xff3301ec in apr_array_pstrcat (p=0x5f0730, arr=0x52b718, sep=32 '
') at .../sources/apr/trunk/r1059819/tables/apr_tables.c:246
cp = 0x3
res = 0x5f0730 ""
strpp = (char **) 0x52b8c0
len = 12
i = 3
#2 0xfe2c1dd8 in match_headers (r=0x5f0770) at
.../sources/httpd/trunk/r1059644/modules/metadata/mod_setenvif.c:682
arr = (const apr_array_header_t *) 0x52b718
sconf = (sei_cfg_rec *) 0x52bf70
entries = (sei_entry *) 0x52bf90
elts = (const apr_table_entry_t *) 0x52b8b8
val = 0x548ff3 "1"
err = 0x
val_len = 1
i = 2
j = 3
last_name = 0x549010 "R2"
regm = {{rm_so = 0, rm_eo = 17}, {rm_so = -1, rm_eo = -1},
{rm_so = -1, rm_eo = -1}, {rm_so = -1, rm_eo = -1}, {rm_so = -1, rm_eo =
-1}, {rm_so = -1, rm_eo = -1},
{rm_so = -1, rm_eo = -1}, {rm_so = -1, rm_eo = -1}, {rm_so = -1,
rm_eo = -1}, {rm_so = -1, rm_eo = -1}}
and
(gdb) dump_string_array arr
[0] 'VAR_ONE'
[1] 'set'
[2Cannot access memory at address 0x5641525f
(gdb) dump_table arr
[0] 'VAR_ONE'='set'
[1] 'VAR_TWO'='set'
[2] 'VAR_THREE'='set'
Regards,
Rainer
Slotmem patch for alignment
Hi, I wrote a small patch fixing an alignment issue for mod_slotmem: http://people.apache.org/~rjung/patches/mod_slotmem_shm_alignment.patch The problem is: mod_slotmem uses a header for meta data before the actual data slots. The addresses used for the data slots are offset by the size of the meta data. Currently this size is divisible by 4 but not by 8 and thus the data put into the slots is only aligned at 4 byte boudaries. If there is data inside the slots needing 8 byte alignment, then the compiler can not arrange for that. I fixed it by increasing the offset to the APR default alignment. Please check whether you think there's a problem with it. It tried it in combination with a separate proxy patch I'll post in a minute and both together fix the crashes observed on Solaris Sparc. One additional remark: I didn't actually understand the original code lines: apr_size_t basesize = (item_size * item_num); apr_size_t size = sizeof(sharedslotdesc_t) + (item_num * sizeof(char)) + basesize; What's the reason for the "(item_num * sizeof(char))" part? I can't actually see, where this part of the memory is being used. Regards, Rainer
Startup ordering between proxy and slotmem
I think slotmem is only a dependency for mod_proxy_balancer, not mod_proxy itself, so it seems safe (and more correct) to move the aszPred entry from mod_proxy.c to mod_proxy_balancer.c: http://people.apache.org/~rjung/patches/mod_proxy-slotmem-order.patch OK?
Re: Startup crash for trunk on Solaris after proxy refactoring
On 17.01.2011 15:45, Rainer Jung wrote: Hi, I get a crash on Solaris Sparc during startup in the test suite after the proxy refactoring. Since it is a "Bus error" I wildly guess the root cause is an alignment issue in the shared memory. Sparc ist sensible to that and the only other Bus error or httpd I remember was wrong alignment in shm for mod_ssl shmcb (long ago). In addition to the fix in slotmem (see previous mail) I suggest hardening the balancer against future crashes by also aligning the slot data at 8 byte boundaries (more precisely the APR default alignment): http://people.apache.org/~rjung/patches/mod_proxy_alignment.patch Regards, Rainer
Re: Startup ordering between proxy and slotmem
Makes sense. On Jan 17, 2011, at 12:56 PM, Rainer Jung wrote: > I think slotmem is only a dependency for mod_proxy_balancer, not mod_proxy > itself, so it seems safe (and more correct) to move the aszPred entry from > mod_proxy.c to mod_proxy_balancer.c: > > http://people.apache.org/~rjung/patches/mod_proxy-slotmem-order.patch > > OK? >
Re: Slotmem patch for alignment
On Jan 17, 2011, at 12:51 PM, Rainer Jung wrote: > Hi, > > I wrote a small patch fixing an alignment issue for mod_slotmem: > > http://people.apache.org/~rjung/patches/mod_slotmem_shm_alignment.patch > > The problem is: mod_slotmem uses a header for meta data before the actual > data slots. The addresses used for the data slots are offset by the size of > the meta data. Currently this size is divisible by 4 but not by 8 and thus > the data put into the slots is only aligned at 4 byte boudaries. If there is > data inside the slots needing 8 byte alignment, then the compiler can not > arrange for that. > > I fixed it by increasing the offset to the APR default alignment. Please > check whether you think there's a problem with it. It tried it in combination > with a separate proxy patch I'll post in a minute and both together fix the > crashes observed on Solaris Sparc. > Sounds good. > One additional remark: I didn't actually understand the original code lines: > > apr_size_t basesize = (item_size * item_num); > apr_size_t size = sizeof(sharedslotdesc_t) + > (item_num * sizeof(char)) + basesize; > > What's the reason for the "(item_num * sizeof(char))" part? I can't actually > see, where this part of the memory is being used. > It's the inuse table > Regards, > > Rainer >
Re: Startup crash for trunk on Solaris after proxy refactoring
On Jan 17, 2011, at 12:59 PM, Rainer Jung wrote: > On 17.01.2011 15:45, Rainer Jung wrote: >> Hi, >> >> I get a crash on Solaris Sparc during startup in the test suite after >> the proxy refactoring. Since it is a "Bus error" I wildly guess the root >> cause is an alignment issue in the shared memory. Sparc ist sensible to >> that and the only other Bus error or httpd I remember was wrong >> alignment in shm for mod_ssl shmcb (long ago). > > In addition to the fix in slotmem (see previous mail) I suggest hardening the > balancer against future crashes by also aligning the slot data at 8 byte > boundaries (more precisely the APR default alignment): > > http://people.apache.org/~rjung/patches/mod_proxy_alignment.patch > Untested, but +1 for better alignment for slotmem in gen and how proxy uses it.
Re: non thread safe functions used in apache httpd project
On 12 Jan 2011, at 10:29, Kevin J Walters wrote: > Hi, I picked this up when you reported it in bugzilla. One feature of the apache way of working is that no individual developer 'owns' your question (unless you pay someone for support), so it risks going unanswered. > Whilst looking at a thread safety issue in mod_fastcgi, i noticed > there's some suspicious looking code in apache httpd project. > > server/mpm_common.c (2.2.17) has two functions ap_uname2id and > ap_gname2id which call getpwnam and getgrnam, two non-reentrant > functions. I can say unambiguously that those functions are only used at server startup, before any threads are spawned. So not quite a bug. > Comparing with typical apr code that tends to have an #ifdef to > select function() vs function_r(). APR is a more general-purpose library, so it matters there. > Perhaps ap_uname2id and ap_gname2id are not executed concurrently by > the current code base but if these are general purpose functions they > should be more cautious/safe? Good point - thanks for making it. They are API functions and should therefore either be thread-safe and reentrant or properly documented as unsafe. So yes, it's a bug! > Has the whole apache httpd 2.x project been scanned for use of > non-reentrant function calls? I couldn't refer you to any systematic scan. However, a lot of third-parties come to us with reports of potential bugs based on scans of our codebase by a range of code-analysis tools. Developers and vendors of such tools come to apache in a variety of circumstances, from making a constructive contribution to seeking a high-profile and prestigious scalp! -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: Test suite crash for trunk in mod_setenvif using trace8
On Mon, 17 Jan 2011, Rainer Jung wrote: It looks like a confusion between array and table: Program terminated with signal 11, Segmentation fault. #0 0xff032198 in strlen () from /lib/libc.so.1 (gdb) bt full Thanks for the pointer. Fixed in r1060072
Weird weirdness with %lld and apr_psprintf
OK, I was getting some weird weird errors with the byterange tests
for httpd... it was always failing. Looking over the output, what
I was seeing is that the output was sending out, well... see the below:
# Failed test 149 in t/apache/byterange.t at line 52 fail #149
Range: bytes=0-8192
Content-Range: bytes %ld-%ld/%ld
This is when APR_OFF_T_FMT is "lld"
No look at this... I change the section of code in byterange_filter.c
to:
if (ctx->num_ranges == 1) {
apr_table_setn(r->headers_out, "Content-Range",
apr_psprintf(r->pool, "bytes %lld - %lld / %lld",
range_start, range_end, clength));
and I get *this*!
# Failed test 149 in t/apache/byterange.t at line 52 fail #149
Range: bytes=0-8192
Content-Range: bytes %ld - %ld / %ld
Note that it looks like something is compressing %lld to %ld!
Re: Weird weirdness with %lld and apr_psprintf
I think it is related to OS X and vformatter:
if ((sizeof(APR_INT64_T_FMT) == 4 &&
fmt[0] == APR_INT64_T_FMT[0] &&
fmt[1] == APR_INT64_T_FMT[1]) ||
(sizeof(APR_INT64_T_FMT) == 3 &&
fmt[0] == APR_INT64_T_FMT[0]) ||
(sizeof(APR_INT64_T_FMT) > 4 &&
strncmp(fmt, APR_INT64_T_FMT,
sizeof(APR_INT64_T_FMT) - 2) == 0)) {
/* Need to account for trailing 'd' and null in sizeof() */
var_type = IS_QUAD;
fmt += (sizeof(APR_INT64_T_FMT) - 2);
}
else if (*fmt == 'q') {
var_type = IS_QUAD;
fmt++;
}
else if (*fmt == 'l') {
var_type = IS_LONG;
fmt++;
}
under OS X, 64bit, APR_INT64_T_FMT is 'ld' and APR_OFF_T_FMT is 'lld'...
In fact, I'm sure it is... Looking over the archives, I see a few
patches floating around for this...
On Jan 17, 2011, at 3:58 PM, Jim Jagielski wrote:
> OK, I was getting some weird weird errors with the byterange tests
> for httpd... it was always failing. Looking over the output, what
> I was seeing is that the output was sending out, well... see the below:
>
> # Failed test 149 in t/apache/byterange.t at line 52 fail #149
> Range: bytes=0-8192
> Content-Range: bytes %ld-%ld/%ld
>
> This is when APR_OFF_T_FMT is "lld"
>
> No look at this... I change the section of code in byterange_filter.c
> to:
>if (ctx->num_ranges == 1) {
>apr_table_setn(r->headers_out, "Content-Range",
> apr_psprintf(r->pool, "bytes %lld - %lld / %lld",
>range_start, range_end, clength));
>
> and I get *this*!
>
> # Failed test 149 in t/apache/byterange.t at line 52 fail #149
> Range: bytes=0-8192
> Content-Range: bytes %ld - %ld / %ld
>
> Note that it looks like something is compressing %lld to %ld!
>
Re: Weird weirdness with %lld and apr_psprintf
Fixed in r1060104/1060105/1060106
On Jan 17, 2011, at 4:24 PM, Jim Jagielski wrote:
> I think it is related to OS X and vformatter:
>
>if ((sizeof(APR_INT64_T_FMT) == 4 &&
> fmt[0] == APR_INT64_T_FMT[0] &&
> fmt[1] == APR_INT64_T_FMT[1]) ||
>(sizeof(APR_INT64_T_FMT) == 3 &&
> fmt[0] == APR_INT64_T_FMT[0]) ||
>(sizeof(APR_INT64_T_FMT) > 4 &&
> strncmp(fmt, APR_INT64_T_FMT,
> sizeof(APR_INT64_T_FMT) - 2) == 0)) {
>/* Need to account for trailing 'd' and null in sizeof() */
>var_type = IS_QUAD;
>fmt += (sizeof(APR_INT64_T_FMT) - 2);
>}
>else if (*fmt == 'q') {
>var_type = IS_QUAD;
>fmt++;
>}
>else if (*fmt == 'l') {
>var_type = IS_LONG;
>fmt++;
>}
>
>
> under OS X, 64bit, APR_INT64_T_FMT is 'ld' and APR_OFF_T_FMT is 'lld'...
>
> In fact, I'm sure it is... Looking over the archives, I see a few
> patches floating around for this...
>
> On Jan 17, 2011, at 3:58 PM, Jim Jagielski wrote:
>
>> OK, I was getting some weird weird errors with the byterange tests
>> for httpd... it was always failing. Looking over the output, what
>> I was seeing is that the output was sending out, well... see the below:
>>
>> # Failed test 149 in t/apache/byterange.t at line 52 fail #149
>> Range: bytes=0-8192
>> Content-Range: bytes %ld-%ld/%ld
>>
>> This is when APR_OFF_T_FMT is "lld"
>>
>> No look at this... I change the section of code in byterange_filter.c
>> to:
>> if (ctx->num_ranges == 1) {
>> apr_table_setn(r->headers_out, "Content-Range",
>> apr_psprintf(r->pool, "bytes %lld - %lld / %lld",
>> range_start, range_end, clength));
>>
>> and I get *this*!
>>
>> # Failed test 149 in t/apache/byterange.t at line 52 fail #149
>> Range: bytes=0-8192
>> Content-Range: bytes %ld - %ld / %ld
>>
>> Note that it looks like something is compressing %lld to %ld!
>>
>
Re: svn commit: r1059910 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_io.c
On 17 Jan 2011, at 4:35 PM, Joe Orton wrote: Is this not a duplicate of the BUFFER filter in mod_buffer? Ah, I forgot that was in the tree. It is similar, but that's a content filter which requires manual user configuration, this is a connection-level filter which does not. Yes, it would certainly be very nice to have a more abstract buffering filter with an API. True. What I've had in mind for a while is a connection level buffering filter that allows the backend request to complete and for r->pool to be destroyed (and all resources released), while the frontend takes its time consuming the data. I suspect that buffering filters are simple enough that trying to optimise them may be over the top. Regards,, Graham --
Possible crash in mod_cgid (logging crashes because of NULL s->module_config)
I did a broken build using a SHELL_PATH that was not available on the
build platform. The test suite tried to log
"exec of 'echo pass' failed"
in test number 16 of t/modules/include.t (line 261). This produced a
crash. It seems the crash will happen every time and exec include fails.
The reason is an incomplete server_rec, that has a NULL module_config.
gdb info:
#0 0x08083ccb in log_error_core (file=0xb78ce194
"/shared/build/dev/httpd/sources/httpd/trunk/r1060112/modules/generators/mod_cgid.c",
line=588, module_index=101,
level=3, status=2, s=0x845e088, c=0x0, r=0x0, pool=0x0,
fmt=0xb78cdfa3 "%s", args=0xbfdb1e6c "")
at
/shared/build/dev/httpd/sources/httpd/trunk/r1060112/server/log.c:1134
configured_level =
errstr = "ess=c...@digsigtrust.com\000\000referer:
\000ddress=webmas...@belsign.be\000\000referer: \000ferer:
\000\000\000\000�\020R\bx\fR\b\022\000\000\000\027šà \003\000\000\000\000\020\000\000\000\020\000\000\000d\035R\bx\035R\b\214\035R\bŽ\fR\b�ò«�\"\000\000\000\021\000\000\000djÀ·@ñï·dñï·dñï·\000\000\000\000xñï·\220\001\000\000š\000\000\000Î�ï·h.R\b°p\001\000�ß�¿djÀ·p\025ï·ð\035R\b"...
logf = (apr_file_t *) 0x845e9e8
level_and_mask = 3
rmain =
sconf =
info = {s = 0xbfdb1e80, c = 0xa, r = 0xbfdb1e18, rmain =
0xb7f9ff2d, file = 0xb78ce079 "CGIDCHILDERRFN", line = -1076158968,
module_index = -107615,
level = 138800256, status = 138800304, using_syslog = -1076158924,
startup = -1215504263}
log_conn_info =
log_req_info =
lines =
done =
line_number =
#1 0x08084a21 in ap_log_error_ (file=0xb78ce194
"/shared/build/dev/httpd/sources/httpd/trunk/r1060112/modules/generators/mod_cgid.c",
line=588, module_index=101,
level=3, status=2, s=0x845e088, fmt=0xb78cdfa3 "%s") at
/shared/build/dev/httpd/sources/httpd/trunk/r1060112/server/log.c:1263
args = 0xbfdb1e6c ""
#2 0xb78cc0db in cgid_child_errfn (pool=0x845de88, err=2,
description=0x845ed00 "exec of 'echo pass' failed")
at
/shared/build/dev/httpd/sources/httpd/trunk/r1060112/modules/generators/mod_cgid.c:588
vr = (void *) 0x845dec8
#3 0xb7fbbac7 in apr_proc_create (new=0x845e078, progname=0x845e3d0
"echo pass", args=0x845ecd8, env=0x845e410, attr=0x845ea88, pool=0x845de88)
at
/shared/build/dev/httpd/sources/apr/trunk/r1059819/threadproc/unix/proc.c:590
desc = 0x845ed00 "exec of 'echo pass' failed"
i =
empty_envp = {0x0}
#4 0xb78ccfb5 in cgid_start (p=,
main_server=0x80b5580, procnew=)
at
/shared/build/dev/httpd/sources/httpd/trunk/r1060112/modules/generators/mod_cgid.c:812
errfileno = 2
argv0 = 0x845e3d0 "echo pass"
env = (char **) 0x845e410
out_pipe =
err_pipe = 0
cmd_type = APR_SHELLCMD
key =
unix_addr = {sun_family = 1,
sun_path =
"\004\r\225·ÞXE\bXŒ£·P¡·ð!Ì·š\020\v\bÚÀ*\bÃ�\037Ã�¿Ã�ñú·\000\200\000\000\203\vó·Ã�\037Ã�¿Ã�ñú·\000dE\b\200\000\000\000¶\001\000\000D!\221·XcE\b\030\000\000\000\000\200\000\000ð!Ì·š\020\v\bÚÀ*\b(
�¿8\233ú·\021dE\b\221�\v\b"}
procattr = (apr_procattr_t *) 0x845ea88
inout = (apr_file_t *) 0x845ea38
stat =
in_pipe =
cgid_req = {req_type = 2, conn_id = 0, ppid = 13477,
core_module_index = 0, env_count = 30, ugid = {uid = 4294967295, gid =
4294967295, userdir = -1},
filename_len = 133, argv0_len = 9, uri_len = 34, args_len = 0,
loglevel = 7, limits = {limit_cpu_set = 0, limit_cpu = {rlim_cur = 0,
rlim_max = 0}, limit_mem_set = 0,
limit_mem = {rlim_cur = 0, rlim_max = 0}, limit_nproc_set = 0,
limit_nproc = {rlim_cur = 0, rlim_max = 0}}}
len = 2
#5 0xb78cd2f2 in cgid_init (p=0x80b10a8, plog=0x80e13b0,
ptemp=0x80e53c0, main_server=0x80b5580)
at
/shared/build/dev/httpd/sources/httpd/trunk/r1060112/modules/generators/mod_cgid.c:937
tmp_sockname = 0x8456400 "/var/tmp/cgitest/cgisock.13477"
ret =
data = (void *) 0x84da4a0
#6 0x0807ef80 in ap_run_post_config (pconf=0x80b10a8, plog=0x80e13b0,
ptemp=0x80e53c0, s=0x80b5580)
at
/shared/build/dev/httpd/sources/httpd/trunk/r1060112/server/config.c:98
n = 28
rv = 0
In mod_cgid.c line 588 the server_rec used in logging has:
(gdb) print *s
$3 = {process = 0x0, next = 0x0, error_fname = 0x0, error_log =
0x845e9e8, log = {module_levels = 0x0, level = 7}, module_config = 0x0,
lookup_defaults = 0x0,
defn_name = 0x0, defn_line_number = 0, is_virtual = 0 '\0', port = 0,
server_scheme = 0x0, server_admin = 0x0, server_hostname = 0x0, addrs =
0x0, timeout = 0,
keep_alive_timeout = 0, keep_alive_max = 0, keep_alive = 0, names =
0x0, wild_names = 0x0, path = 0x0, pathlen = 0, limit_req_line = 0,
limit_req_fieldsize = 0,
limit_req_fields = 0, context = 0x0}
so I guess "sconf = ap_get_module_config(s->module_config,
&core_module
Re: millisecond timeouts in mod_proxy & mod_proxy_http
How can I help clean it up? Are there other places where we can add ms timing support? The custom error-documents and status have been great for restful services where we wanted zero proxy errors returned to the client. Thanks - Neal On 1/15/11, Daniel Ruggeri wrote: > > On 1/14/2011 7:06 PM, Jim Jagielski wrote: >> It looks like it needs some fine-tuning and some formatting changes, >> but assuming we have CLA approval, I'd say lets fold it in >> and clean up post submission;) > ... >>> > - extends RewriteRules to implement a custom error document or return >>> > status per rule if timeout occurs > > FWIW, Jim, I'm a big fan of this part. > -- > Daniel Ruggeri > >
