I'm running into a new problem; sort of.

Sort of new, not sort of a problem.

I just finished installing Apache::ASP (so that I can get our ISP
billing system running).  It relies on the SDBM_File extension for
session object management.  The SDBM_File compilation is failing
because of a missing PL_op symbol, which I assume is supposed to be
coming from mod_perl (which we downgraded to get this far).  I tried 
going back to the previous version of the SDBM_File code, but that
doesn't help.

The problem, (which is why I think it's sort of the same) seems to have
some relationship with an xpvav member in one of the files.  If that's
the case, I may end up going all the way back to perl5.6.0 and the 
older code in several other areas.  The only reason this is problematic
is because the CPAN installation of the support routines for the 
accounting package tries to upgrade everything when I start loading 
the new CPAN entries.

I'm really stuck.  I'm not sure falling back is going to help me, 
and I'm just floundering in the current versions of the code.

Any suggestions?

Dave

David Burgess wrote:
> 
> I would like to report success, but that just isn't going to happen.
> I've been installing from /usr/pkgsrc, trying different combinations of
> installations, and I keep getting the same problem.  Whenever I run
> apache with the -DPERL argument, I get a core dump.  This time (and the
> last few) it has been in S_new_xpvav (), although it has failed in the
> past in various other places (as I moved forward).
> 
> I think the thing that bothers me the most is that it doesn't deal
> with the error, it simply dumps core....
> 
> First - uname information:
> 
> NetBSD webserv02.neonramp.com 1.5.2 NetBSD 1.5.2 (NEONRAMP-RADIUS) #1:
> Sat Sep 29 11:18:54 PDT 2001
> burgess@webserv02.neonramp.com:/usr/src/sys/arch/i386/compile/NEONRAMP-RADIUS
> i386
> 
> I tried the new patch, and get the same basic problems that I've run
> into since Thursday:
> 
> webserv02# httpd -X -DPERL
> Segmentation fault (core dumped)
> webserv02# gdb -c httpd.core `which httpd`
> GNU gdb 4.17
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386--netbsd"...(no debugging symbols
> found)...
> Core was generated by `httpd'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/libexec/ld.elf_so...(no debugging symbols
> found)...
> done.
> Reading symbols from /usr/lib/libcrypt.so.0...(no debugging symbols
> found)...
> done.
> Reading symbols from /usr/lib/libc.so.12...(no debugging symbols
> found)...done.
> Reading symbols from /usr/pkg/lib/httpd/mod_perl.so...
> (no debugging symbols found)...done.
> Reading symbols from
> /usr/pkg/lib/perl5/5.6.1/i386-netbsd/CORE/libperl.so...
> (no debugging symbols found)...done.
> Reading symbols from /usr/lib/libm387.so.0...(no debugging symbols
> found)...
> done.
> Reading symbols from /usr/lib/libm.so.0...(no debugging symbols
> found)...done.
> #0  0x481fdeb0 in S_new_xpvav ()
> (gdb) bt
> #0  0x481fdeb0 in S_new_xpvav ()
> #1  0x481fe70d in Perl_sv_upgrade ()
> #2  0x481f51c6 in Perl_newAV ()
> #3  0x481b0156 in perl_construct ()
> #4  0x4816a006 in perl_startup ()
> #5  0x4816d778 in perl_cmd_handler_handlers ()
> #6  0x806f20d in invoke_cmd ()
> #7  0x806f563 in ap_handle_command ()
> #8  0x806f5ac in ap_srm_command_loop ()
> #9  0x8071cda in filesection ()
> #10 0x806f345 in invoke_cmd ()
> #11 0x806f563 in ap_handle_command ()
> #12 0x806f5ac in ap_srm_command_loop ()
> #13 0x806fa5a in ap_process_resource_config ()
> #14 0x80700a8 in ap_read_config ()
> #15 0x8076c32 in standalone_main ()
> #16 0x80773cb in main ()
> #17 0x804fc39 in ___start ()
> (gdb)
> 
> The results of a pkg_info -a yields the following:
> 
> digest-20010807     Message digest wrapper utility
> apache-1.3.20       HTTP (Web) server
> libtool-base-1.4.20010614nb2 Generic shared library support script (the
> script itself)
> db-2.7.7            Sleepycat Software's Berkeley DB version 2
> pks-0.9.4           PGP Public Key Server
> perl-5.6.1nb3       Practical Extraction and Report Language
> libperl-5.6.1       Perl DynaLoader as a shared object
> p5-BSD-Resource-1.10 BSD::Resource - Perl interface to BSD process
> resources library
> ap-perl-1.26        Module that embeds a Perl interpreter into Apache
> ap-ssl-2.8.4        SSL/TLS protocols module for Apache
> mit-pthreads-1.60b6 Chris Provenzano's (MIT) POSIX threads library
> 
> Here is the pertinent component of the apache.conf file:
> 
> # Note: The order in which modules are loaded is important.  Don't
> change
> # the order below without expert advice.
> #
> # Example:
> # LoadModule foo_module lib/httpd/mod_foo.so
> 
> <IfDefine SSL>
> LoadModule ssl_module lib/httpd/mod_ssl.so
> AddModule mod_ssl.c
> </IfDefine>
> 
> <IfDefine PERL>
>   LoadModule perl_module lib/httpd/mod_perl.so
>   AddModule mod_perl.c
>   <Files ~ "\.pl$">
>     PerlHandler         Apache::Registry
>     PerlSendHeader      On
>     SetHandler          perl-script
>     Options             +ExecCGI
>   </Files>
> </IfDefine>
> 
> #
> 
> If I comment out the <Files>...</Files> section, I get a different
> core dump:
> 
> #0  0x48204acf in Perl_newSVpvn ()
> #1  0x481b000d in perl_construct ()
> #2  0x4816a006 in perl_startup ()
> #3  0x48169cf4 in perl_module_init ()
> #4  0x807015f in ap_init_modules ()
> #5  0x8076c88 in standalone_main ()
> #6  0x80773cb in main ()
> #7  0x804fc39 in ___start ()
> 
> One thing that I saw that I thought was odd was this:
> 
> webserv02# ls -ald /usr/bin/perl
> lrwxrwxr-x  1 root  wheel  19 Oct 18  1997 /usr/bin/perl ->
> /usr/local/bin/perl
> webserv02# ls -ald /usr/local/bin/per*
> -r-xr-xr-x  1 root  wheel  714592 Oct  1 17:53 /usr/local/bin/perl
> -rwxr-xr-x  1 root  wheel   67749 Oct  1 17:45 /usr/local/bin/perl5.6.1
> -rwxr-xr-x  1 root  wheel   35473 Oct  1 17:46 /usr/local/bin/perlbug
> -rwxr-xr-x  1 root  wheel   16928 Oct  1 17:46 /usr/local/bin/perlcc
> -rwxr-xr-x  1 root  wheel   22643 Oct  1 17:46 /usr/local/bin/perldoc
> 
> Should perl5.6.1 be 8 minutes younger than perl?  I tried relinking
> /usr/bin/perl to the perl5.6.1 file, just for grins.  No difference.
> 
> Any help would be greatly appreciated.
> 
> P.S.  As soon as I get this working, I'm going to start on trying to
> get MySQL InnoDB and BDB support working.  BDB compiles, but fails at
> run-time, InnoDB doesn't even compile.
> 
> Dave
> 
> Todd Vierling wrote:
> >
> > On Mon, 1 Oct 2001, Johnny Lam wrote:
> >
> > : I've included below a patch to the perl package that causes perl modules
> > : from CPAN to link directly against -lperl when built.  Combined with the
> > : recent update of perl to add ${LOCALBASE}/lib to the rpath when creating
> > : shared libraries/modules, these two changes make using mod_perl.so (ap-perl)
> > : more painless.
> >
> > FWIW (to get this out of my overflowing mailbox :), this looks great; please
> > implement it.  This was my original intent with libperl.so ages ago, but I
> > never managed to get to fixing it.
> >
> > --
> > -- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
> > -- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/