At 8:49 PM +0100 3/20/02, Gerald Richter wrote: >Ok, this mean something with Apache config goes very wrong (That's also what >the backtraces tell use). Things are not initilized, when they should be set >to zero. Jochen reported yesterday some problems with setup inside of virual >hosts. Do you use virtual hosts and have Embperl settings in more then one >virtual host section ?
Yes, but removing them doesn't fix the problem. Here's my take on the problem for tonight. Keep in mind that the last time I looked into the Apache code was around 1996, so I'm doing a lot of guessing here. First of all, Embperl is the only PerlModule I'm loading, so I don't have anything to compare it to. Here's what's happening. In fixup_virtual_hosts, Apache is repeatedly calling merge_server_configs and merge_per_dir_configs on each virtual host. All is well until we get to the first one that actually has a directive. MSC: 0xCF390: index=34, embperl.c MSC: 0xCF390: index=2, mod_perl.c MSC: 0xCF390: index=33, mod_setenvif.c ... MDC: 0xCF918: index=34, embperl.c MDC: 0xCF918: index=2, mod_perl.c MDC: 0xCF918: index=33, mod_setenvif.c ... MSC: 0xCF390: index=34, embperl.c mdc: 0x0, 0x3AA700, 332 Now we've got to very funny things here. 1. merge_server_configs is calling Embperl's directory merge call. 2. The basev value for the merge is 0. So why is it 0? embperl_create_server_config is being called, but it doesn't appear to have been called on particular configuration array that's being passed to the merge. I *think* that chunk of memory is the one initialized by calling ap_single_module_configure. The only problem with that theory is that mod_perl doesn't get inserted in that one either. At this point I think I'm becoming incoherent--it's too late here. But maybe this is useful to someone. For what it's worth, here's some of my debug output: create_dir_config: .*\.html$ setting 0x3A9EE0[34] = 0x3AA438 (embperl.c) create_server_config: 0x3AA588, 332 setting 0xDDF30[34] = 0x3AA588 (embperl.c) MSC: 0xCF390: index=34, embperl.c mdc: 0x0, 0x3AA588, 332 So we were called on the module_config array at CF390, but the only place I ever see that being set is back here: SING1 setting 0xCF390[3] = 0xCFD88 (mod_vhost_alias.c) SING2 setting 0xCF918[4] = 0xCFDF8 (mod_env.c) SING1 setting 0xCF390[5] = 0xD0028 (mod_log_config.c) SING1 setting 0xCF390[6] = 0xD0120 (mod_mime_magic.c) SING2 setting 0xCF918[7] = 0xD0190 (mod_mime.c) That's in ap_single_module_configure, setting the server config. So we never added an entry there for index #34, but we look *up* index #34 in the merge code. Eventually we're going to hit a non-null instance in that lookup (since it's the last item in the array) and then we're going to call the routine with bad memory references. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
