Re: Regarding apache server debugging source code
Hi William, Your reply helped me . I launched httpd -X and used gdb processID of httpd -X and the debugger went into child_main function of prefork.c and it is remaining in while loop in the same function. What I would want is to see what module is getting invoked when a php script is run? What module is invoked when perl script is run ? I want to debug other core modules of apache like http_protocol.c , http_request.c , http_main.c. What is the best way of debugging the above modules? Thanks, Kalyan On Sat, May 11, 2013 at 9:04 AM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On Thu, 9 May 2013 14:08:45 +0530 kalyan sita kalyansit...@gmail.com wrote: I am trying to attach the eclipse debugger to find how different modules of apache source code are invoked. But I could only debug httpd binary and others present in bin directory. What I want is what exactly happens when a php script is deployed in apache server How are different apache handler modules called. I want to debug them. Firstly, launching httpd with -X (no forking, no detaching) makes any debugging project much easier. Secondly, debuggers allow you to pre-load dynamically loaded shared object modules. Your other two alternatives, are to set a delayed breakpoint on a soon-to-be-loaded module, or finally you can simply set a breakpoint in the mainline code after the config file (and therefore, loadable modules) are processed.
optimization of apache httpd source code for arm processor
Hi All, I am working on optimizing the apache httpd source code for arm processor. Can anyone give me hints of how to do it? Right now I am thinking to optimize assembly level code that is apr_arch_atomic.h etc Thanks, kalyan
ap_rgetline_core in protocol.c
Hi Chris, Can you please tell me in what way we can debug the ap_rgetline_core in protocol.c. I would like to know how you are calling ap_rgetline_core in protocol.c. Thanks in advance, Kalyan
re: ap_rgetline_core in protocol.c
Hi, I wanted to have a look at http://prefetch.net/blog/index.php/2005/12/12/profiling-apache-modules-with-dtrace/ but had no time to look at it for now. May it help you ? Personnaly, I have activated the pool profiling functions in APR which give me information of what and from where is allocated memory using the pool mechanism. After that, I had some printf debugging code to check more in detail what I want to see. (the sample i posted on the dev mailing list was created this way) I was also planning to use the profiling functionality of gcc (-pg option) but didn't manage to have it work yet. If someone has already used it, I'm really interesting. Could also be interesting to have a configure option to control that. Best regards. CJ Message du 14/05/13 13:25 De : kalyan sita A : dev@httpd.apache.org Copie à : Objet : ap_rgetline_core in protocol.c Hi Chris, Can you please tell me in what way we can debug the ap_rgetline_core in protocol.c. I would like to know how you are calling ap_rgetline_core in protocol.c. Thanks in advance, Kalyan
RFC: Handling abnormally large chunk sizes
Hi all, I am currently getting to the bottom of a test case that checks httpd's response to an abnormally large chunk extension from a reverse proxy server. What httpd does now is trigger an error, causing both the upstream and downstream connections to be terminated and truncated. Is this the correct way to respond to this? http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-4.1 says this: All recipients MUST be able to receive and decode the chunked transfer coding and MUST ignore chunk-ext extensions they do not understand. Does the above they do not understand requirement include the requirement to ignore chunk-ext extensions that are too long? (For some arbitrary definition of long) Regards, Graham --
proxy segfault in httpd-trunk
Hi all,
I am currently getting a segfault in the proxy during httpd-test, it looks like
conf-mutex is being used before being initialised:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0010
0x0001007cc8c0 in apr_global_mutex_lock (mutex=0x0) at global_mutex.c:97
97 if (mutex-thread_mutex) {
(gdb) bt
#0 0x0001007cc8c0 in apr_global_mutex_lock (mutex=0x0) at global_mutex.c:97
#1 0x000100159709 in ap_proxy_initialize_worker (worker=0x10108f460,
s=0x10104cae0, p=0x101051228) at proxy_util.c:1734
Not sure if this rings a bell for anyone?
Regards,
Graham
--
Re: proxy segfault in httpd-trunk
On 14 May 2013, at 19:54, Graham Leggett wrote: Hi all, I am currently getting a segfault in the proxy during httpd-test, it looks like conf-mutex is being used before being initialised: http://svn.eu.apache.org/viewvc?view=revisionrevision=1480627 The logic looks screwed to me: it's in create_proxy_config, and the merge just copies from base. If there's no proxy in the first vhost then you're likely in trouble! Should presumably be created server-wide in post- (or pre-)config and attached in child_init, if memory serves. -- Nick Kew
Re: proxy segfault in httpd-trunk
I guess a call to apr_global_mutex_child_init is missing in the child_init
hook of mod_proxy.
BTW: I ask myself why we need a global mutex to protect a pool. Wouldn't a
thread mutex be sufficient?
Plus why are we not using the httpd mutex API to make the mutex method
configurable?
Regards
Rüdiger
Graham Leggett wrote:
Hi all,
I am currently getting a segfault in the proxy during httpd-test, it looks
like conf-mutex is being used before being initialised:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0010
0x0001007cc8c0 in apr_global_mutex_lock (mutex=0x0) at global_mutex.c:97
97if (mutex-thread_mutex) {
(gdb) bt
#0 0x0001007cc8c0 in apr_global_mutex_lock (mutex=0x0) at
global_mutex.c:97
#1 0x000100159709 in ap_proxy_initialize_worker (worker=0x10108f460,
s=0x10104cae0, p=0x101051228) at proxy_util.c:1734
Not sure if this rings a bell for anyone?
Regards,
Graham
--
Re: RFC: Handling abnormally large chunk sizes
On May 14, 2013, at 8:58 AM, Graham Leggett wrote: Hi all, I am currently getting to the bottom of a test case that checks httpd's response to an abnormally large chunk extension from a reverse proxy server. What httpd does now is trigger an error, causing both the upstream and downstream connections to be terminated and truncated. Is this the correct way to respond to this? Is there any other way to handle it? How long are we talking about? I certainly wouldn't try to process more than a single input buffer. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-4.1 says this: All recipients MUST be able to receive and decode the chunked transfer coding and MUST ignore chunk-ext extensions they do not understand. Does the above they do not understand requirement include the requirement to ignore chunk-ext extensions that are too long? (For some arbitrary definition of long) Probably, but we can fix the requirement if you think it might be a security issue (or just a bit too silly). Note that sending chunk-ext has been deprecated. Roy
