You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Nick Tonkin <ni...@rlnt.net> on 2001/02/08 17:02:32 UTC
[RESEND] seg fault with Apache::URI ... weird
Hi all,
No response on this so here it is again, any clues appreciated:
I am encountering a weird problem with Apache::URI ... consider, please,
this test handler:
package WM::Test;
use strict;
sub handler {
my $r = shift;
my $uri = Apache::URI->parse($r, $r->uri);
$uri->hostname($r->get_server_name);
$uri->port($r->get_server_port);
print $uri->unparse;
}
1;
__END__
As written, this causes a seg fault every time. Commenting out _either_
the $uri->hostname assignment _or_ the $uri->port assignment solves the
problem, or even changing the call to one or other of the methods from an
assignment to a read. But when both methods are assigned new values, seg
fault.
This code has worked fine for two years or more on my FreeBSD boxes; this
is on Linux RedHat 7 ... dunno if that makes a difference.
apache etc.:
[Sun Feb 4 10:53:11 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.25
mod_ssl/2.8.0 OpenSSL/0.9.6 configured -- resuming normal operations
perl:
wm@wm ~/wm/perl/WM>perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.2.16-22, archname=i686-linux
uname='linux wm 2.2.16-22 #1 tue aug 22 16:49:06 edt 2000 i686 unknown
'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=2.96 20000731 (Red Hat Linux 7.0)
cppflags='-fno-strict-aliasing'
ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldl -lm -lc -lcrypt
libc=/lib/libc-2.1.92.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Jan 30 2001 10:41:19
@INC:
/usr/local/lib/perl5/5.6.0/i686-linux
/usr/local/lib/perl5/5.6.0
/usr/local/lib/perl5/site_perl/5.6.0/i686-linux
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl
.
Thanks,
Nick
~~~~~~~~~~~
Nick Tonkin
Re: [RESEND] seg fault with Apache::URI ... weird
Posted by Ask Bjoern Hansen <as...@valueclick.com>.
On Fri, 9 Feb 2001, Jeffrey W. Baker wrote:
[...]
> Actually, I didn't. Does this mean that strcasecmp(3) on FreeBSD doesn't
> segfault when given NULL pointers? Or does this mean that the version of
> Apache at the time (1.3.6 and 1.3.9) didn't have this problem? The code
> in Apache hasn't changed since then, so I assume a difference between BSD
> and Linux libc.
Seems like it. We still use your code[1] on 4.2-STABLE with recent
Apache+mod_perl and haven't had any problems while upgrading.
so the conclusion: LINUX SUCKS![2]
;-)
- ask
[1] except $uri->port($r->get_server_port) is now $uri->port(80).
[2] I do use Linux here and there, even RedHat (6.x though), so
let's not start a long thread about which OS sucks less.
--
ask bjoern hansen - <http://ask.netcetera.dk/>
Re: [RESEND] seg fault with Apache::URI ... weird
Posted by Nick Tonkin <ni...@rlnt.net>.
On Fri, 9 Feb 2001, Jeffrey W. Baker wrote:
> On Fri, 9 Feb 2001, Nick Tonkin wrote:
>
> >
> > Hi Jeff,
> >
> > Thanks for your feedback.
> >
> > I wonder if you noticed that this code was from the Auth/Access stuff
> > you did for me a while back ... so I'll patch mine but you might want to
> > take a look at the places you are using it ...
>
> Actually, I didn't. Does this mean that strcasecmp(3) on FreeBSD doesn't
> segfault when given NULL pointers? Or does this mean that the version of
> Apache at the time (1.3.6 and 1.3.9) didn't have this problem? The code
> in Apache hasn't changed since then, so I assume a difference between BSD
> and Linux libc.
Yikes. I'm JAPH -- this (behavior of OS functions on different Unices) is
out of my purview, I'm afraid. However, it is true that the identical code
has worked on FreeBSD with Apache 1.3.[9-current or so] for at least a
year without problems.
HTH,
Nick
Re: [RESEND] seg fault with Apache::URI ... weird
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Fri, 9 Feb 2001, Nick Tonkin wrote:
>
> Hi Jeff,
>
> Thanks for your feedback.
>
> I wonder if you noticed that this code was from the Auth/Access stuff
> you did for me a while back ... so I'll patch mine but you might want to
> take a look at the places you are using it ...
Actually, I didn't. Does this mean that strcasecmp(3) on FreeBSD doesn't
segfault when given NULL pointers? Or does this mean that the version of
Apache at the time (1.3.6 and 1.3.9) didn't have this problem? The code
in Apache hasn't changed since then, so I assume a difference between BSD
and Linux libc.
Cheers,
Jeffrey
Re: [RESEND] seg fault with Apache::URI ... weird
Posted by Nick Tonkin <ni...@rlnt.net>.
Hi Jeff,
Thanks for your feedback.
On Thu, 8 Feb 2001, Jeffrey W. Baker wrote:
> On Thu, 8 Feb 2001, Nick Tonkin wrote:
>
> >
> > Hi all,
> >
> > No response on this so here it is again, any clues appreciated:
> >
> > I am encountering a weird problem with Apache::URI ... consider, please,
> > this test handler:
> >
> >[ ... ]
> >
> > This code has worked fine for two years or more on my FreeBSD boxes; this
> > is on Linux RedHat 7 ... dunno if that makes a difference.
>
> It doesn't make a difference. Segfaults for me on Slackware-current, too.
> However, I would suggest avoinding RH 7.0 and its buggy compiler!
Jeez, I have had nothin but headaches with RedHat. I have always used
FreeBSD but it didn't know about the SCSI disks on the customer's HP
NetServer ... maybe I'll try again with Suse or Slackware before I get too
far along.
>
> I've debugged the problem, but have no solution:
Thanks for getting in where my hands fear to get dirty ... :)
>
> my $uri = Apache::URI->parse($r, $r->uri);
>
> This calls ap_parse_uri_components(), which is responsible for setting
> the scheme, hostname, user, password, port, path, etc. But, the scheme is
> not getting set, because the request line only contains "/path" or such.
>
> $uri->hostname($r->get_server_name);
> $uri->port($r->get_server_port);
>
> These work fine.
>
> print $uri->unparse;
>
> This calls ap_unparse_uri_components(). If there is a hostname but no
> scheme, ap_unparse_uri_components() will pass a null argument to
> strcasecmp, which will cause an invalid memory access and SIGSEGV. You
> can work around the problem by including $uri->scheme('http'); with the
> other accessor methods. In the long run this is probably a bug in Apache.
>
> If you read src/main/util_uri.c in Apache, you can see why commenting out
> one accessor avoids the crash.
>
> Regards,
> Jeffrey Baker
I wonder if you noticed that this code was from the Auth/Access stuff
you did for me a while back ... so I'll patch mine but you might want to
take a look at the places you are using it ...
Thanks again,
Nick
Re: [RESEND] seg fault with Apache::URI ... weird
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Thu, 8 Feb 2001, Nick Tonkin wrote:
>
> Hi all,
>
> No response on this so here it is again, any clues appreciated:
>
> I am encountering a weird problem with Apache::URI ... consider, please,
> this test handler:
>
> package WM::Test;
>
> use strict;
>
> sub handler {
> my $r = shift;
> my $uri = Apache::URI->parse($r, $r->uri);
> $uri->hostname($r->get_server_name);
> $uri->port($r->get_server_port);
> print $uri->unparse;
> }
>
> 1;
> __END__
>
> As written, this causes a seg fault every time. Commenting out _either_
> the $uri->hostname assignment _or_ the $uri->port assignment solves the
> problem, or even changing the call to one or other of the methods from an
> assignment to a read. But when both methods are assigned new values, seg
> fault.
>
> This code has worked fine for two years or more on my FreeBSD boxes; this
> is on Linux RedHat 7 ... dunno if that makes a difference.
It doesn't make a difference. Segfaults for me on Slackware-current, too.
However, I would suggest avoinding RH 7.0 and its buggy compiler!
I've debugged the problem, but have no solution:
my $uri = Apache::URI->parse($r, $r->uri);
This calls ap_parse_uri_components(), which is responsible for setting
the scheme, hostname, user, password, port, path, etc. But, the scheme is
not getting set, because the request line only contains "/path" or such.
$uri->hostname($r->get_server_name);
$uri->port($r->get_server_port);
These work fine.
print $uri->unparse;
This calls ap_unparse_uri_components(). If there is a hostname but no
scheme, ap_unparse_uri_components() will pass a null argument to
strcasecmp, which will cause an invalid memory access and SIGSEGV. You
can work around the problem by including $uri->scheme('http'); with the
other accessor methods. In the long run this is probably a bug in Apache.
If you read src/main/util_uri.c in Apache, you can see why commenting out
one accessor avoids the crash.
Regards,
Jeffrey Baker
Re: [RESEND] seg fault with Apache::URI ... weird
Posted by "G.W. Haywood" <ge...@www.jubileegroup.co.uk>.
Hi there,
On Thu, 8 Feb 2001, Nick Tonkin wrote:
> No response on this so here it is again, any clues appreciated:
> This code has worked fine for two years or more on my FreeBSD boxes; this
> is on Linux RedHat 7 ... dunno if that makes a difference.
[snip]
> config_args=''
This seems strange.
> cc='gcc', optimize='-O2', gccversion=2.96 20000731 (Red Hat Linux 7.0)
And wasn't there a problem with the compiler on RH7?
I think there's something in the List archies.
73,
Ged.