Sorry, I should have stated: this is the same problem that I mentioned in previous messages to the list (See http://axkit.org/cgi-bin/ezmlm-cgi?3:mss:4620:ciiphgjkaelimbnjjbjn and http://axkit.org/cgi-bin/ezmlm-cgi?3:sss:4620:200208:ciiphgjkaelimbnjjbjn#b)
To summarize: 0) The easily visible problems are that AxKit doesn't transform any documents, and writes nothing to the error_log, no matter what AxDebugLevel is set to. 1) I ran the through the code using the perl interactive debugger. This showed that a good amount of AxKit code _does_ get executed. See http://durito.sourceforge.net/axkit_test/error_log_2002_08_19 for a full report of all the AxKit Perl instructions executed in the processing of a request. You can also see from that report all the AxKit::Debug messages that _should_ get sent to the log. 2) The execution on the non-functional server deviates from that of a functional server (running on a different box) when it comes time to determine how to process the document at hand, in Provider.pm, on line 216. AxKit can't find a mapping for any style because the variable $style_mapping just contains an empty hashref. The variable is set on line 210 of Provider.pm, by a call to AxKit::Cfg->StyleMap. That method is implemented by Apache::AxKit::ConfigReader::StyleMap, which finds only an empty hashref as the value of $self->{'cfg'} (ConfigReader.pm line 53). That property, apparently, should be set when the instance of the Apache::AxKit::ConfigReader object is created by Apache::AxKit::ConfigReader::new. That sub calls Apache::AxKit::ConfigReader::get_config, which calls the xs sub _get_config, which returns a reference to an empty hash. So... that's why I tried debugging the C code ;) Should I continue? How should I proceed? Should I be trying something completely different? Does any of this make sense? Sorry if my last message wasn't clear, and was a bit sketchy on some details. Again, thanks for the help. I'm using AxKit 1.6, apache 1.3.24, perl 5.6.1. The full httpd.conf file is available at http://durito.sourceforge.net/axkit_test/httpd_conf_2002_08_19 Take care, Andrew Quoting Jörg Walter <[EMAIL PROTECTED]>: > On Wednesday 18 September 2002 06:58, [EMAIL PROTECTED] wrote: > > > (gdb) s > > 240 RETVAL = newRV_noinc((SV*)config); > > (gdb) s > > 0x811336c in Perl_newRV_noinc () at eval.c:88 > > 88 eval.c: No such file or directory. > > > > <!-- maybe the above output says something that can lead me to the > problem? > > --> > > This is irrelevant. It just means you don't have the file "eval.c" > accessible, > which belongs to perl itself. Since the error is not in perl, we don't > need > it. > > > (gdb) s > > XS_Apache__AxKit__ConfigReader__get_config (cv=0x83036ec) at > AxKit.c:290 > > 290 ST(0) = RETVAL; > > (gdb) c > > Continuing. > > What is the error? What's in the error log at AxDebugLevel 9? What > doesn't > work? > Supposing your assumptions are right: Did you check the return value of > > AxKit::get_config? What is it? and what is wrong with it? It's no sense > > debugging into something when you don't even know what you're after. I > suggest going through the perl code, spreading 'AxKit::Debug(7,"message > with > data");' lines, turning AxDebugLevel to 7 or higher and first narrow > down > where a problem happens and exactly why. Something like "value $foo in > the > hash is not set" or so. Then see if the value should be set, checking > config > files and the like. Debugging into C code is rarely neccessary, unless > your > apache segfaults. > > CU > Jörg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ------------------------------------------------- Obtén tu correo en www.correo.unam.mx UNAMonos Comunicándonos --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
