On Fri, Oct 29, 2010 at 3:53 PM, Jeff Trawick <traw...@gmail.com> wrote: > On Fri, Oct 29, 2010 at 3:29 PM, Anders Kaseorg <ande...@mit.edu> wrote: >> On Fri, 29 Oct 2010, Jeff Trawick wrote: >>> I now have a test module that can duplicate server_rec; I duplicated >>> your crash with trunk (well, as far as I can tell from your truncated >>> backtrace) and confirmed that it works with the latest updates, which >>> I've committed in r1028683. >> >> I’m not sure it’s sufficient just to store server->module_config instead >> of server in fcgid_command. mod_vhost_ldap also duplicates the >> module_config vector out of the request pool, in order to be able to >> update core_module’s module_config without mutating it in place. >> >> Storing vhost_id directly in fcgid_command would probably work. > > yes, I believe so; I'm not sure why I didn't do that already :) > > (and the module_config duplication is another tweak to make to my fake > mass vhost code)
ugly as heck yeah, it crashed at that point, and AFAICT copying out vhost_id for fcgid_command works fine committed yet again (r1028901) I had a look at mod_vhost_ldap and can't see any other such data structure tricks. > >> >> Though I >> suspect it would be more robust to directly compare the fcgid_cmd_options >> structures, thereby avoiding the need to track VirtualHost identities >> altogether. > > while I'm concerned about the amount of storage to compare (possibly > mitigated with a hash if it is really that bad), this is probably the > right long-term solution after some restructures of the various > settings; then the people who want to share across vhosts can do so > provided that they don't have any settings which differ another day
