You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Vincent Moneymaker <vb...@hotmail.com> on 2005/04/23 06:35:39 UTC

Apache2::Reload Segmentation Fault

I am running Apache 2.0.52 on a solaris 8 box with mod_perl-2.0.0-RC5.  I 
previously had problems using Apache::Reload with mod_perl 1.99_19 version 
back in December and gave up trying to find a fix.  I thought I would try 
again with the RC5 version but after having upgraded from mod_perl 1.99_12 
to RC5 I am getting segmentation fault errors when the Apache2::Reload 
module is present in my httpd.conf file and a change is then made in a 
module and the web page that is created via the changed module is then 
called up.  I know that the segmentation fault is related to the 
Apache2::Reload module because the segmentation fault errors don't appear 
when the same change is made in the module (i.e. a simple print statement) 
but without Apache2::Reload being present in the httpd.conf file.

My httpd.conf contains the following with respect to Apache2::Reload

PerlRequire "/opt/prod/apache/programs/startup.pl"
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload


My startup.pl file starts with the following, with the modules in the 
Apache2 and Melior namespaces being listed after this beginning part

BEGIN {

use lib "/opt/prod/apache";
use lib "/opt/prod/apache/nfs";
use lib "/opt/prod/apache/test-mck/mck-cgi";
use lib "/opt/prod/apache/Apache2";
use lib "/opt/prod/apache/Melior";
use CGI::Carp qw(carpout);
  open(LOG, ">>/opt/prod/apache/logs/error_log") or die "Unable to append to 
/opt/prod/apache1/logs/error_log: $! [See the 'startup.pl' program - 1]\n";
  carpout(*LOG);
}


The following is a sample of the segmentation fault errors I am getting when 
Apache2::Reload is listed in the httpd.conf file

[Fri Apr 22 20:59:17 2005] [notice] child pid 22432 exit signal Segmentation 
fault (11)
[Fri Apr 22 20:59:17 2005] [notice] child pid 22431 exit signal Segmentation 
fault (11)
[Fri Apr 22 20:59:25 2005] [notice] child pid 22433 exit signal Segmentation 
fault (11)
[Fri Apr 22 20:59:30 2005] [notice] child pid 22434 exit signal Segmentation 
fault (11)
[Fri Apr 22 20:59:31 2005] [notice] child pid 22435 exit signal Segmentation 
fault (11)
[Fri Apr 22 20:59:32 2005] [notice] child pid 22436 exit signal Segmentation 
fault (11)


And the same things happen when 'PerlSetVar ReloadDebug On' debug mode is 
turned on (below is a sample from the error_log file with the debug mode 
turned on).

[Fri Apr 22 20:09:14 2005] [notice] child pid 21682 exit signal Segmentation 
fault (11)


Again, the segmentation faults only occur when Apache2::Reload is loaded and 
changes are then made to the modules in the Apache2 namespace.  Any help on 
this would be appreciated.


Thanks, Vince Moneymaker



Re: Apache2::Reload Segmentation Fault

Posted by Stas Bekman <st...@stason.org>.
Vincent Moneymaker wrote:
> Stas Bekman wrote:
> 
>>>I discovered what was causing the problem.  Even though I had used the
>>>following in the startup.pl file
>>>
>>>use Apache2::Const -compile => ':common';
>>>
>>>the Apache modules were segfaulting on the straight 'OK' constant
>>>declarations in them.
>>
>>Vincent, what do you mean by 'declaration' here? You mean you've used it?
> 
> 
> In modules where a constant such as 'OK' gets returned (like so)
> 
> sub handler {
>   print "a\n";
>   return OK;
> }
> 
> I had to change the 'OK' constant to the following
> 
> sub handler {
>   print "a\n"
>   return Apache2::Const::OK;
> }

You can't use OK, unless you do:

use Apache2::Const qw(OK);

in each module you use it. It needs to be imported.

> Bear in mind that 'return OK' worked fine if I didn't change a module, but
> if I changed something in the module like a print statement and
> Apache2::Reload was on and the module was then reloaded, that is when the
> segfault would occur
> 
> Also, if the module had a 'use Apache2::Const qw(OK);' statement, I had to
> remove those like so
> 
> package Apache2::Menus;
> 
> #use Apache2::Const qw(OK);
> 
> sub handler {
>   print "a\n";
>   return Apache2::Const::OK;
> }
> 
> So now, whenever I change a module, the change shows up and no segfault
> occurs.  With respect to duplicating the problem, I will keep trying to
> duplicate it in the test tarball that you sent me so that I can duplicate it
> for you.

Great. Thanks. But post it to the list.

> With regard to the reload problem where one *.pm file calls another *.pm
> file but changes in the second *.pm file don't show up, I have fixed that
> problem by using the old Apache::Reload code (i.e. version 0.08) where
> Modperl::Util::unload_package doesn't get used.  Using that old code,
> everything works fine.

Cool. So we know whose fault is that. Hopefully you will make up another 
tarball that reproduces this problem too. Thanks!


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache2::Reload Segmentation Fault

Posted by Vincent Moneymaker <vb...@hotmail.com>.
Stas Bekman wrote:
> > I discovered what was causing the problem.  Even though I had used the
> > following in the startup.pl file
> >
> > use Apache2::Const -compile => ':common';
> >
> > the Apache modules were segfaulting on the straight 'OK' constant
> > declarations in them.
>
> Vincent, what do you mean by 'declaration' here? You mean you've used it?

In modules where a constant such as 'OK' gets returned (like so)

sub handler {
  print "a\n";
  return OK;
}

I had to change the 'OK' constant to the following

sub handler {
  print "a\n"
  return Apache2::Const::OK;
}

Bear in mind that 'return OK' worked fine if I didn't change a module, but
if I changed something in the module like a print statement and
Apache2::Reload was on and the module was then reloaded, that is when the
segfault would occur

Also, if the module had a 'use Apache2::Const qw(OK);' statement, I had to
remove those like so

package Apache2::Menus;

#use Apache2::Const qw(OK);

sub handler {
  print "a\n";
  return Apache2::Const::OK;
}

So now, whenever I change a module, the change shows up and no segfault
occurs.  With respect to duplicating the problem, I will keep trying to
duplicate it in the test tarball that you sent me so that I can duplicate it
for you.

> > However, the other modules I have in the Melior namespace are not
> > getting reloaded.  Apparently the reason for this as noted in the
> > following post at
> >
http://forums.devside.net/viewtopic.php?t=671&start=0&postdays=0&postorder=asc&highlight=
> >
> > is that they are being called from within the Apache2 modules.  In other
> > words, because the Melior modules only get requested by modules in the
> > Apache2 namespace, they don't get reloaded even though their own
> > separate namespace is declared within them, as well as in the Apache2
> > modules and the startup.pl file.
>
> Vincent, please send in a tarball with a minimum setup reproducing the
> problem. I don't undestand from your description what's not right.
>
> > With regard to debugging this problem, the reload debugger shows that
> > the Melior modules do get reloaded when they change but the change
> > doesn't show up on the page that gets spit out.  Here is a sample from
> > the error_log
> >
> > #Apache2::Reload: process 24620 reloading Melior::Menus from
> > Melior/Menus.pm
> > # Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)')
> > called at /opt/prod/apache/Melior/Menus.pm line 0
> > # eval {...} called at /opt/prod/apache/Melior/Menus.pm line 0
> > # Apache2::Reload: Checking mtime of CCMckErrno3_2.pm
> > # Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)')
> > called at -e line 0
> > # eval {...} called at -e line 0
>
> Have you looked at this item?
>
http://perl.apache.org/docs/2.0/api/Apache2/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code
>
> > BTW, as I mentioned last time, I believe this problem first cropped up
> > with modperl version 1.99.17.  If you have any suggestions on what I
> > should tinker with in order to get modules called by other modules
> > reloaded that would be great.
>
> The only suggestion I have at the moment is that we need to be able to
> reproduce the problem... :)
>

With regard to the reload problem where one *.pm file calls another *.pm
file but changes in the second *.pm file don't show up, I have fixed that
problem by using the old Apache::Reload code (i.e. version 0.08) where
Modperl::Util::unload_package doesn't get used.  Using that old code,
everything works fine.





Re: Apache2::Reqest

Posted by Dan Brian <da...@brians.org>.
> This is for apreq-dev@perl.apache.org. Also, search those archives... 
> they hold more answers :)

It's not usually easy to get help compiling a nightly dev shapshot on 
any list (thus, the "dev snapshot" part). I figured that since the 
newer mp2 leaves this group the CVS ... doh, I mean, SVN :P, version as 
the only option for Request.pm, that I could ask here without a 
redirect. :-)

> Try the tarball at http://people.apache.org/~joes  (2.05-dev) a 
> developer preview release.

Thanks, will do.


Re: Apache2::Reqest

Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Dan Brian wrote:

> I'm sure this has been discussed in recent days, but I couldn't find 
> the thread.
>
> Has anyone succeeded in getting the CVS version of libapreq 
> (Apache2::Request) to work with the newer-namespace mp2? I can't get 
> the CVS version to compile, but wondered if there was a working 
> snapshot anyone was aware of (since libapreq2-2.04-dev is still the 
> latest on apache.org), or if my case was isolated. I'll spend more 
> time on it if there are people running Apache2::Request without any 
> problems.

This is for apreq-dev@perl.apache.org. Also, search those archives... 
they hold more answers :)

Try the tarball at http://people.apache.org/~joes  (2.05-dev) a 
developer preview release.

Also, CVS is a thing of the past... Use SVN.



-- 
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone:  202.558.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web:    http://www.liquidation.com


Apache2::Reqest

Posted by Dan Brian <da...@brians.org>.
I'm sure this has been discussed in recent days, but I couldn't find 
the thread.

Has anyone succeeded in getting the CVS version of libapreq 
(Apache2::Request) to work with the newer-namespace mp2? I can't get 
the CVS version to compile, but wondered if there was a working 
snapshot anyone was aware of (since libapreq2-2.04-dev is still the 
latest on apache.org), or if my case was isolated. I'll spend more time 
on it if there are people running Apache2::Request without any 
problems.

Thanks,
Dan


Re: Apache2::Reload Segmentation Fault

Posted by Stas Bekman <st...@stason.org>.
Vincent Moneymaker wrote:
> Vince Moneymaker wrote:
> 
>>> Okay, all of the tests are being passed.  I have added the contents 
>>> of my startup.pl file to the modperl_startup.pl file and no segfaults 
>>> are occurring including even when I change the Handler.pm file as the 
>>> tests are being run on it.  I have also added some items to the conf 
>>> file to try and reproduced how my httpd.conf file is set up and again 
>>> no segfaults.  Should I go the whole way and add the entire contents 
>>> of my httpd.conf file to the test conf file?  Or is there some other 
>>> approach I should take in order to reproduce the problem?
>>
>>
>> Stas Bekman wrote
>>
>> Yes, the easiest approach is to start with everything that you have 
>> and you get a segfault. And then follow the "binary search" approach, 
>> where you try to cut the stuff to the minimum but trying to remove 
>> halves of config/code/whatever.
>>
>>
> I discovered what was causing the problem.  Even though I had used the 
> following in the startup.pl file
> 
> use Apache2::Const -compile => ':common';
> 
> the Apache modules were segfaulting on the straight 'OK' constant 
> declarations in them. 

Vincent, what do you mean by 'declaration' here? You mean you've used it?

> So I fixed the problem by replacing the above 
> line with the following line in the startup.pl file
> 
> use Apache2::Const -compile => qw(OK REDIRECT FORBIDDEN SERVER_ERROR);
> 
> I then went through each Apache module and removed the 'use 
> Apache2::Const' declarations and  changed all of the 'OK' constants to 
> Apache2::Const::OK .  I did the same thing for the REDIRECT, FORBIDDEN, 
> etc constants in the modules.  The only problem I am still having is 
> with the REMOTE_HOST constant which caused a changed module to segfault 
> no matter how I declare it.
> Otherwise, all of the Apache modules work fine.

Well, I'm still not clear on what was your setup like. If you can submit a 
tarball that reproduces the problem, I'll look at it.

> However, the other modules I have in the Melior namespace are not 
> getting reloaded.  Apparently the reason for this as noted in the 
> following post at
> http://forums.devside.net/viewtopic.php?t=671&start=0&postdays=0&postorder=asc&highlight= 
> 
> is that they are being called from within the Apache2 modules.  In other 
> words, because the Melior modules only get requested by modules in the 
> Apache2 namespace, they don't get reloaded even though their own 
> separate namespace is declared within them, as well as in the Apache2 
> modules and the startup.pl file.

Vincent, please send in a tarball with a minimum setup reproducing the 
problem. I don't undestand from your description what's not right.

> With regard to debugging this problem, the reload debugger shows that 
> the Melior modules do get reloaded when they change but the change 
> doesn't show up on the page that gets spit out.  Here is a sample from 
> the error_log
> 
> #Apache2::Reload: process 24620 reloading Melior::Menus from 
> Melior/Menus.pm
> # Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)') 
> called at /opt/prod/apache/Melior/Menus.pm line 0
> # eval {...} called at /opt/prod/apache/Melior/Menus.pm line 0
> # Apache2::Reload: Checking mtime of CCMckErrno3_2.pm
> # Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)') 
> called at -e line 0
> # eval {...} called at -e line 0

Have you looked at this item?
http://perl.apache.org/docs/2.0/api/Apache2/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code

> BTW, as I mentioned last time, I believe this problem first cropped up 
> with modperl version 1.99.17.  If you have any suggestions on what I 
> should tinker with in order to get modules called by other modules 
> reloaded that would be great.

The only suggestion I have at the moment is that we need to be able to 
reproduce the problem... :)

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache2::Reload Segmentation Fault

Posted by Vincent Moneymaker <vb...@hotmail.com>.
Vince Moneymaker wrote:
>>Okay, all of the tests are being passed.  I have added the contents of my 
>>startup.pl file to the modperl_startup.pl file and no segfaults are 
>>occurring including even when I change the Handler.pm file as the tests 
>>are being run on it.  I have also added some items to the conf file to try 
>>and reproduced how my httpd.conf file is set up and again no segfaults.  
>>Should I go the whole way and add the entire contents of my httpd.conf 
>>file to the test conf file?  Or is there some other approach I should take 
>>in order to reproduce the problem?
>
>Stas Bekman wrote
>
>Yes, the easiest approach is to start with everything that you have and you 
>get a segfault. And then follow the "binary search" approach, where you try 
>to cut the stuff to the minimum but trying to remove halves of 
>config/code/whatever.
>
>
I discovered what was causing the problem.  Even though I had used the 
following in the startup.pl file

use Apache2::Const -compile => ':common';

the Apache modules were segfaulting on the straight 'OK' constant 
declarations in them.  So I fixed the problem by replacing the above line 
with the following line in the startup.pl file

use Apache2::Const -compile => qw(OK REDIRECT FORBIDDEN SERVER_ERROR);

I then went through each Apache module and removed the 'use Apache2::Const' 
declarations and  changed all of the 'OK' constants to Apache2::Const::OK .  
I did the same thing for the REDIRECT, FORBIDDEN, etc constants in the 
modules.  The only problem I am still having is with the REMOTE_HOST 
constant which caused a changed module to segfault no matter how I declare 
it.
Otherwise, all of the Apache modules work fine.

However, the other modules I have in the Melior namespace are not getting 
reloaded.  Apparently the reason for this as noted in the following post at
http://forums.devside.net/viewtopic.php?t=671&start=0&postdays=0&postorder=asc&highlight=
is that they are being called from within the Apache2 modules.  In other 
words, because the Melior modules only get requested by modules in the 
Apache2 namespace, they don't get reloaded even though their own separate 
namespace is declared within them, as well as in the Apache2 modules and the 
startup.pl file.

With regard to debugging this problem, the reload debugger shows that the 
Melior modules do get reloaded when they change but the change doesn't show 
up on the page that gets spit out.  Here is a sample from the error_log

#Apache2::Reload: process 24620 reloading Melior::Menus from Melior/Menus.pm
# Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)') called 
at /opt/prod/apache/Melior/Menus.pm line 0
# eval {...} called at /opt/prod/apache/Melior/Menus.pm line 0
# Apache2::Reload: Checking mtime of CCMckErrno3_2.pm
# Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)') called 
at -e line 0
# eval {...} called at -e line 0

BTW, as I mentioned last time, I believe this problem first cropped up with 
modperl version 1.99.17.  If you have any suggestions on what I should 
tinker with in order to get modules called by other modules reloaded that 
would be great.

And again thanks for all of your help, Vince



Re: Apache2::Reload Segmentation Fault

Posted by Stas Bekman <st...@stason.org>.
Vincent Moneymaker wrote:

>>>> OK, so yours crash is in require, Vincent. Any chance you could 
>>>> prepare a tarball that reproduces the problem, so Philippe can 
>>>> reproduce it easily?
>>>>
>>>> Please grab the template from geoff's site:
>>>> http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
>>>>
>>>> In fact better use the attachment in this message:
>>>> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=111145170703909&w=2 
>>>>
>>>> it's already designed for this specific problem. Just swap my setup 
>>>> with yours.
>>>>
>>>> Please don't hesitate to ask questions if you have any, Vincent.
>>>>
> 
> 
> Okay, all of the tests are being passed.  I have added the contents of 
> my startup.pl file to the modperl_startup.pl file and no segfaults are 
> occurring including even when I change the Handler.pm file as the tests 
> are being run on it.  I have also added some items to the conf file to 
> try and reproduced how my httpd.conf file is set up and again no 
> segfaults.  Should I go the whole way and add the entire contents of my 
> httpd.conf file to the test conf file?  Or is there some other approach 
> I should take in order to reproduce the problem?

Yes, the easiest approach is to start with everything that you have and 
you get a segfault. And then follow the "binary search" approach, where 
you try to cut the stuff to the minimum but trying to remove halves of 
config/code/whatever.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache2::Reload Segmentation Fault

Posted by Vincent Moneymaker <vb...@hotmail.com>.
Vincent Moneymaker wrote

>Vincent Moneymaker wrote:
>>>Vincent Moneymaker wrote:
>>>
>>>>Here is the output from the backtrace (hope I did it correctly)
>>>>
>>>>
>>>>Program received signal SIGSEGV, Segmentation fault.
>>>>0xdeb3618f in Perl_gv_efullname3 () from 
>>>>/opt/prod/apache/modules/mod_perl.so
>>>>(gdb) bt
>>>
>>>
>>>>#6  0xdeb9293f in Perl_pp_require () from 
>>>>/opt/prod/apache/modules/mod_perl.so
>>>>#7  0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69
>>>>#8  0xdeb6d61e in Perl_runops_standard ()
>>>>   from /opt/prod/apache/modules/mod_perl.so
>>>>#9  0xdeb31361 in S_call_body () from 
>>>>/opt/prod/apache/modules/mod_perl.so
>>>
>>>
>>Stas Bekman wrote:
>>
>>>
>>>OK, so yours crash is in require, Vincent. Any chance you could prepare a 
>>>tarball that reproduces the problem, so Philippe can reproduce it easily?
>>>
>>>Please grab the template from geoff's site:
>>>http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
>>>
>>>In fact better use the attachment in this message:
>>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=111145170703909&w=2
>>>it's already designed for this specific problem. Just swap my setup with 
>>>yours.
>>>
>>>Please don't hesitate to ask questions if you have any, Vincent.
>>>


Okay, all of the tests are being passed.  I have added the contents of my 
startup.pl file to the modperl_startup.pl file and no segfaults are 
occurring including even when I change the Handler.pm file as the tests are 
being run on it.  I have also added some items to the conf file to try and 
reproduced how my httpd.conf file is set up and again no segfaults.  Should 
I go the whole way and add the entire contents of my httpd.conf file to the 
test conf file?  Or is there some other approach I should take in order to 
reproduce the problem?



Re: Apache2::Reload Segmentation Fault

Posted by Stas Bekman <st...@stason.org>.
Vincent Moneymaker wrote:
>> Vincent Moneymaker wrote:
>>
>>> Here is the output from the backtrace (hope I did it correctly)
>>>
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0xdeb3618f in Perl_gv_efullname3 () from 
>>> /opt/prod/apache/modules/mod_perl.so
>>> (gdb) bt
>>
>>
>>> #6  0xdeb9293f in Perl_pp_require () from 
>>> /opt/prod/apache/modules/mod_perl.so
>>> #7  0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69
>>> #8  0xdeb6d61e in Perl_runops_standard ()
>>>   from /opt/prod/apache/modules/mod_perl.so
>>> #9  0xdeb31361 in S_call_body () from 
>>> /opt/prod/apache/modules/mod_perl.so
>>
>>
> Stas Bekman wrote:
> 
>>
>> OK, so yours crash is in require, Vincent. Any chance you could 
>> prepare a tarball that reproduces the problem, so Philippe can 
>> reproduce it easily?
>>
>> Please grab the template from geoff's site:
>> http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
>>
>> In fact better use the attachment in this message:
>> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=111145170703909&w=2
>> it's already designed for this specific problem. Just swap my setup 
>> with yours.
>>
>> Please don't hesitate to ask questions if you have any, Vincent.
>>
> 
> I downloaded your attachment and I get the following with 'use Apache2 
> ();' in the Makefile.PL
> 
> Can't locate Apache2.pm in @INC (@INC contains: 
> /usr/local/lib/perl5/5.8.0/i86pc-solaris /usr/local/lib/perl5/5.8.0 
> /usr/local/lib/perl5/site_perl/5.8.0/i86pc-solaris 
> /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) 
> at Makefile.PL line 3.
> BEGIN failed--compilation aborted at Makefile.PL line 3.
> 
> When I pull out 'use Apache2 ();', I then the server starts and I get 
> the following error in the error_log
> 
> [Sat Apr 23 10:08:28 2005] [error] [client 127.0.0.1] Can't locate 
> object method
> "dir_config" via package "Apache2::RequestRec" at 
> /usr/local/lib/perl5/site_per
> l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n
> [Sat Apr 23 10:08:31 2005] [error] [client 127.0.0.1] Can't locate 
> object method
> "dir_config" via package "Apache2::RequestRec" at 
> /usr/local/lib/perl5/site_per
> l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n
> [Sat Apr 23 10:08:31 2005] [info] removed PID file 
> /home/vince/mod_perl-2.0.0-RC
> 5/AR-segv-mp2/t/logs/httpd.pid (pid=17237)
> [Sat Apr 23 10:08:31 2005] [notice] caught SIGTERM, shutting down

Yes, sorry, it was created before the move to the Apache2:: name space. 
I've attached a new version which works with RC5.

> The Reload module in the Apache namespace is the old 0.08 Reload 
> module.  When I place a copy of the new 0.09 version of Reload that is 
> in the Apache2 namespace in the Apache namespace, the server won't 
> start.  I suspect I am doing something wrong. 

No, it should be Apache2::Reload coming with RC5. as mentioned above that 
tarball needed a fixup.

> Also, when you talk about 
> preparing a tarball that reproduces the problem, could you give me a 
> pointer on how I prepare that so I can send one to Philippe?

That's the tarball you've been trying to use. Vincent, please try again 
with the fixed attachment.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache2::Reload Segmentation Fault

Posted by Vincent Moneymaker <vb...@hotmail.com>.
>Vincent Moneymaker wrote:
>
>>Here is the output from the backtrace (hope I did it correctly)
>>
>>
>>Program received signal SIGSEGV, Segmentation fault.
>>0xdeb3618f in Perl_gv_efullname3 () from 
>>/opt/prod/apache/modules/mod_perl.so
>>(gdb) bt
>
>>#6  0xdeb9293f in Perl_pp_require () from 
>>/opt/prod/apache/modules/mod_perl.so
>>#7  0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69
>>#8  0xdeb6d61e in Perl_runops_standard ()
>>   from /opt/prod/apache/modules/mod_perl.so
>>#9  0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so
>
Stas Bekman wrote:
>
>OK, so yours crash is in require, Vincent. Any chance you could prepare a 
>tarball that reproduces the problem, so Philippe can reproduce it easily?
>
>Please grab the template from geoff's site:
>http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
>
>In fact better use the attachment in this message:
>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=111145170703909&w=2
>it's already designed for this specific problem. Just swap my setup with 
>yours.
>
>Please don't hesitate to ask questions if you have any, Vincent.
>

I downloaded your attachment and I get the following with 'use Apache2 ();' 
in the Makefile.PL

Can't locate Apache2.pm in @INC (@INC contains: 
/usr/local/lib/perl5/5.8.0/i86pc-solaris /usr/local/lib/perl5/5.8.0 
/usr/local/lib/perl5/site_perl/5.8.0/i86pc-solaris 
/usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at 
Makefile.PL line 3.
BEGIN failed--compilation aborted at Makefile.PL line 3.

When I pull out 'use Apache2 ();', I then the server starts and I get the 
following error in the error_log

[Sat Apr 23 10:08:28 2005] [error] [client 127.0.0.1] Can't locate object 
method
"dir_config" via package "Apache2::RequestRec" at 
/usr/local/lib/perl5/site_per
l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n
[Sat Apr 23 10:08:31 2005] [error] [client 127.0.0.1] Can't locate object 
method
"dir_config" via package "Apache2::RequestRec" at 
/usr/local/lib/perl5/site_per
l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n
[Sat Apr 23 10:08:31 2005] [info] removed PID file 
/home/vince/mod_perl-2.0.0-RC
5/AR-segv-mp2/t/logs/httpd.pid (pid=17237)
[Sat Apr 23 10:08:31 2005] [notice] caught SIGTERM, shutting down

The Reload module in the Apache namespace is the old 0.08 Reload module.  
When I place a copy of the new 0.09 version of Reload that is in the Apache2 
namespace in the Apache namespace, the server won't start.  I suspect I am 
doing something wrong.  Also, when you talk about preparing a tarball that 
reproduces the problem, could you give me a pointer on how I prepare that so 
I can send one to Philippe?

Thanks, Vince



Re: Apache2::Reload Segmentation Fault

Posted by Stas Bekman <st...@stason.org>.
Vincent Moneymaker wrote:
> 
> 
>> Vincent Moneymaker wrote:
>>
>>> I am running Apache 2.0.52 on a solaris 8 box with 
>>> mod_perl-2.0.0-RC5.  I previously had problems using Apache::Reload 
>>> with mod_perl 1.99_19 version back in December and gave up trying to 
>>> find a fix.  I thought I would try again with the RC5 version but 
>>> after having upgraded from mod_perl 1.99_12 to RC5 I am getting 
>>> segmentation fault errors when the Apache2::Reload module is present 
>>> in my httpd.conf file and a change is then made in a module and the 
>>> web page that is created via the changed module is then called up.  I 
>>> know that the segmentation fault is related to the Apache2::Reload 
>>> module because the segmentation fault errors don't appear when the 
>>> same change is made in the module (i.e. a simple print statement) but 
>>> without Apache2::Reload being present in the httpd.conf file.
>>
>>
>> Stas Bekman wrote:
>> It's probably related to the similar segfaults I've been seeing and 
>> reported here [1]. But if you don't show the backtrace of the core 
>> file as explained at http://perl.apache.org/bugs/ we will never know.
>>
>> I've CC'ed Philippe on this one, hoping that he will find the time to 
>> fix this problem.
> 
> 
> 
> Here is the output from the backtrace (hope I did it correctly)
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xdeb3618f in Perl_gv_efullname3 () from 
> /opt/prod/apache/modules/mod_perl.so
> (gdb) bt

> #6  0xdeb9293f in Perl_pp_require () from 
> /opt/prod/apache/modules/mod_perl.so
> #7  0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69
> #8  0xdeb6d61e in Perl_runops_standard ()
>   from /opt/prod/apache/modules/mod_perl.so
> #9  0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so


OK, so yours crash is in require, Vincent. Any chance you could prepare a 
tarball that reproduces the problem, so Philippe can reproduce it easily?

Please grab the template from geoff's site:
http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz

In fact better use the attachment in this message:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=111145170703909&w=2
it's already designed for this specific problem. Just swap my setup with 
yours.

Please don't hesitate to ask questions if you have any, Vincent.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache2::Reload Segmentation Fault

Posted by Vincent Moneymaker <vb...@hotmail.com>.

>Vincent Moneymaker wrote:
>>I am running Apache 2.0.52 on a solaris 8 box with mod_perl-2.0.0-RC5.  I 
>>previously had problems using Apache::Reload with mod_perl 1.99_19 version 
>>back in December and gave up trying to find a fix.  I thought I would try 
>>again with the RC5 version but after having upgraded from mod_perl 1.99_12 
>>to RC5 I am getting segmentation fault errors when the Apache2::Reload 
>>module is present in my httpd.conf file and a change is then made in a 
>>module and the web page that is created via the changed module is then 
>>called up.  I know that the segmentation fault is related to the 
>>Apache2::Reload module because the segmentation fault errors don't appear 
>>when the same change is made in the module (i.e. a simple print statement) 
>>but without Apache2::Reload being present in the httpd.conf file.
>
>Stas Bekman wrote:
>It's probably related to the similar segfaults I've been seeing and 
>reported here [1]. But if you don't show the backtrace of the core file as 
>explained at http://perl.apache.org/bugs/ we will never know.
>
>I've CC'ed Philippe on this one, hoping that he will find the time to fix 
>this problem.


Here is the output from the backtrace (hope I did it correctly)


Program received signal SIGSEGV, Segmentation fault.
0xdeb3618f in Perl_gv_efullname3 () from 
/opt/prod/apache/modules/mod_perl.so
(gdb) bt
#0  0xdeb3618f in Perl_gv_efullname3 ()
   from /opt/prod/apache/modules/mod_perl.so
#1  0xdeb4ba96 in S_gv_ename () from /opt/prod/apache/modules/mod_perl.so
#2  0xdeb57917 in Perl_ck_subr () from /opt/prod/apache/modules/mod_perl.so
#3  0xdeb4faf2 in Perl_newUNOP () from /opt/prod/apache/modules/mod_perl.so
#4  0xdeb4b706 in Perl_yyparse () from /opt/prod/apache/modules/mod_perl.so
#5  0xdeb9169d in S_doeval () from /opt/prod/apache/modules/mod_perl.so
#6  0xdeb9293f in Perl_pp_require () from 
/opt/prod/apache/modules/mod_perl.so
#7  0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69
#8  0xdeb6d61e in Perl_runops_standard ()
   from /opt/prod/apache/modules/mod_perl.so
#9  0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so
#10 0xdeb3113c in Perl_call_sv () from /opt/prod/apache/modules/mod_perl.so
#11 0xdeb14727 in modperl_callback (handler=0x8681fc0, p=0xcd12d10,
    r=0xcd12d48, s=0xc79c908, args=0xccf13ac) at modperl_callback.c:100
#12 0xdeb14dfc in modperl_callback_run_handlers (idx=0, type=5, r=0xcd12d48,
    c=0x0, s=0xc79c908, pconf=0x0, plog=0x0, ptemp=0x0,
    run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:261
#13 0xdeb1521e in modperl_callback_per_srv (idx=0, r=0xcd12d48,
    run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:376
#14 0xdeb2bd20 in modperl_post_read_request_handler (r=0xcd12d48)
    at modperl_hooks.c:67
#15 0x0807fd3e in ap_run_post_read_request (r=0xcd12d48) at protocol.c:1555
#16 0x0807eff3 in ap_read_request (conn=0xccf9948) at protocol.c:994
#17 0x0806c754 in ap_process_http_connection (c=0xccf9948) at 
http_core.c:242
#18 0x0807b4e6 in ap_run_process_connection (c=0xccf9948) at connection.c:42
#19 0x08071b55 in child_main (child_num_arg=0) at prefork.c:609
#20 0x08071d0a in make_child (s=0x80b9d80, slot=0) at prefork.c:649
#21 0x08071d63 in startup_children (number_to_start=8) at prefork.c:721
#22 0x08072479 in ap_mpm_run (_pconf=0x80b7fe0, plog=0x80e2088, s=0x80b9d80)
    at prefork.c:940
#23 0x0807758e in main (argc=6, argv=0x8047c54) at main.c:617



Re: Apache2::Reload Segmentation Fault

Posted by Stas Bekman <st...@stason.org>.
Vincent Moneymaker wrote:
> I am running Apache 2.0.52 on a solaris 8 box with mod_perl-2.0.0-RC5.  
> I previously had problems using Apache::Reload with mod_perl 1.99_19 
> version back in December and gave up trying to find a fix.  I thought I 
> would try again with the RC5 version but after having upgraded from 
> mod_perl 1.99_12 to RC5 I am getting segmentation fault errors when the 
> Apache2::Reload module is present in my httpd.conf file and a change is 
> then made in a module and the web page that is created via the changed 
> module is then called up.  I know that the segmentation fault is related 
> to the Apache2::Reload module because the segmentation fault errors 
> don't appear when the same change is made in the module (i.e. a simple 
> print statement) but without Apache2::Reload being present in the 
> httpd.conf file.

It's probably related to the similar segfaults I've been seeing and 
reported here [1]. But if you don't show the backtrace of the core file as 
explained at http://perl.apache.org/bugs/ we will never know.

I've CC'ed Philippe on this one, hoping that he will find the time to fix 
this problem.

[1] http://marc.theaimsgroup.com/?t=111145169900002&r=1&w=2

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com