Help on debug an apache module
Hi people, Sorry if this is not the correct place for this post. I have some crashes with the libphp5.so, the thing is, if I start apache using gdb, I don't have any info available, just what I'm going to show below: Is there a best way to debug the module (libphp5.so)? On the kernel messages I have this: -- apache2[30793]: segfault at 0 ip b6ed6e5f sp bff4c560 error 4 in libmysqlclient.so.15.0.0[b6e88000+1a3000] -- flecha:~# gdb /usr/sbin/apache2 ruGNU gdb (GDB) 6.8.50.20090628-cvs-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... (no debugging symbols found) (gdb) run -X Starting program: /usr/sbin/apache2 -X (no debugging symbols found) (no debugging symbols found) Warning: DocumentRoot [/home/alojamento/enostar.pt/] does not exist Warning: DocumentRoot [/home/alojamento/lemague.pt/] does not exist Warning: DocumentRoot [/home/alojamento/cmmartins.com/] does not exist Warning: DocumentRoot [/home/alojamento/anossapensao.com/] does not exist [Tue Aug 04 22:21:02 2009] [warn] NameVirtualHost *:80 has no VirtualHosts [New LWP 31297] [LWP 31297 exited] Program received signal SIGSEGV, Segmentation fault. 0xb6f38e5f in ?? () (gdb) bt full #0 0xb6f38e5f in ?? () No symbol table info available. #1 0xb6c7f949 in ?? () No symbol table info available. #2 0xb6f586da in ?? () No symbol table info available. #3 0xb6ca11b7 in ?? () No symbol table info available. #4 0xb6580986 in ?? () No symbol table info available. #5 0xb79d12bc in ?? () No symbol table info available. #6 0xb79bbd20 in ?? () No symbol table info available. #7 0xb79d0b8e in ?? () No symbol table info available. #8 0xb79bbd20 in ?? () No symbol table info available. #9 0xb79d0b8e in ?? () No symbol table info available. #10 0xb79bbd20 in ?? () No symbol table info available. #11 0xb79d0b8e in ?? () No symbol table info available. #12 0xb79bbd20 in ?? () No symbol table info available. #13 0xb79c0f18 in ?? () No symbol table info available. #14 0xb79bbd20 in ?? () No symbol table info available.
Re: svn commit: r799334 - /httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c
On 08/03/2009 08:02 PM, Paul Querna wrote:
On Thu, Jul 30, 2009 at 8:37 AM,jfcl...@apache.org wrote:
Author: jfclere
Date: Thu Jul 30 15:37:22 2009
New Revision: 799334
URL: http://svn.apache.org/viewvc?rev=799334view=rev
Log:
Add the file logic for the handler.
(Next step add the slotmem logic for the multicast socket).
Modified:
httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c
Modified: httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c?rev=799334r1=799333r2=799334view=diff
==
--- httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c (original)
+++ httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c Thu Jul 30 15:37:22
2009
@@ -203,6 +203,188 @@
}
return APR_SUCCESS;
}
+/* Copied from mod_lbmethod_heartbeat.c... */
+static void
+argstr_to_table(apr_pool_t *p, char *str, apr_table_t *parms)
+{
+char *key;
+char *value;
+char *strtok_state;
+
+key = apr_strtok(str, ,strtok_state);
+while (key) {
+value = strchr(key, '=');
+if (value) {
+*value = '\0'; /* Split the string in two */
+value++;/* Skip passed the = */
+}
+else {
+value = 1;
+}
+ap_unescape_url(key);
+ap_unescape_url(value);
+apr_table_set(parms, key, value);
+/*
+ ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ Found query arg: %s = %s, key, value);
+ */
+key = apr_strtok(NULL, ,strtok_state);
+}
+}
This function already exists in this file. it is called qs_to_table.
It is 60 lines above in the same file.
Stop copying and pasting code.
Fixed.
Cheers
Jean-Frederic
Re: Catching graceful restart in apache2 module
I have found in following link: (http://wiki.apache.org/httpd/ModuleLife)
Race conditions during graceful restart
During a graceful restart, old children are still serving old requests while
new children are serving new requests. If the same lock must be used by old
and new children, then the lock name must be the same and cannot be
generated with tmpnam() or similar functions in the post_config hook.
Which lock is means there. I have already found the in the post_config I
have cleanuped procedure, but in the post_config is already mentioned
function for killing all session.
Is there any way how to detect if the restart of apache has been done as
gracefull or as hard restart?
best regards
Petr Hracek
2009/8/1 Petr Hracek phrac...@gmail.com
As you mentioned:
The request pool is no good, because that's cleaned up at the end of the
request. The connection pool is also no good, because that gets cleaned
up after the connection dies. You're probably after the pool you're
given during the post_config hook, which gets destroyed on server
shutdown (graceful or otherwise).
It means that in post_config can be handled the server has been shutdown
with either restart or graceful command for specific pool?
If I understand right then if pool is opened then it would not end because
of apache2 has been restarted with option graceful, right?
Is it behaviour the same when the server is going down in shel with the
gracefull command?
Is there any example how to implement in the post_config handler?
Best regards
Petr
2009/7/31 Graham Leggett minf...@sharp.fm
Petr Hracek wrote:
Thank for the answer.
Could you please explain in details how to do register save-sessions as
a pool cleanup.
You call a function that looks like this to register your cleanup:
apr_pool_cleanup_register(pool, (void *) foo, foo_cleanup,
foo_cleanup);
The function foo_cleanup() is a function you write yourself, that does
whatever you want the cleanup to do:
static apr_status_t foo_cleanup(void *dummy) {
foo_t *foo = (foo_t *)dummy;
... do stuff using foo ...
return APR_SUCCESS;
}
The variable foo is a void pointer that points to whatever you want your
cleanup to operate on, such as a pointer to your session config, or
whatever you want.
The cleanup gets run when the pool is deleted, ie when someone calls
apr_pool_destroy() on that pool.
What you need to do at this point is decide which pool you attach your
cleanup to.
The request pool is no good, because that's cleaned up at the end of the
request. The connection pool is also no good, because that gets cleaned
up after the connection dies. You're probably after the pool you're
given during the post_config hook, which gets destroyed on server
shutdown (graceful or otherwise).
Regards,
Graham
--
Re: Catching graceful restart in apache2 module
2009/8/4 Petr Hracek phrac...@gmail.com:
I have found in following link: (http://wiki.apache.org/httpd/ModuleLife)
Race conditions during graceful restart
During a graceful restart, old children are still serving old requests while
new children are serving new requests. If the same lock must be used by old
and new children, then the lock name must be the same and cannot be
generated with tmpnam() or similar functions in the post_config hook.
Which lock is means there. I have already found the in the post_config I
have cleanuped procedure, but in the post_config is already mentioned
function for killing all session.
Is there any way how to detect if the restart of apache has been done as
gracefull or as hard restart?
/**
* predicate indicating if a graceful stop has been requested ...
* used by the connection loop
* @return 1 if a graceful stop has been requested, 0 otherwise
* @deffunc int ap_graceful_stop_signalled(*void)
*/
AP_DECLARE(int) ap_graceful_stop_signalled(void);
If you haven't already seen it, see:
http://www.fmc-modeling.org/category/projects/apache/amp/4_3Multitasking_server.html
and everything else in that document.
Graham
best regards
Petr Hracek
2009/8/1 Petr Hracek phrac...@gmail.com
As you mentioned:
The request pool is no good, because that's cleaned up at the end of the
request. The connection pool is also no good, because that gets cleaned
up after the connection dies. You're probably after the pool you're
given during the post_config hook, which gets destroyed on server
shutdown (graceful or otherwise).
It means that in post_config can be handled the server has been shutdown
with either restart or graceful command for specific pool?
If I understand right then if pool is opened then it would not end because
of apache2 has been restarted with option graceful, right?
Is it behaviour the same when the server is going down in shel with the
gracefull command?
Is there any example how to implement in the post_config handler?
Best regards
Petr
2009/7/31 Graham Leggett minf...@sharp.fm
Petr Hracek wrote:
Thank for the answer.
Could you please explain in details how to do register save-sessions
as
a pool cleanup.
You call a function that looks like this to register your cleanup:
apr_pool_cleanup_register(pool, (void *) foo, foo_cleanup,
foo_cleanup);
The function foo_cleanup() is a function you write yourself, that does
whatever you want the cleanup to do:
static apr_status_t foo_cleanup(void *dummy) {
foo_t *foo = (foo_t *)dummy;
... do stuff using foo ...
return APR_SUCCESS;
}
The variable foo is a void pointer that points to whatever you want your
cleanup to operate on, such as a pointer to your session config, or
whatever you want.
The cleanup gets run when the pool is deleted, ie when someone calls
apr_pool_destroy() on that pool.
What you need to do at this point is decide which pool you attach your
cleanup to.
The request pool is no good, because that's cleaned up at the end of the
request. The connection pool is also no good, because that gets cleaned
up after the connection dies. You're probably after the pool you're
given during the post_config hook, which gets destroyed on server
shutdown (graceful or otherwise).
Regards,
Graham
--
Re: Catching graceful restart in apache2 module
On 08/04/2009 09:02 AM, Graham Dumpleton wrote: 2009/8/4 Petr Hracek phrac...@gmail.com: I have found in following link: (http://wiki.apache.org/httpd/ModuleLife) Race conditions during graceful restart During a graceful restart, old children are still serving old requests while new children are serving new requests. If the same lock must be used by old and new children, then the lock name must be the same and cannot be generated with tmpnam() or similar functions in the post_config hook. Which lock is means there. I have already found the in the post_config I have cleanuped procedure, but in the post_config is already mentioned function for killing all session. Is there any way how to detect if the restart of apache has been done as gracefull or as hard restart? /** * predicate indicating if a graceful stop has been requested ... * used by the connection loop * @return 1 if a graceful stop has been requested, 0 otherwise * @deffunc int ap_graceful_stop_signalled(*void) */ AP_DECLARE(int) ap_graceful_stop_signalled(void); Is this also true for graceful restarts? The comment only talks about graceful stops. Regards Rüdiger
Re: Catching graceful restart in apache2 module
2009/8/4 Ruediger Pluem rpl...@apache.org: On 08/04/2009 09:02 AM, Graham Dumpleton wrote: 2009/8/4 Petr Hracek phrac...@gmail.com: I have found in following link: (http://wiki.apache.org/httpd/ModuleLife) Race conditions during graceful restart During a graceful restart, old children are still serving old requests while new children are serving new requests. If the same lock must be used by old and new children, then the lock name must be the same and cannot be generated with tmpnam() or similar functions in the post_config hook. Which lock is means there. I have already found the in the post_config I have cleanuped procedure, but in the post_config is already mentioned function for killing all session. Is there any way how to detect if the restart of apache has been done as gracefull or as hard restart? /** * predicate indicating if a graceful stop has been requested ... * used by the connection loop * @return 1 if a graceful stop has been requested, 0 otherwise * @deffunc int ap_graceful_stop_signalled(*void) */ AP_DECLARE(int) ap_graceful_stop_signalled(void); Is this also true for graceful restarts? The comment only talks about graceful stops. Hmmm, I presumed that the server child process wouldn't know the difference and that 'stop' here meant 'stop' of an individual process and not the server as a whole. I guess a bit of digging through code is necessary to verify what actually happens. I could also possibly be wrong in assuming they were wanting to know about detecting in a server child process and not Apache parent process. I haven't exactly been following the discussion in detail. Graham
Re: Catching graceful restart in apache2 module
2009/8/4 Graham Dumpleton graham.dumple...@gmail.com: 2009/8/4 Ruediger Pluem rpl...@apache.org: On 08/04/2009 09:02 AM, Graham Dumpleton wrote: 2009/8/4 Petr Hracek phrac...@gmail.com: I have found in following link: (http://wiki.apache.org/httpd/ModuleLife) Race conditions during graceful restart During a graceful restart, old children are still serving old requests while new children are serving new requests. If the same lock must be used by old and new children, then the lock name must be the same and cannot be generated with tmpnam() or similar functions in the post_config hook. Which lock is means there. I have already found the in the post_config I have cleanuped procedure, but in the post_config is already mentioned function for killing all session. Is there any way how to detect if the restart of apache has been done as gracefull or as hard restart? /** * predicate indicating if a graceful stop has been requested ... * used by the connection loop * @return 1 if a graceful stop has been requested, 0 otherwise * @deffunc int ap_graceful_stop_signalled(*void) */ AP_DECLARE(int) ap_graceful_stop_signalled(void); Is this also true for graceful restarts? The comment only talks about graceful stops. Hmmm, I presumed that the server child process wouldn't know the difference and that 'stop' here meant 'stop' of an individual process and not the server as a whole. I guess a bit of digging through code is necessary to verify what actually happens. I could also possibly be wrong in assuming they were wanting to know about detecting in a server child process and not Apache parent process. I haven't exactly been following the discussion in detail. In prefork that function returns false all the time anyway. :-( Graham
Re: Catching graceful restart in apache2 module
That's true. I have some changes and this function returns always.
In my post_config handler function I have following code:
if(!ap_graceful_stop_signalled())
{
ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_DEBUG, 0,
base_server, !!! Graceful has not been called therefor kill all sessions
!!!);
udsc_usmw_killsessions(base_server);
}
Unfortunatelly it does not work.
Best regards
Petr
2009/8/4 Graham Dumpleton graham.dumple...@gmail.com
2009/8/4 Graham Dumpleton graham.dumple...@gmail.com:
2009/8/4 Ruediger Pluem rpl...@apache.org:
On 08/04/2009 09:02 AM, Graham Dumpleton wrote:
2009/8/4 Petr Hracek phrac...@gmail.com:
I have found in following link: (
http://wiki.apache.org/httpd/ModuleLife)
Race conditions during graceful restart
During a graceful restart, old children are still serving old requests
while
new children are serving new requests. If the same lock must be used
by old
and new children, then the lock name must be the same and cannot be
generated with tmpnam() or similar functions in the post_config hook.
Which lock is means there. I have already found the in the post_config
I
have cleanuped procedure, but in the post_config is already mentioned
function for killing all session.
Is there any way how to detect if the restart of apache has been done
as
gracefull or as hard restart?
/**
* predicate indicating if a graceful stop has been requested ...
* used by the connection loop
* @return 1 if a graceful stop has been requested, 0 otherwise
* @deffunc int ap_graceful_stop_signalled(*void)
*/
AP_DECLARE(int) ap_graceful_stop_signalled(void);
Is this also true for graceful restarts?
The comment only talks about graceful stops.
Hmmm, I presumed that the server child process wouldn't know the
difference and that 'stop' here meant 'stop' of an individual process
and not the server as a whole. I guess a bit of digging through code
is necessary to verify what actually happens.
I could also possibly be wrong in assuming they were wanting to know
about detecting in a server child process and not Apache parent
process. I haven't exactly been following the discussion in detail.
In prefork that function returns false all the time anyway. :-(
Graham
