You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@cpan.org> on 2003/05/06 05:09:24 UTC
Re: OBSD update
On Tue, 2003-05-06 at 10:22, Stas Bekman wrote:
> Hi Carl,
>
> > The OpenBSD people have been resounding in their insistance that
> > the only way to get perl 5.8.0 to work is to upgrade the OS
> > to OBSD 3.3. This is, of course, rubbish, but that's their response.
>
> That must be for a reason. I guess it requires a lot of manipulations which
> for some reason weren't contributed back to the main source. I suppose this is
> related to our failures to use a custom-built perl.
>
> > The OBSD culture is .. how do I put it ... strident?
>
> ;)
>
> > Your thoughts?
>
> Do we know anybody with other perl versions which are a part of OS? 5.6.1 or
> 5.8.0? (5.6.1 should be just fine).
>
> I'm CC'ing Philippe, since I'm not sure which version does he have. gozer,
> have you used the system's perl or a custom built one?
>
> What bugs me most is that I can't even have a working mp1-DSO, not talking
> about mp2. gozer, what's your situation with mp1-DSO on OpenBSD?
Well, you did just beat me to the punch ! I have been spending the last
few days battling the OpenBSD build and was preparing to send out my
SUCCESS story.
I've been able to run ./t/SMOKE on OpenBSD 3.3 (see attached test
results) with 100% success, both with a custom-built perl and the perl
that comes on that box
I did run into many issues, mostly understood by now, and here is a
short list of the gotchas:
1. On my machine, by default, the max file descriptors is set to 64, and
it's not sufficient, 128 did it.
2. By default, httpd(well, apr) will build with IPv6 support and
IPv4-mapped addresses disabled. So the generated httpd.conf et all, when
they say Listen 8530, you end up with a listening socket on ::1, IPv6
only. So, of course, all the tests explode with connection failed, etc.
Small patch to the configuration generation fixes this, as I couldn't
figure out a way to figure out if IPv4-mapping is enabled or not
reliably.
3. ranlib is not needed on this architecture, and explodes with the
strange warning: Inappropriate file type or format, so I fixed the
generated makefiles to skip it on OpenBSD
4. Can't make symbols global at DynaLoader warning. As pointed out in
the past, this is just a warning triggered by perl because we want
RTLD_GLOBAL, but OpenBSD doesn't implement it. Patched the 2 Const.pm to
work around it to avoid the warning as well
5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
machine. And the perl that ships with my OpenBSD will simply segfault in
a completely bogus way:
(gdb) bt
#0 0x400078cf in end ()
#1 0x40013060 in end ()
#2 0x400074a8 in end ()
#3 0x40007182 in end ()
#4 0x400085bd in end ()
The secret to fixing it for me so far, has been to make sure
/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
to figure out WHY have failed miserably.
With that, it all works fine for me.
> __________________________________________________________________
> 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
--
Philippe M. Chiasson <go...@cpan.org>
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> On Tue, 2003-05-06 at 15:00, Stas Bekman wrote:
>
>>Philippe M. Chiasson wrote:
>>
>>>On Tue, 2003-05-06 at 11:56, Stas Bekman wrote:
>>>
>>>
>>>>Philippe M. Chiasson wrote:
>>>>
>>>>
>>>>Great work, Philippe. Later when we work our the details please apply the
>>>>Apache::Test and mod_perl 2.0 patches separately as they now each have a
>>>>separate Changes file and separate lives on CPAN.
>>>>
>>>>
>>>>
>>>>>1. On my machine, by default, the max file descriptors is set to 64, and
>>>>>it's not sufficient, 128 did it.
>>>>
>>>>If this is crucial, we need to run a check and warn/croak if that's the case.
>>>
>>>
>>>That's relatively easy, sure can.
>>
>>but you can't deterministically say how much is enough. So we should at least
>>start with documenting this issue. Care to submit a patch for
>>src/docs/2.0/user/troubleshooting/troubleshooting.pod?
>
>
> Sure, and we could also try and gracefully detect that we just ran out
> of filehandles...
How are you going to do that? The code that was trying to open the file (and
failed) should have reported this when it hit the limit. Do you say that it
didn't?
>>>>>The secret to fixing it for me so far, has been to make sure
>>>>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
>>>>>to figure out WHY have failed miserably.
>>>>
>>>>yes, this is big pain, probably need to support that internally, or complain
>>>>aloud if there is a mismatch.
>>>
>>>
>>>Well, I've narrowed it down for me to /usr/X11R6/lib.
>>>
>>>LD_LIBRARY_PATH=/usr/local/lib works find
>>>LD_LIBRARY_PATH=/usr/local/lib:/usr/X11R6/lib explodes...
>>>
>>>Doesnt' make much sense, as adding a include dir to the path shouldn't
>>>change a thing... /me ponders...
>>
>>but that's on your system. On other machine it can be something different.
>
>
> I know, and to top it off, there is nothing in /usr/X11R6/lib that I can
> find Perl would load.
>
> I guess what I am trying to say is how can we figure out what's needed
> and what's not.
>
> In my case I _need_ /usr/local/lib, for other people, their requirements
> might be different, as you noted.
>
> What I am trying to figure out is _why_ certain directories would cause
> such strange segfaults.
For example DSO dependencies which happen to load different versions of the
same DSO (from different directories). Let's say liblang.so depends on
libfoo.so and libbar.so. Now libfoo.so depends on /tmp/1/libplus.so and
libbar.so depends on /tmp/2/libplus.so, which is a different build. Each
loading a different version of the same DSO and *boom*, *krush*, *bang*
Could this be the reason? I mean don't look for libperl.so in /usr/X11R6/lib
but for some other DSO which also resides in /usr/local/lib.
I'm reading Ulrich's papers on DSO design and he talks about those. Check his
homepage:
http://people.redhat.com/drepper/
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Tue, 2003-05-06 at 15:00, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > On Tue, 2003-05-06 at 11:56, Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>
> >>Great work, Philippe. Later when we work our the details please apply the
> >>Apache::Test and mod_perl 2.0 patches separately as they now each have a
> >>separate Changes file and separate lives on CPAN.
> >>
> >>
> >>>1. On my machine, by default, the max file descriptors is set to 64, and
> >>>it's not sufficient, 128 did it.
> >>
> >>If this is crucial, we need to run a check and warn/croak if that's the case.
> >
> >
> > That's relatively easy, sure can.
>
> but you can't deterministically say how much is enough. So we should at least
> start with documenting this issue. Care to submit a patch for
> src/docs/2.0/user/troubleshooting/troubleshooting.pod?
Sure, and we could also try and gracefully detect that we just ran out
of filehandles...
> >>>The secret to fixing it for me so far, has been to make sure
> >>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
> >>>to figure out WHY have failed miserably.
> >>
> >>yes, this is big pain, probably need to support that internally, or complain
> >>aloud if there is a mismatch.
> >
> >
> > Well, I've narrowed it down for me to /usr/X11R6/lib.
> >
> > LD_LIBRARY_PATH=/usr/local/lib works find
> > LD_LIBRARY_PATH=/usr/local/lib:/usr/X11R6/lib explodes...
> >
> > Doesnt' make much sense, as adding a include dir to the path shouldn't
> > change a thing... /me ponders...
>
> but that's on your system. On other machine it can be something different.
I know, and to top it off, there is nothing in /usr/X11R6/lib that I can
find Perl would load.
I guess what I am trying to say is how can we figure out what's needed
and what's not.
In my case I _need_ /usr/local/lib, for other people, their requirements
might be different, as you noted.
What I am trying to figure out is _why_ certain directories would cause
such strange segfaults.
>
> >>>>- $link .= "\n" . $ranlib unless DARWIN;
> >>>>+ $link .= "\n" . $ranlib unless (DARWIN or OPENBSD);
> >>>>
> >>>> $link;
> >>>>}
> >>>
> >>or $(MODPERL_RANLIB) constant should be set to ':'. I don't understand why the
> >>special case for DARWIN/OPENBSD, but linux doesn't really use it, and the
> >>solution is different?
> >
> >
> > Well, DARWIN was already there, and I just slapped OpenBSD to it.
>
> +1
>
> >>>>- my $port = $tree->lookup('Listen');
> >>>>+ my $listen = $tree->lookup('Listen');
> >>>>
> >>>>- ok t_cmp($vars->{port}, $port);
> >>>>+ ok t_cmp('0.0.0.0:'.$vars->{port}, $listen);
> >>>>
> >>>> my $documentroot = $tree->lookup('DocumentRoot');
> >>>
> >>shouldn't this be coded as a variable in Apache/TestConfig? I mean:
> >>
> >>$vars->{ip_address} or something like that?
> >
> >
> > Yeah, probably should.
> >
> >
> >>Also do we have the same problem with mp1?
> >
> >
> > Don't think so, as apache-1/mp1 wouldn't be using IPv6 by default,
> > wouldn't it ? (I'll verify that later on)
>
> This is quite possible in the later releases, but this is unrelated to
> Apache::Test since it will do the same thing for mp1 and mp2 (with your
> patch). just add a new variable so it'll be encapsulated rather than hardcoded.
>
> I was talking about the mp1 test suite, but I have heard of no complaints so
> far. So let's just leave it...
>
Fine, will add something like $vars->{ip_address} then...
>
> __________________________________________________________________
> 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
--
Philippe M. Chiasson <go...@cpan.org>
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> BTW, I've just done building/testing (with my OpenBSD patches)
>
> config_args='-des -Dprefix=/home/gozer/opt/perl/OpenBSD-i386/5.6.1
> -Doptimize='-g' -Dusedevel -Dusethreads -Uuseshrplib'
>
> With httpd-dev perfork/worker
>
> and I get most test passing. ( a few failures, but I am missing LWP and
> all, so I expected that )
Great!
> So, sounds that there is _extra_ trouble for OpenBSD 2.9
>
> I'll wait to get the access to that box and I'll what I can dig up
> later.
cool
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
BTW, I've just done building/testing (with my OpenBSD patches)
config_args='-des -Dprefix=/home/gozer/opt/perl/OpenBSD-i386/5.6.1
-Doptimize='-g' -Dusedevel -Dusethreads -Uuseshrplib'
With httpd-dev perfork/worker
and I get most test passing. ( a few failures, but I am missing LWP and
all, so I expected that )
So, sounds that there is _extra_ trouble for OpenBSD 2.9
I'll wait to get the access to that box and I'll what I can dig up
later.
On Tue, 2003-05-06 at 15:00, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > On Tue, 2003-05-06 at 11:56, Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>
> >>Great work, Philippe. Later when we work our the details please apply the
> >>Apache::Test and mod_perl 2.0 patches separately as they now each have a
> >>separate Changes file and separate lives on CPAN.
> >>
> >>
> >>>1. On my machine, by default, the max file descriptors is set to 64, and
> >>>it's not sufficient, 128 did it.
> >>
> >>If this is crucial, we need to run a check and warn/croak if that's the case.
> >
> >
> > That's relatively easy, sure can.
>
> but you can't deterministically say how much is enough. So we should at least
> start with documenting this issue. Care to submit a patch for
> src/docs/2.0/user/troubleshooting/troubleshooting.pod?
>
> >>>The secret to fixing it for me so far, has been to make sure
> >>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
> >>>to figure out WHY have failed miserably.
> >>
> >>yes, this is big pain, probably need to support that internally, or complain
> >>aloud if there is a mismatch.
> >
> >
> > Well, I've narrowed it down for me to /usr/X11R6/lib.
> >
> > LD_LIBRARY_PATH=/usr/local/lib works find
> > LD_LIBRARY_PATH=/usr/local/lib:/usr/X11R6/lib explodes...
> >
> > Doesnt' make much sense, as adding a include dir to the path shouldn't
> > change a thing... /me ponders...
>
> but that's on your system. On other machine it can be something different.
>
> >>>>- $link .= "\n" . $ranlib unless DARWIN;
> >>>>+ $link .= "\n" . $ranlib unless (DARWIN or OPENBSD);
> >>>>
> >>>> $link;
> >>>>}
> >>>
> >>or $(MODPERL_RANLIB) constant should be set to ':'. I don't understand why the
> >>special case for DARWIN/OPENBSD, but linux doesn't really use it, and the
> >>solution is different?
> >
> >
> > Well, DARWIN was already there, and I just slapped OpenBSD to it.
>
> +1
>
> >>>>- my $port = $tree->lookup('Listen');
> >>>>+ my $listen = $tree->lookup('Listen');
> >>>>
> >>>>- ok t_cmp($vars->{port}, $port);
> >>>>+ ok t_cmp('0.0.0.0:'.$vars->{port}, $listen);
> >>>>
> >>>> my $documentroot = $tree->lookup('DocumentRoot');
> >>>
> >>shouldn't this be coded as a variable in Apache/TestConfig? I mean:
> >>
> >>$vars->{ip_address} or something like that?
> >
> >
> > Yeah, probably should.
> >
> >
> >>Also do we have the same problem with mp1?
> >
> >
> > Don't think so, as apache-1/mp1 wouldn't be using IPv6 by default,
> > wouldn't it ? (I'll verify that later on)
>
> This is quite possible in the later releases, but this is unrelated to
> Apache::Test since it will do the same thing for mp1 and mp2 (with your
> patch). just add a new variable so it'll be encapsulated rather than hardcoded.
>
> I was talking about the mp1 test suite, but I have heard of no complaints so
> far. So let's just leave it...
>
>
>
> __________________________________________________________________
> 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
--
Philippe M. Chiasson <go...@cpan.org>
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> On Tue, 2003-05-06 at 11:56, Stas Bekman wrote:
>
>>Philippe M. Chiasson wrote:
>>
>>
>>Great work, Philippe. Later when we work our the details please apply the
>>Apache::Test and mod_perl 2.0 patches separately as they now each have a
>>separate Changes file and separate lives on CPAN.
>>
>>
>>>1. On my machine, by default, the max file descriptors is set to 64, and
>>>it's not sufficient, 128 did it.
>>
>>If this is crucial, we need to run a check and warn/croak if that's the case.
>
>
> That's relatively easy, sure can.
but you can't deterministically say how much is enough. So we should at least
start with documenting this issue. Care to submit a patch for
src/docs/2.0/user/troubleshooting/troubleshooting.pod?
>>>The secret to fixing it for me so far, has been to make sure
>>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
>>>to figure out WHY have failed miserably.
>>
>>yes, this is big pain, probably need to support that internally, or complain
>>aloud if there is a mismatch.
>
>
> Well, I've narrowed it down for me to /usr/X11R6/lib.
>
> LD_LIBRARY_PATH=/usr/local/lib works find
> LD_LIBRARY_PATH=/usr/local/lib:/usr/X11R6/lib explodes...
>
> Doesnt' make much sense, as adding a include dir to the path shouldn't
> change a thing... /me ponders...
but that's on your system. On other machine it can be something different.
>>>>- $link .= "\n" . $ranlib unless DARWIN;
>>>>+ $link .= "\n" . $ranlib unless (DARWIN or OPENBSD);
>>>>
>>>> $link;
>>>>}
>>>
>>or $(MODPERL_RANLIB) constant should be set to ':'. I don't understand why the
>>special case for DARWIN/OPENBSD, but linux doesn't really use it, and the
>>solution is different?
>
>
> Well, DARWIN was already there, and I just slapped OpenBSD to it.
+1
>>>>- my $port = $tree->lookup('Listen');
>>>>+ my $listen = $tree->lookup('Listen');
>>>>
>>>>- ok t_cmp($vars->{port}, $port);
>>>>+ ok t_cmp('0.0.0.0:'.$vars->{port}, $listen);
>>>>
>>>> my $documentroot = $tree->lookup('DocumentRoot');
>>>
>>shouldn't this be coded as a variable in Apache/TestConfig? I mean:
>>
>>$vars->{ip_address} or something like that?
>
>
> Yeah, probably should.
>
>
>>Also do we have the same problem with mp1?
>
>
> Don't think so, as apache-1/mp1 wouldn't be using IPv6 by default,
> wouldn't it ? (I'll verify that later on)
This is quite possible in the later releases, but this is unrelated to
Apache::Test since it will do the same thing for mp1 and mp2 (with your
patch). just add a new variable so it'll be encapsulated rather than hardcoded.
I was talking about the mp1 test suite, but I have heard of no complaints so
far. So let's just leave it...
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Tue, 2003-05-06 at 11:56, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>
> Great work, Philippe. Later when we work our the details please apply the
> Apache::Test and mod_perl 2.0 patches separately as they now each have a
> separate Changes file and separate lives on CPAN.
>
> > 1. On my machine, by default, the max file descriptors is set to 64, and
> > it's not sufficient, 128 did it.
>
> If this is crucial, we need to run a check and warn/croak if that's the case.
That's relatively easy, sure can.
> > 2. By default, httpd(well, apr) will build with IPv6 support and
> > IPv4-mapped addresses disabled. So the generated httpd.conf et all, when
> > they say Listen 8530, you end up with a listening socket on ::1, IPv6
> > only. So, of course, all the tests explode with connection failed, etc.
> > Small patch to the configuration generation fixes this, as I couldn't
> > figure out a way to figure out if IPv4-mapping is enabled or not
> > reliably.
>
> OK
>
> > 3. ranlib is not needed on this architecture, and explodes with the
> > strange warning: Inappropriate file type or format, so I fixed the
> > generated makefiles to skip it on OpenBSD
>
> Yes, it shouldn't have been set. Look at the Linux implementation, it's set to
> ':' in Makefile, rather than skipped.
Sure, but for the love of god, what sets it to ':'. Couldn't find it
after a quick grep session...
> > 4. Can't make symbols global at DynaLoader warning. As pointed out in
> > the past, this is just a warning triggered by perl because we want
> > RTLD_GLOBAL, but OpenBSD doesn't implement it. Patched the 2 Const.pm to
> > work around it to avoid the warning as well
>
> +1, but probably
>
> > 5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
> > yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
> > machine. And the perl that ships with my OpenBSD will simply segfault in
> > a completely bogus way:
> >
> > (gdb) bt
> > #0 0x400078cf in end ()
> > #1 0x40013060 in end ()
> > #2 0x400074a8 in end ()
> > #3 0x40007182 in end ()
> > #4 0x400085bd in end ()
> >
> > The secret to fixing it for me so far, has been to make sure
> > /usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
> > to figure out WHY have failed miserably.
>
> yes, this is big pain, probably need to support that internally, or complain
> aloud if there is a mismatch.
Well, I've narrowed it down for me to /usr/X11R6/lib.
LD_LIBRARY_PATH=/usr/local/lib works find
LD_LIBRARY_PATH=/usr/local/lib:/usr/X11R6/lib explodes...
Doesnt' make much sense, as adding a include dir to the path shouldn't
change a thing... /me ponders...
> RE: patch:
>
> Please add Changes and Apache-Test/Changes patches... and please commit each
> change separately.
Oups, forgot about that. Will do.
> >>Index: lib/Apache/Build.pm
> >>===================================================================
> >>RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
> >>retrieving revision 1.121
> >>diff -b -B -u -r1.121 Build.pm
> >>--- lib/Apache/Build.pm 22 Apr 2003 08:32:59 -0000 1.121
> >>+++ lib/Apache/Build.pm 6 May 2003 03:03:48 -0000
> >>@@ -25,6 +25,7 @@
> >> use constant AIX => $^O eq 'aix';
> >> use constant DARWIN => $^O eq 'darwin';
> >> use constant HPUX => $^O eq 'hpux';
> >>+use constant OPENBSD => $^O eq 'openbsd';
> >> use constant WIN32 => $^O eq 'MSWin32';
> >>
> >> use constant MSVC => WIN32() && ($Config{cc} eq 'cl');
> >>@@ -1050,7 +1051,7 @@
> >>
> >> my $ranlib = "\t" . '$(MODPERL_RANLIB) $@';
> >>
> >>- $link .= "\n" . $ranlib unless DARWIN;
> >>+ $link .= "\n" . $ranlib unless (DARWIN or OPENBSD);
> >>
> >> $link;
> >> }
>
> or $(MODPERL_RANLIB) constant should be set to ':'. I don't understand why the
> special case for DARWIN/OPENBSD, but linux doesn't really use it, and the
> solution is different?
Well, DARWIN was already there, and I just slapped OpenBSD to it.
Just find out where the MODPERL_RANLIB => ':' comes from and I'll change
it.
> >>Index: t/response/TestApache/conftree.pm
> >>===================================================================
> >>RCS file: /home/cvs/modperl-2.0/t/response/TestApache/conftree.pm,v
> >>retrieving revision 1.5
> >>diff -b -B -u -r1.5 conftree.pm
> >>--- t/response/TestApache/conftree.pm 29 Jan 2003 03:56:00 -0000 1.5
> >>+++ t/response/TestApache/conftree.pm 6 May 2003 03:03:55 -0000
> >>@@ -27,9 +27,9 @@
> >>
> >> ok $tree;
> >>
> >>- my $port = $tree->lookup('Listen');
> >>+ my $listen = $tree->lookup('Listen');
> >>
> >>- ok t_cmp($vars->{port}, $port);
> >>+ ok t_cmp('0.0.0.0:'.$vars->{port}, $listen);
> >>
> >> my $documentroot = $tree->lookup('DocumentRoot');
>
> shouldn't this be coded as a variable in Apache/TestConfig? I mean:
>
> $vars->{ip_address} or something like that?
Yeah, probably should.
> Also do we have the same problem with mp1?
Don't think so, as apache-1/mp1 wouldn't be using IPv6 by default,
wouldn't it ? (I'll verify that later on)
> __________________________________________________________________
> 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
--
Philippe M. Chiasson <go...@cpan.org>
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
Great work, Philippe. Later when we work our the details please apply the
Apache::Test and mod_perl 2.0 patches separately as they now each have a
separate Changes file and separate lives on CPAN.
> 1. On my machine, by default, the max file descriptors is set to 64, and
> it's not sufficient, 128 did it.
If this is crucial, we need to run a check and warn/croak if that's the case.
> 2. By default, httpd(well, apr) will build with IPv6 support and
> IPv4-mapped addresses disabled. So the generated httpd.conf et all, when
> they say Listen 8530, you end up with a listening socket on ::1, IPv6
> only. So, of course, all the tests explode with connection failed, etc.
> Small patch to the configuration generation fixes this, as I couldn't
> figure out a way to figure out if IPv4-mapping is enabled or not
> reliably.
OK
> 3. ranlib is not needed on this architecture, and explodes with the
> strange warning: Inappropriate file type or format, so I fixed the
> generated makefiles to skip it on OpenBSD
Yes, it shouldn't have been set. Look at the Linux implementation, it's set to
':' in Makefile, rather than skipped.
> 4. Can't make symbols global at DynaLoader warning. As pointed out in
> the past, this is just a warning triggered by perl because we want
> RTLD_GLOBAL, but OpenBSD doesn't implement it. Patched the 2 Const.pm to
> work around it to avoid the warning as well
+1, but probably
> 5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
> yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
> machine. And the perl that ships with my OpenBSD will simply segfault in
> a completely bogus way:
>
> (gdb) bt
> #0 0x400078cf in end ()
> #1 0x40013060 in end ()
> #2 0x400074a8 in end ()
> #3 0x40007182 in end ()
> #4 0x400085bd in end ()
>
> The secret to fixing it for me so far, has been to make sure
> /usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
> to figure out WHY have failed miserably.
yes, this is big pain, probably need to support that internally, or complain
aloud if there is a mismatch.
RE: patch:
Please add Changes and Apache-Test/Changes patches... and please commit each
change separately.
>>Index: lib/Apache/Build.pm
>>===================================================================
>>RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
>>retrieving revision 1.121
>>diff -b -B -u -r1.121 Build.pm
>>--- lib/Apache/Build.pm 22 Apr 2003 08:32:59 -0000 1.121
>>+++ lib/Apache/Build.pm 6 May 2003 03:03:48 -0000
>>@@ -25,6 +25,7 @@
>> use constant AIX => $^O eq 'aix';
>> use constant DARWIN => $^O eq 'darwin';
>> use constant HPUX => $^O eq 'hpux';
>>+use constant OPENBSD => $^O eq 'openbsd';
>> use constant WIN32 => $^O eq 'MSWin32';
>>
>> use constant MSVC => WIN32() && ($Config{cc} eq 'cl');
>>@@ -1050,7 +1051,7 @@
>>
>> my $ranlib = "\t" . '$(MODPERL_RANLIB) $@';
>>
>>- $link .= "\n" . $ranlib unless DARWIN;
>>+ $link .= "\n" . $ranlib unless (DARWIN or OPENBSD);
>>
>> $link;
>> }
or $(MODPERL_RANLIB) constant should be set to ':'. I don't understand why the
special case for DARWIN/OPENBSD, but linux doesn't really use it, and the
solution is different?
>>Index: t/response/TestApache/conftree.pm
>>===================================================================
>>RCS file: /home/cvs/modperl-2.0/t/response/TestApache/conftree.pm,v
>>retrieving revision 1.5
>>diff -b -B -u -r1.5 conftree.pm
>>--- t/response/TestApache/conftree.pm 29 Jan 2003 03:56:00 -0000 1.5
>>+++ t/response/TestApache/conftree.pm 6 May 2003 03:03:55 -0000
>>@@ -27,9 +27,9 @@
>>
>> ok $tree;
>>
>>- my $port = $tree->lookup('Listen');
>>+ my $listen = $tree->lookup('Listen');
>>
>>- ok t_cmp($vars->{port}, $port);
>>+ ok t_cmp('0.0.0.0:'.$vars->{port}, $listen);
>>
>> my $documentroot = $tree->lookup('DocumentRoot');
shouldn't this be coded as a variable in Apache/TestConfig? I mean:
$vars->{ip_address} or something like that?
Also do we have the same problem with mp1?
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
>>Yup, I have 64. Do you have to reboot after changing this setting? (It's not
>>my machine, It's Carl who let's me mess with it).
>
>
>
> Once changed, just logout/login and it is there.
>
> you can check that it worked with
>
> $> ulimit -n
> 128
Yup, I've found the manpage ;)
I've tried:
% ulimit -n 256
but in vain. I've tried raising other limits, but no change.
>>>>>5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
>>>>>yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
>>>>>machine. And the perl that ships with my OpenBSD will simply segfault in
>>>>>a completely bogus way:
>>>>>
>>>>>(gdb) bt
>>>>>#0 0x400078cf in end ()
>>>>>#1 0x40013060 in end ()
>>>>>#2 0x400074a8 in end ()
>>>>>#3 0x40007182 in end ()
>>>>>#4 0x400085bd in end ()
>>>>>
>>>>>The secret to fixing it for me so far, has been to make sure
>>>>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
>>>>>to figure out WHY have failed miserably.
>>>>
>>>>You have to specify it explicitly when you invoke your mod_perl. We probably
>>>>should supply a support for this from within Apache::Test.
>>>
>>>
>>>Well, I was also planning on doing some more digging on the strange
>>>segfaults I've been seeing with /usr/X11R6/lib, but it's very strange,
>>>IMO.
>>
>>IMHO, overriding LD_LIBRARY_PATH is probably the simplest. At least for the
>>tests.
>
>
> Well, more or less. For example, on my setup, you need to keep
> /usr/local/lib and 'know' to remove /usr/X11R6/bin ...
>
>
>>What I don't understand why the perl executable picks wrong libraries - they
>>don't even much on the version numbers. Without LD_LIBRARY_PATH it complains:
>>
>>/usr/libexec/ld.so: warning: libperl.so.6.0: minor version >= 1 expected,
>>using it anyway
>>
>>why "using anyway"....
>
>
> You can try setting
> LD_TRACE_LOADED_OBJECTS=1
>
> to get a more detailled of what ld loaded ...
and LD_DEBUG=1 ;)
The thing is, it has no clue about the
/data/stas/perl/5.6.1/lib/5.6.1/OpenBSD.i386-openbsd/CORE/ path, I though the
perl executable should at least try that one first unless overriden with an
explicit LD_LIBRARY_PATH, but apparently it totaly ignores it.
>>It also looks like it doesn't like LD_PRELOAD:
>>
>>cd perl-5.6.1
>>LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make test
>>/usr/libexec/ld.so: preload: /data/stas/perl.org/perl-5.6.1/libperl.so: cannot
>>map object
>>
>
>
> On a funnier note, I've found where RANLIB comes from
>
> linux #> perl -V:ranlib
> ':'
> openbsd $> perl -V:ranlib
> 'ranlib'
>
> So we are getting it from Config.pm, but annoyingly enough, it says to
> use ranlib even though we don't want to.
>
> So, after all, maybe the DARWIN hack is for the same reason...
In that case, go with it.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Tue, 2003-05-06 at 14:19, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > On Tue, 2003-05-06 at 11:45, Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>
> >>>Well, you did just beat me to the punch ! I have been spending the last
> >>>few days battling the OpenBSD build and was preparing to send out my
> >>>SUCCESS story.
> >>
> >>Great work, Philippe. I'll comment on the patch in a separate email.
> >
> >
> > Too bad you beat me to the punch ;-p
>
> ;)
>
> >>Unfortunately OpenBSD 2.9 still doesn't work with your patch. Here is the
> >>segfault and how to reproduce it:
> >>
> >>LD_LIBRARY_PATH=/data/stas/perl/5.6.1/lib/5.6.1/OpenBSD.i386-openbsd/CORE:$LD_LIBRARY_PATH
> >>gdb
> >
> >
> > You have to set LD_LIBRARY_PATH for perl ? (let me guess, otherwise it
> > picks up the libperl.so from somewhere else)
>
> Yup, it picks /usr/lib/perl's one.
> >>Did you have the same segfault before you managed to make it work?
> >
> >
> > Nope, as I showed you, I got this 100% bogus stack trace full of end()s
> > ;-( But I can try on my end. This was perl 5.6.1, anything special about
> > it? ithreads, etc ? I'll give it a shot and see if I can reproduce that.
>
> No ithreads, on OpenBSD-2.9 both 5.8.0 and 5.6.1 fail to compile if you supply
> -Dusethreads
>
> I've used:
>
> make distclean
> ./Configure -des -Dprefix=/data/stas/perl/5.6.1 \
> -Dopenbsd_distribution=false -Doptimize='-g' -Duseshrplib -Dusedevel
> make -j2
> LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make test
> LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make install
>
> > How come it looks like your perl (or libperl.so) doesn't have debugging
> > symbols...
>
> I was just trying to check if the debug flags could be a reason for a fault,
> but no. Here is one with debug symbols enabled:
>
> #0 0x4036971b in S_new_xpvhv () at sv.c:655
> #1 0x4036a2a1 in Perl_sv_upgrade (sv=0x7fe454, mt=11) at sv.c:1102
> #2 0x40357ba1 in Perl_newHV () at hv.c:1006
> #3 0x402e9524 in perl_construct (my_perl=0x39f030) at perl.c:284
> #4 0x402bf4e4 in modperl_startup (s=0x1cdd28, p=0x183018) at mod_perl.c:166
> #5 0x402c07dc in modperl_init (base_server=0x1cdd28, p=0x183018) at
> mod_perl.c:353
> #6 0x402c0998 in modperl_hook_init (pconf=0x183018, plog=0x0, ptemp=0x0,
> s=0x1cdd28)
> at mod_perl.c:486
> #7 0x402c09d4 in modperl_run () at mod_perl.c:497
> #8 0x402c5032 in modperl_cmd_load_module (parms=0xdfbfda5c, mconfig=0x1d63c8,
> arg=0x1e34e8 "TestDirective::perlloadmodule3") at modperl_cmd.c:499
> #9 0x7d7b2 in L413 () at config.c:713
> #10 0x7e4c1 in ap_walk_config_sub (current=0x1e34c8, parms=0xdfbfda5c,
> section_vector=0x1cfbd8) at config.c:1082
> #11 0x7e545 in ap_walk_config (current=0x1d6688, parms=0xdfbfda5c,
> section_vector=0x1cfbd8)
> at config.c:1121
> #12 0x7f2d4 in ap_process_config_tree (s=0x1cdd28, conftree=0x1d6688, p=0x183018,
> ptemp=0x187018) at config.c:1594
> #13 0x83066 in L67 () at main.c:638
>
I am building perl 5.6.1 on my OpenBSD box as we speak, more on that one
later
> >>>1. On my machine, by default, the max file descriptors is set to 64, and
> >>>it's not sufficient, 128 did it.
> >>
> >>how do I change it on OpenBSD? that's the only thing that I haven't tried yet.
> >
> >
> > Look at /etc/login.conf
> >
> > Mine looks like this:
> > default:\
> > :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bi /usr/local/bin:\
> > :umask=022:\
> > :datasize-max=256M:\
> > :datasize-cur=64M:\
> > :maxproc-max=128:\
> > :maxproc-cur=64:\
> > :openfiles-cur=128:\
> > :stacksize-cur=4M:\
> > :localcipher=blowfish,6:\
> > :ypcipher=old:\
> > :tc=auth-defaults:\
> > :tc=auth-ftp-defaults:
> >
> > The one you are looking for is openfiles-cur
>
> Yup, I have 64. Do you have to reboot after changing this setting? (It's not
> my machine, It's Carl who let's me mess with it).
Once changed, just logout/login and it is there.
you can check that it worked with
$> ulimit -n
128
> >>>5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
> >>>yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
> >>>machine. And the perl that ships with my OpenBSD will simply segfault in
> >>>a completely bogus way:
> >>>
> >>>(gdb) bt
> >>>#0 0x400078cf in end ()
> >>>#1 0x40013060 in end ()
> >>>#2 0x400074a8 in end ()
> >>>#3 0x40007182 in end ()
> >>>#4 0x400085bd in end ()
> >>>
> >>>The secret to fixing it for me so far, has been to make sure
> >>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
> >>>to figure out WHY have failed miserably.
> >>
> >>You have to specify it explicitly when you invoke your mod_perl. We probably
> >>should supply a support for this from within Apache::Test.
> >
> >
> > Well, I was also planning on doing some more digging on the strange
> > segfaults I've been seeing with /usr/X11R6/lib, but it's very strange,
> > IMO.
>
> IMHO, overriding LD_LIBRARY_PATH is probably the simplest. At least for the
> tests.
Well, more or less. For example, on my setup, you need to keep
/usr/local/lib and 'know' to remove /usr/X11R6/bin ...
> What I don't understand why the perl executable picks wrong libraries - they
> don't even much on the version numbers. Without LD_LIBRARY_PATH it complains:
>
> /usr/libexec/ld.so: warning: libperl.so.6.0: minor version >= 1 expected,
> using it anyway
>
> why "using anyway"....
You can try setting
LD_TRACE_LOADED_OBJECTS=1
to get a more detailled of what ld loaded ...
>
> It also looks like it doesn't like LD_PRELOAD:
>
> cd perl-5.6.1
> LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make test
> /usr/libexec/ld.so: preload: /data/stas/perl.org/perl-5.6.1/libperl.so: cannot
> map object
>
On a funnier note, I've found where RANLIB comes from
linux #> perl -V:ranlib
':'
openbsd $> perl -V:ranlib
'ranlib'
So we are getting it from Config.pm, but annoyingly enough, it says to
use ranlib even though we don't want to.
So, after all, maybe the DARWIN hack is for the same reason...
> __________________________________________________________________
> 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
--
Philippe M. Chiasson <go...@cpan.org>
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> On Tue, 2003-05-06 at 11:45, Stas Bekman wrote:
>
>>Philippe M. Chiasson wrote:
>>
>>
>>>Well, you did just beat me to the punch ! I have been spending the last
>>>few days battling the OpenBSD build and was preparing to send out my
>>>SUCCESS story.
>>
>>Great work, Philippe. I'll comment on the patch in a separate email.
>
>
> Too bad you beat me to the punch ;-p
;)
>>Unfortunately OpenBSD 2.9 still doesn't work with your patch. Here is the
>>segfault and how to reproduce it:
>>
>>LD_LIBRARY_PATH=/data/stas/perl/5.6.1/lib/5.6.1/OpenBSD.i386-openbsd/CORE:$LD_LIBRARY_PATH
>>gdb
>
>
> You have to set LD_LIBRARY_PATH for perl ? (let me guess, otherwise it
> picks up the libperl.so from somewhere else)
Yup, it picks /usr/lib/perl's one.
>>Did you have the same segfault before you managed to make it work?
>
>
> Nope, as I showed you, I got this 100% bogus stack trace full of end()s
> ;-( But I can try on my end. This was perl 5.6.1, anything special about
> it? ithreads, etc ? I'll give it a shot and see if I can reproduce that.
No ithreads, on OpenBSD-2.9 both 5.8.0 and 5.6.1 fail to compile if you supply
-Dusethreads
I've used:
make distclean
./Configure -des -Dprefix=/data/stas/perl/5.6.1 \
-Dopenbsd_distribution=false -Doptimize='-g' -Duseshrplib -Dusedevel
make -j2
LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make test
LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make install
> How come it looks like your perl (or libperl.so) doesn't have debugging
> symbols...
I was just trying to check if the debug flags could be a reason for a fault,
but no. Here is one with debug symbols enabled:
#0 0x4036971b in S_new_xpvhv () at sv.c:655
#1 0x4036a2a1 in Perl_sv_upgrade (sv=0x7fe454, mt=11) at sv.c:1102
#2 0x40357ba1 in Perl_newHV () at hv.c:1006
#3 0x402e9524 in perl_construct (my_perl=0x39f030) at perl.c:284
#4 0x402bf4e4 in modperl_startup (s=0x1cdd28, p=0x183018) at mod_perl.c:166
#5 0x402c07dc in modperl_init (base_server=0x1cdd28, p=0x183018) at
mod_perl.c:353
#6 0x402c0998 in modperl_hook_init (pconf=0x183018, plog=0x0, ptemp=0x0,
s=0x1cdd28)
at mod_perl.c:486
#7 0x402c09d4 in modperl_run () at mod_perl.c:497
#8 0x402c5032 in modperl_cmd_load_module (parms=0xdfbfda5c, mconfig=0x1d63c8,
arg=0x1e34e8 "TestDirective::perlloadmodule3") at modperl_cmd.c:499
#9 0x7d7b2 in L413 () at config.c:713
#10 0x7e4c1 in ap_walk_config_sub (current=0x1e34c8, parms=0xdfbfda5c,
section_vector=0x1cfbd8) at config.c:1082
#11 0x7e545 in ap_walk_config (current=0x1d6688, parms=0xdfbfda5c,
section_vector=0x1cfbd8)
at config.c:1121
#12 0x7f2d4 in ap_process_config_tree (s=0x1cdd28, conftree=0x1d6688, p=0x183018,
ptemp=0x187018) at config.c:1594
#13 0x83066 in L67 () at main.c:638
>>>1. On my machine, by default, the max file descriptors is set to 64, and
>>>it's not sufficient, 128 did it.
>>
>>how do I change it on OpenBSD? that's the only thing that I haven't tried yet.
>
>
> Look at /etc/login.conf
>
> Mine looks like this:
> default:\
> :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bi /usr/local/bin:\
> :umask=022:\
> :datasize-max=256M:\
> :datasize-cur=64M:\
> :maxproc-max=128:\
> :maxproc-cur=64:\
> :openfiles-cur=128:\
> :stacksize-cur=4M:\
> :localcipher=blowfish,6:\
> :ypcipher=old:\
> :tc=auth-defaults:\
> :tc=auth-ftp-defaults:
>
> The one you are looking for is openfiles-cur
Yup, I have 64. Do you have to reboot after changing this setting? (It's not
my machine, It's Carl who let's me mess with it).
>>>5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
>>>yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
>>>machine. And the perl that ships with my OpenBSD will simply segfault in
>>>a completely bogus way:
>>>
>>>(gdb) bt
>>>#0 0x400078cf in end ()
>>>#1 0x40013060 in end ()
>>>#2 0x400074a8 in end ()
>>>#3 0x40007182 in end ()
>>>#4 0x400085bd in end ()
>>>
>>>The secret to fixing it for me so far, has been to make sure
>>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
>>>to figure out WHY have failed miserably.
>>
>>You have to specify it explicitly when you invoke your mod_perl. We probably
>>should supply a support for this from within Apache::Test.
>
>
> Well, I was also planning on doing some more digging on the strange
> segfaults I've been seeing with /usr/X11R6/lib, but it's very strange,
> IMO.
IMHO, overriding LD_LIBRARY_PATH is probably the simplest. At least for the
tests.
What I don't understand why the perl executable picks wrong libraries - they
don't even much on the version numbers. Without LD_LIBRARY_PATH it complains:
/usr/libexec/ld.so: warning: libperl.so.6.0: minor version >= 1 expected,
using it anyway
why "using anyway"....
It also looks like it doesn't like LD_PRELOAD:
cd perl-5.6.1
LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make test
/usr/libexec/ld.so: preload: /data/stas/perl.org/perl-5.6.1/libperl.so: cannot
map object
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Tue, 2003-05-06 at 11:45, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
> > Well, you did just beat me to the punch ! I have been spending the last
> > few days battling the OpenBSD build and was preparing to send out my
> > SUCCESS story.
>
> Great work, Philippe. I'll comment on the patch in a separate email.
Too bad you beat me to the punch ;-p
> Unfortunately OpenBSD 2.9 still doesn't work with your patch. Here is the
> segfault and how to reproduce it:
>
> LD_LIBRARY_PATH=/data/stas/perl/5.6.1/lib/5.6.1/OpenBSD.i386-openbsd/CORE:$LD_LIBRARY_PATH
> gdb
You have to set LD_LIBRARY_PATH for perl ? (let me guess, otherwise it
picks up the libperl.so from somewhere else)
> file /data/stas/httpd/prefork/bin/httpd
> handle SIGPIPE nostop
> handle SIGPIPE pass
> set auto-solib-add 0
> run -d `pwd`/t -f `pwd`/t/conf/httpd.conf -DONE_PROCESS -DNO_DETATCH -DAPACHE2
> sharedlib libperl.so
> sharedlib mod_perl.so
> where
>
> #0 0x40340296 in Perl_report_uninit ()
> #1 0x40340aa5 in Perl_sv_upgrade ()
> #2 0x4033549b in Perl_newHV ()
> #3 0x402e929a in perl_construct ()
> #4 0x402bf4e4 in modperl_startup (s=0x1cdd28, p=0x183018) at mod_perl.c:166
> #5 0x402c07dc in modperl_init (base_server=0x1cdd28, p=0x183018) at
> mod_perl.c:353
> #6 0x402c0998 in modperl_hook_init (pconf=0x183018, plog=0x0, ptemp=0x0,
> s=0x1cdd28)
> at mod_perl.c:486
> #7 0x402c09d4 in modperl_run () at mod_perl.c:497
> #8 0x402c5032 in modperl_cmd_load_module (parms=0xdfbfda5c, mconfig=0x1d63c8,
> arg=0x1e34e8 "TestDirective::perlloadmodule3") at modperl_cmd.c:499
> #9 0x7d7b2 in L413 () at config.c:713
> #10 0x7e4c1 in ap_walk_config_sub (current=0x1e34c8, parms=0xdfbfda5c,
> section_vector=0x1cfbd8) at config.c:1082
> #11 0x7e545 in ap_walk_config (current=0x1d6688, parms=0xdfbfda5c,
> section_vector=0x1cfbd8)
> at config.c:1121
> #12 0x7f2d4 in ap_process_config_tree (s=0x1cdd28, conftree=0x1d6688, p=0x183018,
> ptemp=0x187018) at config.c:1594
> #13 0x83066 in L67 () at main.c:638
>
> Did you have the same segfault before you managed to make it work?
Nope, as I showed you, I got this 100% bogus stack trace full of end()s
;-( But I can try on my end. This was perl 5.6.1, anything special about
it? ithreads, etc ? I'll give it a shot and see if I can reproduce that.
How come it looks like your perl (or libperl.so) doesn't have debugging
symbols...
> > 1. On my machine, by default, the max file descriptors is set to 64, and
> > it's not sufficient, 128 did it.
>
> how do I change it on OpenBSD? that's the only thing that I haven't tried yet.
Look at /etc/login.conf
Mine looks like this:
default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bi /usr/local/bin:\
:umask=022:\
:datasize-max=256M:\
:datasize-cur=64M:\
:maxproc-max=128:\
:maxproc-cur=64:\
:openfiles-cur=128:\
:stacksize-cur=4M:\
:localcipher=blowfish,6:\
:ypcipher=old:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:
The one you are looking for is openfiles-cur
> > 5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
> > yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
> > machine. And the perl that ships with my OpenBSD will simply segfault in
> > a completely bogus way:
> >
> > (gdb) bt
> > #0 0x400078cf in end ()
> > #1 0x40013060 in end ()
> > #2 0x400074a8 in end ()
> > #3 0x40007182 in end ()
> > #4 0x400085bd in end ()
> >
> > The secret to fixing it for me so far, has been to make sure
> > /usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
> > to figure out WHY have failed miserably.
>
> You have to specify it explicitly when you invoke your mod_perl. We probably
> should supply a support for this from within Apache::Test.
Well, I was also planning on doing some more digging on the strange
segfaults I've been seeing with /usr/X11R6/lib, but it's very strange,
IMO.
> __________________________________________________________________
> 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
--
Philippe M. Chiasson <go...@cpan.org>
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> On Tue, 2003-05-06 at 11:53, Stas Bekman wrote:
>
>>Also you didn't reply whether you can 'make test' modperl1-DSO on OpenBSD
>>(2.9). Because I can't, with a similar segfault in the lexer parse stage as in
>>modperl2.
>
>
> I'll give it a shot under OpenBSD 3.3
>
> BTW, is it me, or I thought you can 'make test' with DSO in mp1 ?
works for me with the system's 5.6.0. Doesn't work with any custom build I've
tried: 5.6.1, 5.8.0, 5.8.1, 5.9.0. Custom 5.6.0 starts but refuses any
connections, even though I can see the LISTENing socket in the output of
'netstat -na'.
Notice that the system's 5.6.0 was (heavily?) patched. so it's not the same as
the core src. but the build arguments are similar. And there is a special
/usr/src/gnu/usr.bin/perl/Makefile.bsd-wrapper
which does lots of things in its own way, instead of using perl's Makefile.
That's on OpenBSD 2.9.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Tue, 2003-05-06 at 11:53, Stas Bekman wrote:
> Also you didn't reply whether you can 'make test' modperl1-DSO on OpenBSD
> (2.9). Because I can't, with a similar segfault in the lexer parse stage as in
> modperl2.
I'll give it a shot under OpenBSD 3.3
BTW, is it me, or I thought you can 'make test' with DSO in mp1 ?
> __________________________________________________________________
> 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
--
Philippe M. Chiasson <go...@cpan.org>
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Randal L. Schwartz wrote:
>>>>>>"Stas" == Stas Bekman <st...@stason.org> writes:
>>>>>
>
> Stas> Also you didn't reply whether you can 'make test' modperl1-DSO on
> Stas> OpenBSD (2.9). Because I can't, with a similar segfault in the lexer
> Stas> parse stage as in modperl2.
>
> Since OpenBSD 2.9 hit "end of life" about a year ago, is this actually
> relevant? There have been some important security patches that
> are no longer available for that ancient release.
There are people who still use this release and want to run mod_perl 2 on it.
If we can make it possible, cool. If not, then we will just put it on the list
of the releases which aren't supported.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Stas" == Stas Bekman <st...@stason.org> writes:
Stas> Also you didn't reply whether you can 'make test' modperl1-DSO on
Stas> OpenBSD (2.9). Because I can't, with a similar segfault in the lexer
Stas> parse stage as in modperl2.
Since OpenBSD 2.9 hit "end of life" about a year ago, is this actually
relevant? There have been some important security patches that
are no longer available for that ancient release.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Also you didn't reply whether you can 'make test' modperl1-DSO on OpenBSD
(2.9). Because I can't, with a similar segfault in the lexer parse stage as in
modperl2.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: OBSD update
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> Well, you did just beat me to the punch ! I have been spending the last
> few days battling the OpenBSD build and was preparing to send out my
> SUCCESS story.
Great work, Philippe. I'll comment on the patch in a separate email.
Unfortunately OpenBSD 2.9 still doesn't work with your patch. Here is the
segfault and how to reproduce it:
LD_LIBRARY_PATH=/data/stas/perl/5.6.1/lib/5.6.1/OpenBSD.i386-openbsd/CORE:$LD_LIBRARY_PATH
gdb
file /data/stas/httpd/prefork/bin/httpd
handle SIGPIPE nostop
handle SIGPIPE pass
set auto-solib-add 0
run -d `pwd`/t -f `pwd`/t/conf/httpd.conf -DONE_PROCESS -DNO_DETATCH -DAPACHE2
sharedlib libperl.so
sharedlib mod_perl.so
where
#0 0x40340296 in Perl_report_uninit ()
#1 0x40340aa5 in Perl_sv_upgrade ()
#2 0x4033549b in Perl_newHV ()
#3 0x402e929a in perl_construct ()
#4 0x402bf4e4 in modperl_startup (s=0x1cdd28, p=0x183018) at mod_perl.c:166
#5 0x402c07dc in modperl_init (base_server=0x1cdd28, p=0x183018) at
mod_perl.c:353
#6 0x402c0998 in modperl_hook_init (pconf=0x183018, plog=0x0, ptemp=0x0,
s=0x1cdd28)
at mod_perl.c:486
#7 0x402c09d4 in modperl_run () at mod_perl.c:497
#8 0x402c5032 in modperl_cmd_load_module (parms=0xdfbfda5c, mconfig=0x1d63c8,
arg=0x1e34e8 "TestDirective::perlloadmodule3") at modperl_cmd.c:499
#9 0x7d7b2 in L413 () at config.c:713
#10 0x7e4c1 in ap_walk_config_sub (current=0x1e34c8, parms=0xdfbfda5c,
section_vector=0x1cfbd8) at config.c:1082
#11 0x7e545 in ap_walk_config (current=0x1d6688, parms=0xdfbfda5c,
section_vector=0x1cfbd8)
at config.c:1121
#12 0x7f2d4 in ap_process_config_tree (s=0x1cdd28, conftree=0x1d6688, p=0x183018,
ptemp=0x187018) at config.c:1594
#13 0x83066 in L67 () at main.c:638
Did you have the same segfault before you managed to make it work?
> 1. On my machine, by default, the max file descriptors is set to 64, and
> it's not sufficient, 128 did it.
how do I change it on OpenBSD? that's the only thing that I haven't tried yet.
> 5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
> yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
> machine. And the perl that ships with my OpenBSD will simply segfault in
> a completely bogus way:
>
> (gdb) bt
> #0 0x400078cf in end ()
> #1 0x40013060 in end ()
> #2 0x400074a8 in end ()
> #3 0x40007182 in end ()
> #4 0x400085bd in end ()
>
> The secret to fixing it for me so far, has been to make sure
> /usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
> to figure out WHY have failed miserably.
You have to specify it explicitly when you invoke your mod_perl. We probably
should supply a support for this from within Apache::Test.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org