When i am adding virtual tag in apache for mod_perl and restarting it
 says segmentation fault .
 please see below.
 deepak@deepak:~/modperl/MyApache2$ sudo /etc/init.d/apache2 restart
   Restarting web server: apache2  [Sat Feb 23 01:39:53 2008] [error] (EAI 5)No address associated with hostname: Could not resolve host name /perl/ -- ignoring!

  [Sat Feb 23 01:40:23 2008] [error] (EAI 5)No address associated with hostname: Could not resolve host name /perl/ -- ignoring!
 /usr/sbin/apache2ctl: line 83:  9819 Segmentation fault      $HTTPD ${APACHE_ARGUMENTS} -k $ARGV
 failed!


 This what error log says.

 [Sat Feb 23 01:39:53 2008] [notice] caught SIGWINCH, shutting down gracefully


This is what my httpd.conf says.

<VirtualHost /perl/>
	PerlOptions -Enable
</VirtualHost>

Hi,

this is not correct since /perl/ is not a valid ip address or
hostname. Of course, apache shouldn't segfault either. Can you please
provide a backtrace as described in
/usr/share/doc/apache2.2-common/README.backtrace ?

TIA.

Stefan

I had the problem of a segmentation fault.

$ sudo /etc/init.d/apache2 restart
Restarting web server: apache2* We failed to correctly shutdown apache, so
we're now killing all running apache processes. This is almost certainly
suboptimal, so please make sure your system is working as you'd expect now!

apache2: Could not reliably determine the server's fully qualified domain
name, using 192.168.1.20 for ServerName
/usr/sbin/apache2ctl: line 83:  4003 Segmentation fault      $HTTPD
${APACHE_ARGUMENTS} -k $ARGV
 failed!

I upgraded from 2.2.8-4 to 2.2.9-2, hoping to solve the problem:

$ sudo aptitude
(Reading database ... 189183 files and directories currently installed.)
Preparing to replace apache2-utils 2.2.6-2 (using
.../apache2-utils_2.2.9-2_amd64.deb) ...
Unpacking replacement apache2-utils ...
Preparing to replace apache2-mpm-worker 2.2.8-4 (using
.../apache2-mpm-worker_2.2.9-2_amd64.deb) ...
Stopping web server: apache2* We failed to correctly shutdown apache, so
we're now killing all running apache processes. This is almost certainly
suboptimal, so please make sure your system is working as you'd expect now!
.
Unpacking replacement apache2-mpm-worker ...
Preparing to replace apache2.2-common 2.2.8-4 (using
.../apache2.2-common_2.2.9-2_amd64.deb) ...
Unpacking replacement apache2.2-common ...
Preparing to replace apache2 2.2.8-4 (using .../apache2_2.2.9-2_all.deb) ...
Unpacking replacement apache2 ...
Setting up apache2-utils (2.2.9-2) ...
Setting up apache2.2-common (2.2.9-2) ...
Installing new version of config file /etc/init.d/apache2 ...
Setting up apache2-mpm-worker (2.2.9-2) ...
Starting web server: apache2apache2: Could not reliably determine the
server's fully qualified domain name, using 192.168.1.20 for ServerName
/usr/sbin/apache2ctl: line 83:  5805 Segmentation fault      $HTTPD
${APACHE_ARGUMENTS} -k $ARGV
 failed!
invoke-rc.d: initscript apache2, action "start" failed.
Setting up apache2 (2.2.9-2) ...
Press return to continue.

I added "Servername localhost" to httpd.conf to get rid of the FQDN error,
but the segfault remained:

$ sudo /etc/init.d/apache2 restart
Restarting web server: apache2* We failed to correctly shutdown apache, so
we're now killing all running apache processes. This is almost certainly
suboptimal, so please make sure your system is working as you'd expect now!
 ... waiting /usr/sbin/apache2ctl: line 83:  5934 Segmentation fault
$HTTPD ${APACHE_ARGUMENTS} -k $ARGV
 failed!

Message #10 for this bug suggests doing a backtrace.  I followed the
instructions in README.backtrace, installing -dbg packages.  I updated gdb
while I was at it.  Some other packages (libapr1, libaprutil1) were
automatically updated.

$ sudo aptitude
(Reading database ... 189180 files and directories currently installed.)
Preparing to replace gdb 6.6.dfsg.90.20070912-1 (using
.../archives/gdb_6.7.1-2_amd64.deb) ...
Unpacking replacement gdb ...
Preparing to replace libapr1 1.2.11-1 (using .../libapr1_1.2.12-4_amd64.deb)
...
Unpacking replacement libapr1 ...
Preparing to replace libaprutil1 1.2.7+dfsg-2+b1 (using
.../libaprutil1_1.2.12+dfsg-3_amd64.deb) ...
Unpacking replacement libaprutil1 ...
Selecting previously deselected package apache2-dbg.
Unpacking apache2-dbg (from .../apache2-dbg_2.2.9-2_amd64.deb) ...
Selecting previously deselected package libapr1-dbg.
Unpacking libapr1-dbg (from .../libapr1-dbg_1.2.12-4_amd64.deb) ...
Selecting previously deselected package libaprutil1-dbg.
Unpacking libaprutil1-dbg (from .../libaprutil1-dbg_1.2.12+dfsg-3_amd64.deb)
...
Setting up gdb (6.7.1-2) ...
Setting up libapr1 (1.2.12-4) ...
Setting up libaprutil1 (1.2.12+dfsg-3) ...
Setting up apache2-dbg (2.2.9-2) ...
Setting up libapr1-dbg (1.2.12-4) ...
Setting up libaprutil1-dbg (1.2.12+dfsg-3) ...
Press return to continue.

I added "CoreDumpDirectory /var/cache/apache2" to httpd.conf.
I now stop and start apache2 as instructed

$ sudo su
# cd /etc
# init.d/apache2 stop
Stopping web server: apache2 ... waiting .
# ulimit -c unlimited
# init.d/apache2 start
Starting web server: apache2.
root@pictorm:/etc# exit
exit

No error, so I try without root, after commenting out "CoreDumpDirectory
/var/cache/apache2":

$ sudo /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting .

Works.  And the error log looks good as well:

$ sudo su
# cd /var/log/apache2
# tail -11 error.log
[Tue Jul 08 01:15:36 2008] [notice] Apache/2.2.9 (Debian) mod_perl/2.0.4
Perl/v5.10.0 configured -- resuming normal operations
[Tue Jul 08 01:33:16 2008] [notice] caught SIGTERM, shutting down
[Tue Jul 08 01:33:16 2008] [notice] seg fault or similar nasty error
detected in the parent process
[Tue Jul 08 01:33:17 2008] [notice] Apache/2.2.9 (Debian) mod_perl/2.0.4
Perl/v5.10.0 configured -- resuming normal operations
[Tue Jul 08 01:42:37 2008] [notice] caught SIGTERM, shutting down
[Tue Jul 08 01:42:37 2008] [notice] seg fault or similar nasty error
detected in the parent process
[Tue Jul 08 01:43:11 2008] [notice] Apache/2.2.9 (Debian) mod_perl/2.0.4
Perl/v5.10.0 configured -- resuming normal operations
[Tue Jul 08 01:43:36 2008] [notice] caught SIGTERM, shutting down
[Tue Jul 08 01:43:38 2008] [notice] Apache/2.2.9 (Debian) mod_perl/2.0.4
Perl/v5.10.0 configured -- resuming normal operations
[Tue Jul 08 01:45:21 2008] [notice] caught SIGTERM, shutting down
[Tue Jul 08 01:45:22 2008] [notice] Apache/2.2.9 (Debian) mod_perl/2.0.4
Perl/v5.10.0 configured -- resuming normal operations
#

All I can think of is that libapr1 and/or libaprutil1 were too old.
However, they should have been installed with apache2 when I installed it a
few weeks ago - previously I had been running apache-perl which doesn't
depend on those packages.

The bug is no longer an issue for me, but hopefully this helps someone get
to the bottom of it...

Mark

I have setup a valid (I suppose) config for 2 virtual hosts, one for port 80, one for port 443.

Port 443 configured through :

<VirtualHost *:443>
...
        # for mod_perl and TWiki
        PerlRequire /var/lib/twiki/tools/mod_perl_startup.pl
        # Turn on taint checking
        PerlSwitches -T
</VirtualHost> (in a dedicated /etc/apache2/sites-enabled/060-ssl file)

and Port 80 :
<VirtualHost *:80>
#       PerlOptions -Enable
</VirtualHost> (in a dedicated /etc/apache2/sites-enabled/000-default file)

If I uncomment the PerlOptions in /etc/apache2/sites-enabled/000-default apache restart segfaults :(

So I think that the virtualhost syntax for first report was not the problem.

There's indeed something weird with activating mod_perl on one virtualhost and disactivating it on another, or more simply with "PerlOptions -Enable" at all.

Hope this helps.

May try to debug more the fault, but this is a production server, so I'm not so keen on breaking it so much.

Best regards,

More details at : http://mail-archives.apache.org/mod_mbox/perl-modperl/200707.mbox/<4693E9EF.4060907@ocf.berkeley.edu> (including patch)

Hope this helps, though.

tags 472647 - moreinfo
retitle 472647 "Segfault with PerlOptions -Enable in virtualhost"
thanks

I guess there's significant evidence of the reproductibility conditions, although upstream apparently is waiting for more help to validate the fix.

Maybe the maintainer knows the best way to try and re-activate action on such issue ?

Best regards,

I think it's also related to this bug.
When you try to set "PerlOptions +Parent" in some enabled vhost, httpd
segfaults on any command.
mod-perl 2.0.4-5 does not; indeed, Etch has 2.0.2-2.4 so you couldn't use
+Parent on etch... (I solved this problem building 2.0.4-5 debs from
dpkg-source on Etch)
Sorry for probably messy English.

I have also this problem.

If I add in the virtual host "PerlOptions -Enable"
I got error apache2 ... waiting /usr/sbin/apache2ctl: line 83:  4933 Segmentation fault      $HTTPD ${APACHE_ARGUMENTS} -k $ARGV
 failed!


Apache 2.2.9-10+lenny4

I'm having a similar problem, apache segfaulting when I have

PerlOptions +Parent

In a virtual host.

However, this has only started recently on my sid system. It certainly
wasn't occurring back in January when Vitaliy Filippov reported having
this problem. The problem also doesn't occur on the lenny system where
my website is currently deployed.

The last time it was working correctly, was November 16th.

It was definitely broken on November 18th.

Unfortunately when it does segfault, the logs contain a stack trace, but
no date, so I can't pin down exactly when it broke.

However, according to my aptitude logs, apache related packages were
updated on November 8th:

[UPGRADE] apache2 2.2.14-1 -> 2.2.14-2
[UPGRADE] apache2-mpm-worker 2.2.14-1 -> 2.2.14-2
[UPGRADE] apache2-utils 2.2.14-1 -> 2.2.14-2
[UPGRADE] apache2.2-bin 2.2.14-1 -> 2.2.14-2
[UPGRADE] apache2.2-common 2.2.14-1 -> 2.2.14-2

And then again on November 22nd:

[UPGRADE] apache2 2.2.14-2 -> 2.2.14-3
[UPGRADE] apache2-mpm-worker 2.2.14-2 -> 2.2.14-3
[UPGRADE] apache2-utils 2.2.14-2 -> 2.2.14-3
[UPGRADE] apache2.2-bin 2.2.14-2 -> 2.2.14-3
[UPGRADE] apache2.2-common 2.2.14-2 -> 2.2.14-3
...
[UPGRADE] libapache2-mod-apreq2 2.08-5+b1 -> 2.08-5.1
[UPGRADE] libapache2-request-perl 2.08-5+b1 -> 2.08-5.1

Which doesn't correspond to when I started getting this problem.

I've attached a snippet of my apache error log that contains a backtrace
and memory map. I don't know if it's useful at all.

Ignore my comment on this bug.

Further testing show that it's specific modules being loaded that causes
the problem, not specific PerlOptions.

Clearly there's a bug somewhere, but I'm not sure what package is at
fault, and it doesn't seem related to this bug report anymore.