Module exceptions can be handled before it crashes httpd?
Hello, Is there a way to handle the exceptions (access violation, heap corruption etc) thrown by an output filter module within the module itself so that it does not propagate till the httpd.exe server resulting in a server crash? The C++ output filter module that I have written makes use of native memory allocation methods like malloc/new in some cases. I have not used the APR request pool here since the allocations in these methods are very much short lived and are called many times within a single request. So rather than waiting for the request completion and then the pool manager releasing this memory, I'm using native new/delete calls to do the allocation/deallocation so that I can release the memory immediately after use. The issue is, in some rare case scenarios I saw a httpd.exe crash that was due to heap corruption and access violation during new/delete calls in these methods. Is there a way I can gracefully handle these within the module by catching such exceptions and trying to handle them, rather that propagating this exception resulting in httpd.exe crash? Worst case even if no filtering happened due to a crash in the module, I'd prefer that the filter sent back the original data (that was passed to the filter when the filter callback was made by the server) down the filter chain, ofcourse after logging this information for later troubleshooting. Thankyou.
Re: svn commit: r1482918 - in /httpd/httpd/trunk: modules/http/http_filters.c server/protocol.c
Hi Graham,
seems you forgot to add a log number at line 1541:
On 15.05.2013 17:46, minf...@apache.org wrote:
Author: minfrin
Date: Wed May 15 15:46:01 2013
New Revision: 1482918
URL: http://svn.apache.org/r1482918
Log:
core: Stop ap_finalize_request_protocol() and ap_get_client_block() from
silently
swallowing errors from the filter stack, create error buckets and return them
appropriately.
Modified:
httpd/httpd/trunk/modules/http/http_filters.c
httpd/httpd/trunk/server/protocol.c
Modified: httpd/httpd/trunk/modules/http/http_filters.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1482918r1=1482917r2=1482918view=diff
==
--- httpd/httpd/trunk/modules/http/http_filters.c (original)
+++ httpd/httpd/trunk/modules/http/http_filters.c Wed May 15 15:46:01 2013
...
+if (APR_SUCCESS != rv) {
+ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r, APLOGNO()
+ Error while writing error response);
+}
+
/* if we actually fail here, we want to just return and
* stop trying to read data from the client.
*/
Gün.
[PATCH] Make error logging modular
Hi, last week I was trying to write my own module to log error_log to systemd-journal [1] and I've found out that with the current error_log code, it's not possible to do that properly. I was able to use error_log hook, but there is no way to disable creation of ErrorLog file (One can set it to /dev/null, but httpd will still write data to it without any reason). Syslog logger fixes that by hardcoding syslog methods in log.c/core.c, but I don't think that's the right thing to do with journald. Therefore, I've created following patches: http://people.apache.org/~jkaluza/patches/logging/ Their descriptions should be clear from their names, but I will describe them briefly here too. Patch 0001 declares ap_errorlog_provider which can be implemented by module providing error_log logger. Admin can later define ErrorLog provider arg to choose particular errorlog provider. Old syntax still works and the change is backward compatible. This patch also removes syslog logging from log.c (it is moved to newly created mod_syslog.c in next patch) Patch 0002 creates mod_syslog.c which uses the new API to implement syslog logging. It works the same way as the version in log.c I removed in previous patch, but it's in separate module. Patch 0003 shows how mod_journald.c can use the existing API. This module works well with systemd-journal, but unfortunately the performance of systemd-journal daemon is poor so far [2], but I presume it will be fixed and the module will be usable for general use in the future. There is probably no real benefit in accepting this last patch right now. It's here to only show why the previous two patches are useful. Note that this is my first bigger patch touching httpd core, so feel free to correct my possible mistakes... :) [1] http://0pointer.de/blog/projects/journalctl.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=963620 [patches] http://people.apache.org/~jkaluza/patches/logging/ Regards, Jan Kaluza
apr_atomic functions usage
I see that the below functions have specific assembly implementations for os32,ia32 architectures: apr_atomic_add32 apr_atomic_sub32 apr_atomic_inc32 apr_atomic_dec32 apr_atomic_set32 apr_atomic_cas32 apr_atomic_casptr apr_atomic_xchg32 apr_atomic_xchgptr How frequently are these functions used. I am planning to write arm specific code for the above functions in arm.c file. Can anyone help me where to start ? Thanks, Kalyan
profiling an apache httpd -X process
Hi all, I am able to debug the httpd -X process using eclipse gdb debugger But I am not able to profile the same. I am able to profile only a command line application . Can anyone pl help me out in profile the application with httpd -X process. Thanks, kalyan
Re: apr_atomic functions usage
On Mon, May 27, 2013 at 8:42 PM, kalyan sita kalyansit...@gmail.com wrote: I see that the below functions have specific assembly implementations for os32,ia32 architectures: apr_atomic_add32 apr_atomic_sub32 apr_atomic_inc32 apr_atomic_dec32 apr_atomic_set32 apr_atomic_cas32 apr_atomic_casptr apr_atomic_xchg32 apr_atomic_xchgptr How frequently are these functions used. I am planning to write arm specific code for the above functions in arm.c file. Can anyone help me where to start ? You really should direct this at the d...@apr.apache.org list since it's not part of httpd (granted there's a lot of overlap between the projects). These are only used if the compiler doesn't provide the atomic builtins: http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins If HAVE_ATOMIC_BUILTINS is true in include/arch/unix/apr_private.h then you don't need the ASM versions. One of the Linux Kernel hackers (Jon Masters) has a blog post up about ARM atomic operations: http://www.jonmasters.org/blog/2012/11/13/arm-atomic-operations/
