You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2001/04/27 19:05:08 UTC

ANNOUNCE: mod_perl guide ver. 1.29

The updated guide is out, rush and read it before you ask a question :)

How to get it:

* CPAN:

  file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.29.tar.gz
  size: 469832 bytes
   md5: 498ae2164b637f59bea34cbe9343b9ac

* Online:

   http://perl.apache.org/guide/

* PDF Book (663pp)

  http://perl.apache.org/guide/mod_perl_guide.pdf.gz

====================================================================
=== Changes:
====================================================================

04.26.2001 ver 1.29

* dbm.pod:

  o updated "Flawed Locking Methods Which Must Not Be Used" with notes
    about lock upgrading (David Harris)

* strategy.pod:

  o added a ref to a light and fast Boa webserver

* scenario.pod:

  o cleared out the section on open proxying with mod_proxy (Eric Cholet)

* multiuser.pod:

  o extended the "Virtual Servers Technologies" section with freevsd,
    freevmware, vmware and S/390 references.

* snippets.pod:

  o removed the cache control section -- it's covered in the HTTP
    headers chapter.

  o subrequests and notes working together (Darren Chamberlain)

* performance.pod:

  o "Interpolation vs List" update: wrongly used the 'concatenation'
    term instead of interpolation (Mark Summerfield)

  o "Interpolation, Concatenation or List" was rewritten

  o new: "Architecture Specific Compile Options" (Tim Bunce, Perrin
    Harkins, Greg Cope, Owen Williams, Vivek Khera, Steve Fink, James
    W Walden)

* modules.pod:

  o Extended the docs of Apache::SubProcess module

* porting.pod:

  o "using register_cleanup in startup.pl to register cleanup action
    at the server shutdown or restart" (Doug)

* config.pod:

  o Cleared the item which was falsely stating that the globals
    defined in startup.pl cannot be seen by child process. (Richard
    Chen)

* install.pod:

  o updated "Discovering Whether Some Option Was Configured": added
    Apache::MyConfig

  o debian/apt install notes updates (Neil Conway)

  o some callback hooks aren't enabled by ALL_HOOKS=1 (Neil Conway)

* download.pod

  o update the location of mod_proxy_add_forward.c (Ask Bjorn Hansen)

* help.pod

  o added a link to Andrew Ford's Apache and mod_perl pocket books.

  o added a link to take23.org

  o added a XS resources section

  o added a link to the scalable list archive

  o remove the mailing list post address, to make it easier of Ask to
    filter SPAM.

* troubleshooting.pod

  o new: "exit signal Segmentation fault (11)" with mysql: (Matt
    Sergeant)

  o improved the docs of fixing a broken /dev/null

* debug.pod

  o updated "gdb says there are no debugging symbols" -- a simpler
    technique to have the binary unstripped during make install.

* Minor corrections:

  o debug.pod (Alexander Farber)
  o performance.pod (Marc Lehmann, Kees Vonk)
  o snippets.pod (Ime Smits)
  o porting.pod (Michele Beltrame)
  o config.pod (Surat Singh Bhati, Paul Cotter )
  o control.pod (Aaron Johnson, Cliff Rayman, Yann Kerherv)
  o modules.pod (Daniel Bohling)
  o install.pod (Kevin Swope, Jamie)

Enjoy!

_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide
mailto:stas@stason.org   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/



More information on segfault

Posted by "Richard L. Goerwitz III" <ri...@goerwitz.com>.
More information on segfault (apache-1.3.20, mod_perl 1.26_01, perl
5.6.0
[default RedHat 7.0 installation of Perl plus modules]).  I've compiled
in
tracing and now at least pinpoint the command that's causing the problem
(yes, I have mod_ssl-2.8.4-1.3.20 compiled in as well):

SVt_PV: $SSLPassPhraseDialog =
`'exec:/usr/local/sbin/echo-server-privkey-password''
handle_command (SSLPassPhraseDialog
'exec:/usr/local/sbin/echo-server-privkey-password'): OK
Program received signal SIGSEGV, Segmentation fault.
0x81fe1d2 in Perl_sv_free ()
(gdb) bt
#0  0x81fe1d2 in Perl_sv_free ()
#1  0x81d5e84 in Perl_cv_undef ()
#2  0x80acba9 in perl_clear_symtab ()
#3  0x80ad38f in perl_section ()
#4  0x818cdf8 in invoke_cmd ()
#5  0x818d90e in ap_handle_command ()
#6  0x818d9a1 in ap_srm_command_loop ()
#7  0x818e00e in ap_process_resource_config ()
#8  0x818e943 in ap_read_config ()
#9  0x8198670 in standalone_main ()
#10 0x8198fab in main ()
#11 0x402f4b5c in __libc_start_main (main=0x8198bf8 <main>, argc=4, 
    ubp_av=0xbffff9c4, init=0x807d5d8 <_init>, fini=0x8235950 <_fini>, 
    rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129

All this tells me is that the error is occurring after all the
handle_command() calls are finished (SSLPassPhraseDialog is the
last one to be executed; if I remove the $SSLPassPhraseDialog =
statement it and put it outside a <Perl> section, then the seg-
fault happens anyway - after the last command gets handled).

-- 

Richard Goerwitz                               richard@Goerwitz.COM
tel: 401 438 8978

Re: segfault w/ Apache 1.3.20, mod_perl 1.26

Posted by "Richard L. Goerwitz III" <ri...@goerwitz.com>.
Ged Haywood wrote:

> IIRC there was a problem with the compiler (gcc) that came with RH7.0,
> which compiler are you using?

I'm using the patched version of GCC that RedHat later released,
gcc-2.96-85.

Dunno if it's relevant, but I see the following ChangeLog entry that
might or might not be relevant to this problem (for mod_perl 1.25_01
- July 6, 2001):

  adjust perl_clear_symtab() to deal properly bleedperl's version of
  cv_undef() (which broke modules with directive handlers)
  thanks to Geoffrey Young for the spot

On perl_clear_symtab() see below.

Note that I tried both mod_perl 1.26 and 1.26_01, and both behave
similarly.  I.e., both coredump after handling all the commands in
my <Perl></Perl> section.  The coredump happens inside Perl_sv_free:

  #0  0x81fe1d2 in Perl_sv_free ()
  #1  0x81d5e84 in Perl_cv_undef ()
  #2  0x80acba9 in perl_clear_symtab ()

The message in my error_log file is:

  Attempt to free unreferenced scalar.

> Send us the output of "perl -V" and also the arguments you gave to
> Makefile.PL, then when they all get back from the conference maybe
> someone will have your answer.

Ok, first the Makefile.PL args.  I tried this various ways (e.g., with
and without PERL_DEBUG; also, with just PERL_TRACE):

SSL_BASE='/usr' perl Makefile.PL APACHE_SRC=/usr/local/src/apache/src
USE_APACI=1 EVERYTHING=1 PERL_DEBUG=1 ADD_MODULE=all DO_HTTPD=1
APACI_ARGS='--enable-module=all' 

Here's my perl -V output:

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2.17-8smp, archname=i386-linux
    uname='linux porky.devel.redhat.com 2.2.17-8smp #1 smp fri nov 17
16:12:17 est 2000 i686 unknown '
    config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc
-Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr
-Darchname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm
-Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Uuselargefiles'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=undef 
    use64bitint=undef use64bitall=undef uselongdouble=undef
usesocks=undef
  Compiler:
    cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96
20000731 (Red Hat Linux 7.1 2.96-78)
    cppflags='-fno-strict-aliasing'
    ccflags ='-fno-strict-aliasing'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lc -lcrypt
    libc=/lib/libc-2.2.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl): 
  Compile-time options:
  Built under linux
  Compiled at Apr  3 2001 11:27:33
  @INC:
    /usr/lib/perl5/5.6.0/i386-linux
    /usr/lib/perl5/5.6.0
    /usr/lib/perl5/site_perl/5.6.0/i386-linux
    /usr/lib/perl5/site_perl/5.6.0
    /usr/lib/perl5/site_perl
    .

> Does this happen with a static build?

Yes, indeed it does.

-- 

Richard Goerwitz                               richard@Goerwitz.COM
tel: 401 438 8978

Re: segfault w/ Apache 1.3.20, mod_perl 1.26

Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,

On Sun, 22 Jul 2001, Richard L. Goerwitz III wrote:

> After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an
> Apache server instance that uses a config file with an extensive
> set of <Perl></Perl> sections.  I'm using the Perl that came with
> my Linux (RedHat 7.0) machine, namely 5.6.0.

IIRC there was a problem with the compiler (gcc) that came with RH7.0,
which compiler are you using?

Send us the output of "perl -V" and also the arguments you gave to
Makefile.PL, then when they all get back from the conference maybe
someone will have your answer.

Does this happen with a static build?

(Ducks for cover before Doug reads this... :)

73,
Ged.

PS: Please don't change your subject line, it messes up the thread.



Re: segfault w/ Apache 1.3.20, mod_perl 1.26

Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 22 Jul 2001, Richard L. Goerwitz III wrote:

> I apologize if this problem has already been identified and solved.
> After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an
> Apache server instance that uses a config file with an extensive
> set of <Perl></Perl> sections.  I'm using the Perl that came with
> my Linux (RedHat 7.0) machine, namely 5.6.0.

i can't reproduce with 5.6.1.  can you post a <Perl> section the produces
the segv?



segfault w/ Apache 1.3.20, mod_perl 1.26

Posted by "Richard L. Goerwitz III" <ri...@goerwitz.com>.
I apologize if this problem has already been identified and solved.
After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an
Apache server instance that uses a config file with an extensive
set of <Perl></Perl> sections.  I'm using the Perl that came with
my Linux (RedHat 7.0) machine, namely 5.6.0.

I'm just wondering if the following trace looks familiar to anyone:

Program received signal SIGSEGV, Segmentation fault.
0x81fc2c2 in Perl_sv_free ()
(gdb) bt
#0  0x81fc2c2 in Perl_sv_free ()
#1  0x81d3f74 in Perl_cv_undef ()
#2  0x80ab249 in perl_clear_symtab ()
#3  0x80ab8cf in perl_section ()
#4  0x818aee8 in invoke_cmd ()
#5  0x818b9fe in ap_handle_command ()
#6  0x818ba91 in ap_srm_command_loop ()
#7  0x818c0fe in ap_process_resource_config ()
#8  0x818ca33 in ap_read_config ()
#9  0x8196760 in standalone_main ()
#10 0x819709b in main ()
#11 0x402f4b5c in __libc_start_main (main=0x8196ce8 <main>, argc=4, 
    ubp_av=0xbffff9e4, init=0x807d58c <_init>, fini=0x8233a40 <_fini>, 
    rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffff9dc)
    at ../sysdeps/generic/libc-start.c:129

-- 

Richard Goerwitz                               richard@Goerwitz.COM
tel: 401 438 8978

thttpd v.s. boa (Re: ANNOUNCE: mod_perl guide ver. 1.29)

Posted by Philip Mak <pm...@aaanime.net>.
On Sat, 28 Apr 2001, Stas Bekman wrote:

> * strategy.pod:
>
>   o added a ref to a light and fast Boa webserver

The strategy guide mentions thttpd, khttpd and Boa. khttpd doesn't look to
be production quality yet (its website says that it can crash the kernel),
so that leaves thttpd and Boa.

Which one would be better to use? Here's what I know so far:

- Someone's reported thttpd using over 100 MB of memory, and suggested
  to switch to Boa instead. (the message is in the thttpd mailing list
  archives somewhere... February 2001 I think)

- thttpd's website shows benchmarks where thttpd handles 720 requests per
  second, while Boa only handles 475.

- thttpd supports chroot and throttling. Boa does not.

-Philip Mak (pmak@aaanime.net)