Sorry, perhaps I should have stated: this is the same problem that I mentioned a little while ago on this list. (See http://axkit.org/cgi-bin/ezmlm-cgi?3:mss:4620:ciiphgjkaelimbnjjbjn and http://axkit.org/cgi-bin/ezmlm-cgi?3:sss:4620:ciiphgjkaelimbnjjbjn#b.)
To summarize: 1) The easily visible problems are: AxKit won't transform any documents, and writes nothing to the error_log, no matter what AxDebugLevel is set to. 2) I went through the code using the perl interactive debugger. As it turns out, a substantial amount of AxKit code _is_ executed. See http://durito.sourceforge.net/axkit_test/error_log_2002_08_19 for a report of all the Perl instructions that are executed in the processing of the request. (That file also shows all the information that AxKit::Debug _should_ be sending to the log.) 3) 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 AxKit should process a document. On line 216 of Provider.pm, AxKit declines to deal with the document, since $style_mapping contains just an empty hashref. $style_mapping is set on line 210 via the expression $AxKit::Cfg->StyleMap. The method StyleMap method is implemented by the sub Apache::AxKit::ConfigReader::StyleMap. In that sub, $self->{cfg} just contains an empty hashref, too. The sub Apache::AxKit::ConfigReader::new, I believe, should set this property with $self->get_config($r), on line 27 of ConfigReader.pm. In Apache::AxKit::ConfigReader::get_config, the expression _get_config($self->{apache}) returns an empty hash. _get_config is implemented in AxKit.xs. So... that's why I tried to debug this from C ;) Should I continue? How should I proceed? Should I try something totally different? I hope some of the above makes sense... again, any help is greatly apreciated. I'm using AxKit 1.6, perl 5.6.1 and apache 1.3.24. The full httpd.conf file I'm using 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]
