You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by David Robins <db...@davidrobins.net> on 2005/06/24 09:08:37 UTC
BUG: Apache::Cookie saving expired data
I just upgraded to the newest Apache2/mod_perl2, which needed
libapreq2-2.05-dev for Apache2::Request. Apache 2.0.54, mod_perl 2.0.0, perl
5.8.6.
The following statement died with an error about err_headers_out:
Apache2::Cookie->new($r, name => 'blah', value => $sid, expires => '+1D',
path => '/path')->bake();
Fine, checked the code, found that bake now wants $r (strange to require it
two places, but OK, it's 'dev'):
Apache2::Cookie->new($r, name => 'blah', value => $sid, expires => '+1D',
path => '/path')->bake($r);
But now it's outputting a cookie with path '+1D' (and everything else
correct).
if I call path() and expires() separately, it's OK.
I put some trace prints in Apache2::Cookie::new (this is the code that sets
expires and path, name and value are done explicitly):
while(my ($k, $v) = each %attrs) {
$k =~ s/^-//;
print STDERR "setting '$k' to '$v'\n";
print STDERR "pre: ".$cookie->as_string()."\n";
$cookie->$k($v);
print STDERR "post: ".$cookie->as_string()."\n";
}
return $cookie;
Oddly, the 'path' value is corrupt before expires() is even called. I smell
rodent and look for the C code for path(), finding it in Cookie.xs:
--- begin function ---
char *
path(obj, val=NULL)
APR::Request::Cookie obj
char * val
PREINIT:
/*nada*/
CODE:
RETVAL = (char *) obj->path;
if (items > 1) {
obj->path = (char *) val;
}
OUTPUT:
RETVAL
--- end function ---
C programmers will probably see what's wrong here: copying a volatile pointer
(aliasing bug). The char* comes from SvPV_nolen(), which points into the SV,
in this case $v from the 'each'. When $v changes, so will the value of path.
When $v goes out of scope and its PV gets freed, 'val' will be overwritten by
whatever uses the space.
The same problem occurs in the other generated char* functions, e.g. domain,
port, comment, etc.
Should the passed-in strings could be allocated space from the Apache pool
like name and value? I figure someone else is better positioned to make a
clean fix, but if not I can look into writing up a patch.
--
Dave
Isa. 40:31
BUG: version_check reports false negatives
Posted by David Robins <db...@davidrobins.net>.
On Monday June 27, 2005 10:57, Joe Schaefer wrote:
> David Robins <db...@davidrobins.net> writes:
>
> > C programmers will probably see what's wrong here: copying a volatile
> > pointer (aliasing bug). The char* comes from SvPV_nolen(), which
> > points into the SV, in this case $v from the 'each'. When $v changes,
> > so will the value of path. When $v goes out of scope and its PV gets
> > freed, 'val' will be overwritten by whatever uses the space.
> >
> > The same problem occurs in the other generated char* functions,
> > e.g. domain, port, comment, etc.
>
> Exactly- that's another bug we inherited from ExtUtils::XSBuilder, but
> our current svn trunk includes a fix for that.
Thanks, will grab latest from svn.
Do you know about this one?
httpd-apreq-2 # perl Makefile.PL
perl: 5.8.6 ok
mod_perl: 2.000000 ok
Apache::Test: 1.25 ok
ExtUtils::MakeMaker: 6.17 ok
ExtUtils::XSBuilder: 0.27 ok
build/version_check.pl failed: Test::More version 0.6 unsupported (0.47 or
greater is required).
# Looks like your test died before it could output anything.
Please upgrade Test::More first.
./configure --enable-perl-glue --with-perl="/usr/bin/perl"
sh: ./configure: No such file or directory
Doesn't seem to realize that 0.6 > 0.47. The splitting code in
build/version_check.pl looks very suspicious; perhaps use regular numeric
comparison if there's < 2 dots (see attached diff)?
--
Dave
Isa. 40:31
Re: BUG: Apache::Cookie saving expired data
Posted by Joe Schaefer <jo...@sunstarsys.com>.
David Robins <db...@davidrobins.net> writes:
> C programmers will probably see what's wrong here: copying a volatile
> pointer (aliasing bug). The char* comes from SvPV_nolen(), which
> points into the SV, in this case $v from the 'each'. When $v changes,
> so will the value of path. When $v goes out of scope and its PV gets
> freed, 'val' will be overwritten by whatever uses the space.
>
> The same problem occurs in the other generated char* functions,
> e.g. domain, port, comment, etc.
Exactly- that's another bug we inherited from ExtUtils::XSBuilder, but
our current svn trunk includes a fix for that.
--
Joe Schaefer