I had this drafted and ready to send when you did the followup. Will send it
anyway.
Problem is that I cannot duplicate the problem. All works fine with Apache
2.4.4 on MacOS X Mountain Lion.
The previous person who had this did some analysis, but what he thought was an
issue shouldn't be an issue as I understood what they were suggesting.
They believed the problem was related to the fact that Apache will process the
configuration more than once. What they thought was occurring was that mod_wsgi
was saving away various configuration from the first pass into global variables
where memory for those was allocated from a memory pool that Apache then
destroyed after the first pass of the configuration. I guess they then figured
that on the second pass of the configuration that it would try and access the
data in those globals which would then crash because the memory pool had been
deleted.
What was wrong with this analysis was that on the second pass of the
configuration, all those static global variables should have been automatically
reset to 0. This is because between those two configuration runs, Apache would
have unloaded the mod_wsgi.so object from memory and then reloaded it. This
should have had the affect of throwing away everything mod_wsgi had done and
started over.
If I do a test using:
$ git diff
diff --git a/mod_wsgi.c b/mod_wsgi.c
index 1327e37..9a8fcf9 100644
--- a/mod_wsgi.c
+++ b/mod_wsgi.c
@@ -9781,6 +9781,10 @@ static const char *wsgi_add_daemon_process(cmd_parms *cmd
* Apache configuration.
*/
+ fprintf(stderr, "wsgi_add_daemon_process %ld\n", (long)cmd->pool);
+ fprintf(stderr, "wsgi_daemon_list #1 %ld\n", (long)wsgi_daemon_list);
+ fflush(stderr);
+
uid = ap_unixd_config.user_id;
user = ap_unixd_config.user_name;
@@ -10123,6 +10127,9 @@ static const char *wsgi_add_daemon_process(cmd_parms *cm
entry->listener_fd = -1;
+ fprintf(stderr, "wsgi_daemon_list #2 %ld\n", (long)wsgi_daemon_list);
+ fflush(stderr);
+
return NULL;
}
@@ -13659,6 +13666,10 @@ static int wsgi_hook_init(apr_pool_t *pconf, apr_pool_t
int status = OK;
+ fprintf(stderr, "wsgi_hook_init %ld %ld\n", (long)pconf, (long)ptemp);
+ fprintf(stderr, "wsgi_daemon_list %ld\n", (long)wsgi_daemon_list);
+ fflush(stderr);
+
/*
* Init function gets called twice during startup, we only
* need to actually do anything on the second time it is
where WSGIDaemonProcess and WSGIProcessGroup appear only the once, I do indeed
see wsgi_add_daemon_process() called twice on each restart. For one the print
statement appears in the shell window where I do the restart and the other in
the Apache error log.
In all cases though (with only one WSGIDaemonProcess), the wsgi_daemon_list
global is always 0 on doing the processing of that one and only
WSGIDaemonProcess. This indicates that mod_wsgi.so was correctly unloaded and
the static variables reset between the two configuration passes.
So right now that is not the problem.
Graham
On Apr 22, 2013, at 8:22 PM, Chingis Dugarzhapov <[email protected]> wrote:
> Hello guys,
>
> Just to confirm that issue still persists in 2.4.4, as well as in 2.4.1...
> (mod_wsgi 3.4/3.5)
>
> The issue is quite embarrassing. Segfaults force reinitialization of all
> mod_wsgi python environment which cause several seconds timeouts during first
> requests. We are obliged to run a backup server during deployment in
> production in order to make segfaults "pass though" with dummy shooters.
>
> Graham, could you kindly provide some visibility on when the issue would be
> fixed? (we cannot go back 2.2 :( and of course Embedded mode is *not* a
> solution for us)
>
> Cheers,
>
> --
> Chingis
>
>
> Le jeudi 28 mars 2013 06:18:09 UTC+1, Graham Dumpleton a écrit :
> There has been one other report of this with Apache 2.4.2.
>
> https://groups.google.com/d/topic/modwsgi/ehiiqqjQ6aA/discussion
>
> I didn't really have the time to look at it properly back then, but the code
> has always worked before with no issue and Apache wouldn't have change how
> memory pools are managed when reading configuration. I would be surprised if
> have managed to have a latent bug in there for so long.
>
> Any chance you can try Apache 2.4.4 and see if the issue goes away.
>
> Graham
>
>
> On 28 March 2013 04:18, Don Tillman <[email protected]> wrote:
> Hi,
>
> With mod_wsgi 3.4, apache httpd 2.4.2, apr 1.4.6, apr_util 1.4.1.
>
> Embedded Mode seems to work well. But I need Daemon Mode.
>
> When I add the WSGIProcessGroup directive to the config file and restart
> Apache httpd, it blows out immediately with a segmentation fault with no
> mention in the log.
>
> It happens in mod_wsgi.c, on line 10069, this:
>
> entry->server = cmd->server;
>
>
> Debugging:
>
> --------
> gdb /usr/sbin/httpd
> b wsgi_add_daemon_process
> run -X -f /etc/opt/tms/output/httpd.conf
> --------
>
>
> The first call to wsgi_add_daemon_process goes without incident. It's the
> second call that's a problem.
>
> --------
> Breakpoint 1, wsgi_add_daemon_process (cmd=0x7fffffffdb30, mconfig=0x8cd0b0,
> args=0x8d08b8 "djangodaemon threads=15") at mod_wsgi.c:9720
> 9720 mod_wsgi.c: No such file or directory.
> in mod_wsgi.c
> --------
>
> Go to the line, examine the locals:
>
> --------
> (gdb) until 10069
> wsgi_add_daemon_process (cmd=0x7fffffffdb30, mconfig=0x8cd0b0, args=0x8d08cf
> "") at mod_wsgi.c:10069
> 10069 in mod_wsgi.c
> (gdb) p *wsgi_daemon_list
> $1 = {pool = 0x80d138, elt_size = 280, nelts = 1, nalloc = 20, elts =
> 0x944058 ""}
> (gdb) p *cmd->server
> $2 = {process = 0x80b218, next = 0x0, error_fname = 0x5890ce
> "logs/error_log", error_log = 0x8809f8, log = {module_levels = 0x0, level =
> 4}, module_config = 0x8c77c8,
> lookup_defaults = 0x8cbd78, defn_name = 0x0, defn_line_number = 0,
> is_virtual = 0 '\000', port = 0, server_scheme = 0x0, server_admin = 0x5890bb
> "[no address given]",
> server_hostname = 0x0, addrs = 0x880a70, timeout = 60000000,
> keep_alive_timeout = 5000000, keep_alive_max = 100, keep_alive = 1, names =
> 0x0, wild_names = 0x0,
> path = 0x0, pathlen = 0, limit_req_line = 8190, limit_req_fieldsize = 8190,
> limit_req_fields = 100, context = 0x0}
> (gdb) p entry
> $3 = (WSGIProcessGroup *) 0x944058
> --------
>
> Okay. Continue, for the next call.
>
> --------
> (gdb) c
> Continuing.
> Missing separate debuginfo for /lib64/libnss_files.so.2
> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install
> /var/lib/debug/.build-id/19/c24fb834453511d12dfb4283d3c70f1346e974.debug
>
> Breakpoint 1, wsgi_add_daemon_process (cmd=0x7fffffffdb30, mconfig=0x852730,
> args=0x8d14a0 "djangodaemon threads=15") at mod_wsgi.c:9720
> 9720 in mod_wsgi.c
> --------
>
> Go to the line, examine the locals.
>
> --------
> (gdb) until 10069
> wsgi_add_daemon_process (cmd=0x7fffffffdb30, mconfig=0x852730, args=0x8d14b7
> "") at mod_wsgi.c:10069
> 10069 in mod_wsgi.c
> (gdb) p *wsgi_daemon_list
> $4 = {pool = 0x5929f0, elt_size = 10, nelts = 1, nalloc = 4567695, elts =
> 0x592b78 "mod_file_cache.c"}
> (gdb) p *cmd->server
> $5 = {process = 0x80b218, next = 0x0, error_fname = 0x5890ce
> "logs/error_log", error_log = 0x845cb8, log = {module_levels = 0x0, level =
> 4}, module_config = 0x845ee0,
> lookup_defaults = 0x8513f8, defn_name = 0x0, defn_line_number = 0,
> is_virtual = 0 '\000', port = 0, server_scheme = 0x0, server_admin = 0x5890bb
> "[no address given]",
> server_hostname = 0x0, addrs = 0x845d30, timeout = 60000000,
> keep_alive_timeout = 5000000, keep_alive_max = 100, keep_alive = 1, names =
> 0x0, wild_names = 0x0,
> path = 0x0, pathlen = 0, limit_req_line = 8190, limit_req_fieldsize = 8190,
> limit_req_fields = 100, context = 0x0}
> (gdb) p entry
> $6 = (WSGIProcessGroup *) 0x592b78
> --------
>
> Continue, and blammo...
>
> --------
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004fcdd6 in wsgi_add_daemon_process (cmd=0x7fffffffdb30,
> mconfig=0x852730, args=0x8d14b7 "") at mod_wsgi.c:10069
> 10069 in mod_wsgi.c
> (gdb)
> --------
>
> So it's not the usual kind of null pointer segv situation. The assignment on
> line 10069 looks to me like it should work.
>
> I did notice that wsgi_daemon_lists's nalloc value looks mighty large the
> second time around; perhaps that's an issue.
>
> Any ideas? This is very frustrating.
>
> -- Don
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/modwsgi?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/modwsgi?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
