Re: Undefined symbols in Apache2.so
On Tue, Oct 27, 2009 at 7:15 PM, Allan wrote: > Hello, > > I'm trying to get the Apache2 perl modules to work properly. My system is > FreeBSD 7.2-RELEASE and I'm using perl 5.8.9. I've installed the following > from ports: > > libapreq2 > p5-libapreq2 > mod_perl2 > > Upon initial testing, I noticed that with > > LoadModule apreq_module libexec/apache22/mod_apreq2.so > LoadModule perl_module libexec/apache22/mod_perl.so > > In the Apache configuration file, whenever I run a perl script containing > any of the Apache2 modules (Apache2::Cookie for example) it will cause the > child process to seg fault as shown here: > > [Wed Oct 28 18:22:56 2009] [notice] child pid 62128 exit signal > Segmentation fault (11) > > So to take Apache out of the equations I ran a simple one liner to see what > happens. > > # perl -MApache2::Request -e '$req = Apache2::Request::->new();' > /libexec/ld-elf.so.1: > /usr/local/lib/perl5/site_perl/5.8.9/mach/auto/APR/Request/Apache2/Apache2.so: > Undefined symbol "modperl_xs_sv2request_rec" > > That symbol is in mod_perl.so, which is only available within the Apache2 environment. If you manually build libapreq2 against the installed Apache2/mod_perl, do all the tests pass? -- best regards, Randy
Re: libapreq 1.34 on cpan is an ** UNAUTHORIZED RELEASE **
On Fri, Apr 17, 2009 at 9:32 AM, Geoffrey Young wrote: > Adam Prime wrote: >> I'm guessing that Isaac needs to be added as a co-maintainer for >> libapreq or something, since the latest apreq1 release shows up as being >> unauthorized. >> >> http://search.cpan.org/~isaac/libapreq/ >> >> Also, because of this problem (i think) the link on >> >> http://httpd.apache.org/apreq/ >> >> to >> >> CPAN (http://search.cpan.org/search?mode=module&query=libapreq) >> >> still finds 1.33, not 1.34. > > I've done all I can about this: isaac is already co-maintainer of > Apache::Request and Apache::Cookie. and while the official libapreq > release falls under my pause id, there is no listing for > > libapreq > Apache::libapreq > > that I can find in any of the places where I own or co-maintain things. > I suspect that stas or doug still is still the official owner of those. It seems to be fixed now, at least in the CPAN indices: cpan> d /libapreq/ Distribution id = I/IS/ISAAC/libapreq-1.34.tar.gz CPAN_USERID ISAAC (Issac Goldstand ) CPAN_VERSION 1.34 CONTAINSMODS Apache::Cookie Apache::Request However, search.cpan.org still indicates http://search.cpan.org/~isaac/libapreq-1.34/ is an unauthorized release (perhaps this just needs updating). -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2
On Fri, Mar 6, 2009 at 5:54 PM, Bojan Smojver wrote: > On Sat, 2009-03-07 at 10:34 +1100, Bojan Smojver wrote: > > On Fri, 2009-03-06 at 15:25 -0800, Joe Schaefer wrote: > > > Is that a +1 to release, or not yet? > > > > I'll try to build some RPMs from it first and report back. > > +1. > > Builds OK as RPM on F-10 and F-11. +1 Tests pass on - linux, Apache/2.2.8 (prefork), perl-5.10, latest mod_perl - win32, Apache/2.2.8 (winnt), perl-5.10, latest mod_perl, VC++ 6 -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.11
Issac Goldstand wrote: Steve Hay wrote: Issac Goldstand wrote: Vote results show only 2 +1s (issac,joes) and no -1s. We're still a +1 short of release. Has anyone else tested on Win32 yet? I reported a build error which hasn't been addressed yet: http://marc.info/?l=apreq-dev&m=123244555902865&w=2 I must've missed that. I'll try playing on win32 a bit, I guess... I need to figure out where I'm gonna install a new set of compilers, though, since my old win32 playground died on me a while back, so it might take me some time. After including the missing libapreq.rc from the svn sources, I get a build error: C:\svn\apreq\module\apache2\filter.c(421) : error C2152: 'initializing': pointers to functions with different attributes NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. which comes from APR_REGISTER_OPTIONAL_FN(apreq_handle_apache2); in module/apache2/filter.c. This is on Win32, VC 6, and Apache/2.2.8. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.11
Steve Hay wrote: Issac Goldstand wrote: Vote results show only 2 +1s (issac,joes) and no -1s. We're still a +1 short of release. Has anyone else tested on Win32 yet? I reported a build error which hasn't been addressed yet: http://marc.info/?l=apreq-dev&m=123244555902865&w=2 This is because libapreq.rc in the svn sources wasn't included in the release candidate tarball. -- best regards, Randy
Re: [PATCH] Fix more build issues
On Mon, 2008-05-19 at 22:10 +0300, Nikolay Ananiev wrote: > (i've sent this earlier but seems like it didn't reach the list) [ ... ] Thanks very much for this, and your two earlier patches - these have been committed to the svn sources. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
On Mon, 4 Jun 2007, Fred Moyer wrote: Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on Fedora Core 5, perl 5.8.8, apache 1.3.37, mod_perl 1.30. +1 +1 All tests OK on Win32 (XP) - perl-5.8.8, apache-1.3.34 and mod_perl-1.29. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
On Mon, 30 Apr 2007, Joe Schaefer wrote: Joe Schaefer <[EMAIL PROTECTED]> writes: Issac Goldstand <[EMAIL PROTECTED]> writes: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] +1, tested on Debian stable i386. We need a few votes from pmc members before Issac can release. I'm away for the next several days, but will give it a try on Win32 when I return. -- best regards, Randy
Re: Can't make spool bucket + apreqXXXXXX temp files - Windows & 2.08
On Thu, 19 Apr 2007, Peter Walsham wrote: I have two problems and I don't know if they are related. I see there has been some previous discussions of the problems I have been encountering, but as there aren't solutions currently I thought I would post details on them. Thanks - you're right that this is still a problem ... Both problems involve using Apache2::Upload on Windows. They always occur on the 4 machines I've tested on (3x Windows Server 2003 and 1x XP Pro). I'm using libapreq2 2.08 (see bottom for more specs). Both problems make Apache2::Upload unusable on Windows in a production environment. Problem 1 - Temp files are always left in c:/WINDOWS/Temp Temp files are always left in c:/WINDOWS/Temp until shutdown and cannot be removed through perl or explorer Problem 2 - A large proportion of uploads fail (maybe 20-50%) A large proportion of uploads fail (maybe 20-50%) and produce errors such as: "$param->upload_tempname($req): can't make spool bucket" or "(OS 5)Access is denied. : apreq_brigade_concat failed; TempDir problem?" This problem seems to occur slightly more with larger files, but it is not deterministic. Repeated tries with the same file will eventually result in success, but sometime take 20 retries. I have mainly been testing with images, JPGs etc. Multiple upload request in any one second seem to increase the chance of failure. The fact that this isn't an easily reproduceable problem makes it difficult to track down. Assuming you got the libapreq2 package through ppm via http://theoryx5.uwinnipeg.ca/ppms/ would you mind testing out the current libapreq2 package? It contains a change that has helped at least one other person with a similar problem. The version hasn't changed, so you may have to uninstall libapreq2 first, and also, stop Apache, so that the mod_apreq2.so Apache module can get installed. Thanks. -- best regards, Randy Kobes
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Fri, 30 Mar 2007, Joe Schaefer wrote:
I still believe the problem stems from mixing posix and win32 calls;
but it's perl that mixes them, not apr. In any case, we have evidence
that our cleanup is failing, so we should include code that traps the
error and tries to recover somehow.
How about leaving the current upload.t tests alone, so they can
generate tempfiles on Steve's box, and coming up with some cleanup
code that, at least while we're trying to sort this out, does
something like this:
static apr_status_t apreq_file_cleanup(void *d)
{
struct cleanup_data *data = d;
apr_status_t s = apr_file_remove(data->fname, data->pool);
#ifdef WIN32
if (s != APR_SUCCESS) {
apr_file_t *stderr;
apr_pool_t *p;
const char fmt[] = "apr_file_remove failed with status %d on temp file %s.
"
"Sleeping for 1 sec before retrying";
apr_pool_create_ex(&p, NULL, NULL, NULL);
apr_file_open_stderr(&stderr, p);
apr_file_printf(stderr, fmt, s, data->fname);
sleep(1); /* may need to #include */
apr_pool_clear(p);
apr_pool_destroy(p);
s = apr_file_remove(data->fname, data->pool);
}
#endif
return s;
}
I've tried this just using the sleep() - the printf stuff
doesn't work on Win32. Unfortunately, I still see some
apreqXX left over in the temp directory, very
occasionally (this is with perl-5.8.8, Apache/2.2.2,
mp2 2.03). I tried a sleep(5), but that didn't
help either.
Sometimes, although it's not precisely
correlated, an entry in the error log appears:
$param->upload_tempname($req): can't make spool bucket
at ...lib/APR/Request/Param.pm
which comes from upload_tempname() in
APR/Request/Param/Param.xs, which indicates that
apreq_brigade_concat() has failed. However, sometimes
a stray temp file remains without this error, and
sometimes this error appears without a stray temp
file remaining, so I'm not sure they're directly related.
It's a frustrating problem - there doesn't seem to be
much of a pattern; I can run the tests over and over
again for 15 minutes without seeing any strays, but
at other times they appear every few minutes. This machine
isn't overly busy. The only common thing is that all of
the temp files for me are copies of the perl.exe
used in the upload test, and they're identical copies
to the original.
--
best regards,
Randy
Apache2::Cookie and CGI::Cookie
I've been looking at the CGI::Cookie:
http://search.cpan.org/~lds/CGI.pm-3.27/CGI/Cookie.pm
tests in CGI.pm:
http://search.cpan.org/src/LDS/CGI.pm-3.27/t/cookie.t
run through apreq/glue/perl using Apache2::Cookie:
http://search.cpan.org/~joesuf/libapreq2-2.08/glue/perl/lib/Apache2/Cookie.pm
to create the cookie, and have run across some differences
that lead to failed tests in this context. I'll make
up a proper set of diffs for these tests, but thought it
better to first raise these issues, to see what sort of
approach would be best in resolving them.
In the following, $c is a cookie created with
Apache2::Cookie:
- if one calls
$c->expires;
an error results:
Usage: APR::Request::Cookie::expires(c, time_str)
which arises from the generated
apreq/glue/perl/xs/APR/Request/Cookie/Cookie.c
file: XS_APR__Request__Cookie_expires has in it
if (items != 2)
Perl_croak(aTHX_ "Usage:
APR::Request::Cookie::expires(c, time_str)");
Thus, it requires an argument. However, apreq_cookie_expires
in apreq/library/cookie.c accepts time_str being NULL, in
which case c->max_age is set to -1. Should $c->expires
work with a null argument?
- The expires() method of CGI::Cookie returns the
expires value, but apreq_cookie_expires is declared as
void, so returns nothing. Would it be useful to have
something that returns the current value? Or perhaps
something that returns the max_age member of the
apreq_cookie_t structure?
- If one sets things like
my $rv = $c->domain('some.new.domain');
or
my $rv = $c->path('/some/new/path/');
then in CGI::Cookie the new value is returned, but
Apache2::Cookie returns the old value. Would there
be a desire to change this, or should the difference
simply be documented?
- If one creates a cookie without specifying the -path,
then in CGI::Cookie a default of '/' is used, but
with Apache2::Cookie $c->path is undef. Should
Apache2::Cookie have '/' as the default path?
--
best regards,
Randy
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Thu, 22 Mar 2007, Steve Hay wrote:
Randy Kobes wrote:
On Wed, 14 Mar 2007, Steve Hay wrote:
I tried your patch with the current svn version (revision 518242), but I'm
still seeing intermittent failures (usually in tests 15, 16 and/or 20)
either when I run "nmake test" from the top-level,
[ ... ]
Perhaps just to narrow things down, could you try the
attached C file (a VC++ Makefile is also attached)?
[ ... ]
I ran each program with an argument of 500 for good measure. All four
programs successfully create and then delete a large number (presumably 500,
I didn't count 'em!) of apreq* temp files.
apr_temp and apr_temp_sh both deleted all those files about as quickly as
they were made (i.e. very quickly), while apr_temp_nc and apr_temp_nc_sh both
output loads of CLEANUP messages in the console quickly but then seemed to
hang for nearly a minute, during which time loads of apreq* files were
visible in the temp directory, and then eventually exited and all the files
disappeared.
On my system (Windows XP, VC++ 6, Apache/2.2.2), there's
essentially no difference in speed between the four
programs in cleaning things up, and like you, all temp
files are gone at the end. I'm afraid I'm stuck ...
Since for you apr_temp/apr_temp_sh (fast) and
apr_temp_nc/apr_temp_nc_sh (hangs a minute) pairwise
behave similarly, that suggests APR_SHARELOCK isn't
relevant (which is supported by it's apparent lack of
relevance to this problem in the Apache sources).
APR_FILE_NOCLEANUP does seem to make a (negative)
difference in speed, but perhaps
http://marc.info/?l=apr-dev&m=117448738223552&w=2
is relevant here. In any case, the above results suggests
that having APR_FILE_NOCLEANUP and APR_SHARELOCK both
undefined would be better, which makes sense, but
both apparently help in the Perl glue on Win32. Sigh ...
I'm wondering the following ... The failed upload
tests (15, 16, and/or 20), for me, involve uploading
the perl.exe binary. Is that the same for you? Might
there be a problem with uploading a file which is
a program that might be in use at the time? Does the
attached patches against
apreq/library/util.c
which removes the
flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK
line, and
apreq/glue/perl/t/apreq/upload.t
which skips using perl.exe (and httpd.exe) for
the upload tests on Win32 work for you?
--
best regards,
RandyIndex: util.c
===
--- util.c (revision 522726)
+++ util.c (working copy)
@@ -823,14 +823,6 @@
/* NO APR_DELONCLOSE! see comment above */
flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL | APR_BINARY;
-/* Win32 needs the following to remove temp files.
- * XXX: figure out why the APR_SHARELOCK flag works;
- * a grep through the httpd sources seems to indicate
- * it's only used in sdbm files??
-*/
-#ifdef WIN32
-flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK;
-#endif
rc = apr_file_mktemp(fp, tmpl, flag, pool);
if (rc == APR_SUCCESS) {
Index: upload.t
===
--- upload.t(revision 516765)
+++ upload.t(working copy)
@@ -4,6 +4,7 @@
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest qw(UPLOAD_BODY GET_BODY_ASSERT);
+use constant WIN32 => Apache::TestConfig::WIN32;
use Cwd;
require File::Basename;
@@ -12,9 +13,12 @@
my $module = 'TestApReq::upload';
my $location = Apache::TestRequest::module2url($module);
-my %types = (perl => 'application/octet-stream',
- httpd => 'application/octet-stream',
-);
+my %types = ();
+unless (WIN32) {
+%types = (perl => 'application/octet-stream',
+ httpd => 'application/octet-stream',
+ );
+}
my $vars = Apache::Test::vars;
my $perlpod = $vars->{perlpod};
if (-d $perlpod) {
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Wed, 14 Mar 2007, Steve Hay wrote:
I tried your patch with the current svn version (revision
518242), but I'm still seeing intermittent failures
(usually in tests 15, 16 and/or 20) either when I run
"nmake test" from the top-level, or when I run: perl
-Iblib/arch -Iblib/lib t/TEST -verbose=1 t/apreq/upload.t
from the glue/perl sub-directory :-( I'm running
perl-5.8.8, apache-2.2.2 and mod_perl-2.0.3 (RC3, I
think). Do I need to update anything there?
I don't think so - I ran the tests against essentially the
same setup, and didn't see any failures when run a number
of times.
Perhaps just to narrow things down, could you try the
attached C file (a VC++ Makefile is also attached)?
This uses the relevant parts of libapreq2 to create
and cleanup a temp file; the Makefile produces 4 .exes:
apr_temp: don't enable APR_FILE_NOCLEANUP nor
APR_SHARELOCK
apr_temp_nc: enable only APR_FILE_NOCLEANUP
apr_temp_sh: enable only APR_SHARELOCK
apr_temp_nc_sh: enable both APR_FILE_NOCLEANUP and
APR_SHARELOCK
These are run, for example
apr_temp 20
which will go in a loop and create, and then remove, 20
temp files (with no arguments, the default is 10.
Are there any problems with the cleanup in any of these?
If not, then it looks like the problem is somewhere
within the Perl glue.
--
best regards,
RandyCC = cl
LINK = link
APACHE2 = C:\Apache2
DEF = -DWIN32
INCFLAG = -I$(APACHE2)\include
LIBFLAG = $(APACHE2)\lib\libapr-1.lib $(APACHE2)\lib\libaprutil-1.lib
all: apr_temp apr_temp_nc apr_temp_sh apr_temp_nc_sh
apr_temp: apr_temp.c
$(CC) -c apr_temp.c $(DEF) $(INCFLAG) /Foapr_temp.obj
$(LINK) apr_temp.obj $(LIBFLAG) /out:apr_temp.exe
apr_temp_nc: apr_temp.c
$(CC) -c apr_temp.c $(DEF) -DNOCLEANUP $(INCFLAG) /Foapr_temp_nc.obj
$(LINK) apr_temp_nc.obj $(LIBFLAG) /out:apr_temp_nc.exe
apr_temp_sh: apr_temp.c
$(CC) -c apr_temp.c $(DEF) -DSHARELOCK $(INCFLAG) /Foapr_temp_sh.obj
$(LINK) apr_temp_sh.obj $(LIBFLAG) /out:apr_temp_sh.exe
apr_temp_nc_sh: apr_temp.c
$(CC) -c apr_temp.c $(DEF) -DNOCLEANUP -DSHARELOCK $(INCFLAG)
/Foapr_temp_nc_sh.obj
$(LINK) apr_temp_nc_sh.obj $(LIBFLAG) /out:apr_temp_nc_sh.exe
clean:
del *.obj *.tds *.exe#include "apr.h"
#include "apr_errno.h"
#include "apr_pools.h"
#include "apr_file_io.h"
struct cleanup_data {
const char *fname;
apr_pool_t *pool;
};
static apr_status_t apreq_file_cleanup(void *d) {
struct cleanup_data *data = d;
printf("CLEANUP\n");
return apr_file_remove(data->fname, data->pool);
}
apr_status_t apreq_file_mktemp(apr_file_t **fp,
apr_pool_t *pool,
const char *path) {
apr_status_t rc;
char *tmpl;
struct cleanup_data *data;
apr_int32_t flag;
if (path == NULL) {
rc = apr_temp_dir_get(&path, pool);
if (rc != APR_SUCCESS)
return rc;
}
rc = apr_filepath_merge(&tmpl, path, "apreqXX",
APR_FILEPATH_NOTRELATIVE, pool);
if (rc != APR_SUCCESS)
return rc;
data = apr_palloc(pool, sizeof *data);
/* cleanups are LIFO, so this one will run just after
the cleanup set by mktemp */
apr_pool_cleanup_register(pool, data,
apreq_file_cleanup, apreq_file_cleanup);
/* NO APR_DELONCLOSE! see comment above */
flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL | APR_BINARY;
#ifdef NOCLEANUP
flag |= APR_FILE_NOCLEANUP;
#endif
/* Win32 needs the following to remove temp files */
#ifdef SHARELOCK
flag |= APR_SHARELOCK;
#endif
rc = apr_file_mktemp(fp, tmpl, flag, pool);
if (rc == APR_SUCCESS) {
apr_file_name_get(&data->fname, *fp);
data->pool = pool;
printf("fname=%s\n", data->fname);
}
else {
apr_pool_cleanup_kill(pool, data, apreq_file_cleanup);
}
return rc;
}
int main(int argc, char **argv) {
apr_status_t rc;
apr_pool_t *p;
apr_file_t *fp;
int count=10, i;
const char *path = NULL;
if (argc == 2) count = atoi(argv[1]);
rc = apr_app_initialize(&argc, &argv, NULL);
for (i=0; i
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Mon, 12 Mar 2007, Vinay Y S wrote: On 3/12/07, Joe Schaefer <[EMAIL PROTECTED]> wrote: [ ... ] Here's a different suggestion to try: [ ... ] In other words, delete the file *before* closing it. This shouldn't matter. My version is apreq2-2.0.8 with Apache 2.2.2/2.2.4 build with Visual Studio 2003 running on Windows XP SP2 with all updates. I'm not sure if this is relevant, but the problems we found earlier with this is with VC++ 6, which must be used for compatibility with ActivePerl. I don't know the perl code, but I would assume it would be doing all it's stuff(open/copy/closing the temp file) before either of the two cleanup functions are called above. So, if we apply the patch suggested by Joe or me(second patch) and fix the perl code which originally triggered all this discussion, all should be fine. You're probably right about fixing the perl code; however, this may lie somewhere in the Perl/mod_perl side of things. And due to the nature of the failures, it's a hard thing to track down. Just in case it wasn't clear from the earlier messages, the failures we found were only in the upload test of the perl glue; running it many (>15) times in rapid succession resulted in occasional (and seemingly, randomly occuring) stray temp files remaining. The problem seemed worse on Steve's system compared to mine, although we were running similar software versions (Windows XP, VC++ 6, httpd-2.2.2, and the latest perl-5.8 and mod_perl at the time). The "fix" that was introduced seemed to help this problem, which I agree doesn't make sense from the C side. However, as one of the major consumers of libapreq2 in the Win32 world are people running ActivePerl with similar setups who install this via ppm, it's important to support that side of things. It may be that this was a problem outside of libapreq2; since the time of the above failures, I've upgraded perl, mod_perl, and Apache, and haven't encountered similar failures with either your patch or Joe's. I would though like to get Steve's experiences with this, as his setup encountered more of the original failures. -- best regards, Randy
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Sun, 11 Mar 2007, Joe Schaefer wrote: Which Win32 tho? 98,ME,XP,XPPro,Vista,NT,etc? For me, it's XP, and if I remember correctly, that's what Steve was using. -- best regards, Randy
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Sun, 11 Mar 2007, Joe Schaefer wrote: So I think what's happening in the cases where the tempfiles aren't being removed is that the call to apr_file_remove is failing. On windows, let's trap that error in apreq_file_cleanup and call DeleteFile() in that case. If that fails return APR_EGENERAL. From what I can see from http://svn.apache.org/viewvc/apr/apr/trunk/file_io/win32/open.c?revision=428317&view=markup apr_file_remove() on Win32 is calling DeleteFile(), with unicode issues taken into consideration. So if apr_file_remove() is failing, then DeleteFile() is failing. I've seen problems in the Perl world on Win32 unable to delete files because the file handle is still in scope: for example, my $file = 'dummy.txt'; open(my $fh, '>', $file); print $fh "Hello"; unlink $file or warn $!; works on Unix but fails on Win32 with a "permission denied" error. The fix is to close($fh); before unlinking the file. Vinay's original patch with the addition of apr_file_close() I thought was doing the analagous thing (I had originally tried this, but had been inserting it too early in the process). By the way, as discussed at http://marc.theaimsgroup.com/?l=apreq-dev&m=115439946810955&w=2 I tried a simple C program that just uses the code in apreq_file_mktemp(), with the registered apreq_file_cleanup(), to open and close a temp file - in this case, the temp files were cleaned up with or without the #ifdef WIN32 flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; #endif Since this problem of temp files only happens with the Perl glue, it may be that there's some complex interaction happening between apr and Perl. Also, get rid of this ifdef in apreq_file_mktemp: #ifdef WIN32 flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; #endif It's bogus, and IMO is only confusing the situation. I agree, but, at least at the time it was added, it definitely did help in the cleanup of temp files. So it'd be nice to be able to replace this with something more understandable. -- best regards, Randy
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Sun, 11 Mar 2007, Joe Schaefer wrote: May I suggest that people start posting version numbers of both libapr and operating system? All we're doing now is running around blindly tweaking crap that we really shouldn't be tweaking in the first place. The problems described at http://marc.theaimsgroup.com/?t=11533762941&r=1&w=2 were on Win32 with httpd-2.2.2, based on the libapreq2-2.08-RC4 sources. VC++ 6 was used to compile things. -- best regards, Randy
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Fri, 9 Mar 2007, Joe Schaefer wrote:
Randy, do you know why we use the APR_FILE_NOCLEANUP flag? Maybe
we should just remove that and see if it fixes the problem Vinay
is seeing.
Hi Steve, and all,
If you remember from
http://marc.theaimsgroup.com/?t=11533762941&r=1&w=2
there was a problem with stray temp files in apreq
remaining after uploads; we came up with a fix that
worked most of the time, but Vinay has come up with
something that appears better, and more understandable.
The attached diff against library/util.c (in the svn
sources) works for me in getting multiple invocations
of the glue/perl/t/apreq/upload.t to pass; if you have
time, could you try it out to see how it fares on
your system? Thanks.
--
best regards,
RandyIndex: util.c
===
--- util.c (revision 516656)
+++ util.c (working copy)
@@ -775,12 +775,14 @@
struct cleanup_data {
const char *fname;
+apr_file_t *f;
apr_pool_t *pool;
};
static apr_status_t apreq_file_cleanup(void *d)
{
struct cleanup_data *data = d;
+apr_file_close(data->f);
return apr_file_remove(data->fname, data->pool);
}
@@ -823,19 +825,12 @@
/* NO APR_DELONCLOSE! see comment above */
flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL | APR_BINARY;
-/* Win32 needs the following to remove temp files.
- * XXX: figure out why the APR_SHARELOCK flag works;
- * a grep through the httpd sources seems to indicate
- * it's only used in sdbm files??
-*/
-#ifdef WIN32
-flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK;
-#endif
-rc = apr_file_mktemp(fp, tmpl, flag, pool);
+rc = apr_file_mktemp(fp, tmpl, flag, pool);
if (rc == APR_SUCCESS) {
apr_file_name_get(&data->fname, *fp);
data->pool = pool;
+data->f = *fp;
}
else {
apr_pool_cleanup_kill(pool, data, apreq_file_cleanup);
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
On Fri, 10 Nov 2006, Issac Goldstand wrote: Philip M. Gollucci wrote: Issac Goldstand wrote: Following up on the FAIL report for win32: Which CGI tests fail ? Erm, my win32 build computer fizzled a bit last night, but I'll try to remember to post this on Sunday. I've already seen the same tests failing on a separate PC with a separate build environment (at work - yesterday's build were on my home office PC); I saw it when I was originally writing the interactive-cgi module (but never found time to chase them down) The new Apache-Test-1.29-RC2 runs the test suite for 2.08 just fine (against mod_perl-2.0.3-RC2). However, here the test suite can't load mod_perl (also mod_perl-2.0.3-RC2) into the server properly: The dection of mod_perl has changed 0 between 1.27->1.29 much less 1.29-rc1 and 1.29-rc2 CGI passes most tests (it fails 7; libapreq-2.08 also fails the same ones lately. That's a separate issue for a separate thread, though), it's just the mod_perl ones that seem to fail. Didn't you just contradict yourself ? I'm probably reading that wrong I don't think so - the CGI (t/apreq/cgi.t) test runs as a normal CGI, so IIRC doesn't go through mod_perl... That's true, but it needs mod_perl, for some APR::* modules. Can you try installing the latest mod_perl-2.0.3-rc2 that Philip posted to see if that helps? Deeper probing (t/conf/httpd.conf) shows that: #unable to locate mod_perl.so (could be a static build) Yes that would be the problem. (does Apache-Test have the correct path to apxs and is it actually functional?) I believe so; the same Apache-Test detects the same mod_perl just fine on the 2.08 tarball - it's really quite odd... Sunday I'll see if I can reproduce this at work. Does the installed Apache::TestConfigData point to the correct httpd.exe? -- best regards, Randy Kobes
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
On Wed, 8 Nov 2006, Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: +1 - all tests pass on - Win32: Apache/2.2.3 (winnt), perl-5.8.8 (ActivePerl 817), mod_perl-2.0.3-rc2 - linux: Apache/2.0.55 (prefork), perl-5.8.7, mod_perl-2.0.2 -- best regards, Randy Kobes
Win32 all-in-one binary package
I've been maintaining one of the all-in-one binary packages for Win32 that contains Perl, Apache, plus related modules, for some time: http://perl.apache.org/docs/2.0/os/win32/install.html#All_in_one_packages Since starting this, though, the standard ActivePerl and Apache Win32 distributions have evolved significantly in terms of features, ease of installation, etc., and I'm wondering now if there might be a better model for the all-in-one package. In particular, what I'm thinking of is making up some mega ppm package (to be installed with an existing ActivePerl and Apache installation) containing web-based Perl modules (mod_perl, libapreq2, HTML::Mason, Apache::ASP, etc.), plus some some sample pages and Apache configuration directives, which could be installed locally. This would be a lot smaller to maintain than an all-in-one distribution, and thus could be updated more frequently. What I'm wondering is, is there something significant missing from such a mega ppm package that would be useful to include? Any thoughts on this, or other ideas on any other aspect, would be appreciated - thanks! -- best regards, Randy Kobes
Win32 ppm packages
I'd like to get a sense from Win32 ppm users of mod_perl and/or libapreq2 about the following. Right now in our http://theoryx5.uwinnipeg.ca/ppms/ ppm repository, there's ppm packages for mod_perl and libapreq2. The ones compatible with Apache/2.0 are called mod_perl and libapreq2, respectively, while those for Apache/2.2 are mod_perl-2.2 and libapreq2-2.2, respectively. What I'm wondering is, if Apache/2.2 is by now mostly used, should I switch the names: mod_perl and libapreq2 for Apache/2.2, and mod_perl-2.0 and libapreq-2.0 for Apache/2.0? Thoughts? -- best regards, Randy Kobes
Re: [RELEASE CANDIDATE]: libapreq2 2.09-RC1
On Thu, 7 Sep 2006, Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09-rc1.tar.gz +1. Tested on - Win32: Apache/2.2.3 (winnt), perl-5.8.8 (ActivePerl 819), with mod_perl-2.0.3-rc1 installed - linux: Apache/2.0.55 (prefork), perl-5.8.7, with mod_perl 2.0.2 -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
On Sun, 6 Aug 2006, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC5.tar.gz Builds fine and all tests pass on: - linux, Apache/2.0.55 prefork, mod_perl 2.02, perl-5.8.7 - Win32, Apache/2.2.2 winnt, mod_perl svn, perl-5.8.8 (ActiverPerl 817) Unfortunately, the problem on Win32 with running the glue/perl/t/apreq/upload.t test numerous times seems to be still with us; I still see sporadic temp files not being cleaned up. However, the tests still pass for me; it'd be interesting to see if Steve has problems. However, I don't want this problem to hold up a release any longer, so I'm +1 for this. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Tue, 25 Jul 2006, Randy Kobes wrote: On Tue, 25 Jul 2006, Steve Hay wrote: Yes, that works for me! I tried the individual test and the whole test suite dozens of times over and didn't get a single failure. I'm not sure how it makes any difference, though, or exactly what it does. I searched the whole of my httpd-2.2.2 folder and only found one use of it (actually, of its new name, APR_FOPEN_SHARELOCK) relating to sdbm files. What am I missing? I'm baffled now, too - as far as I can see too, apr only uses APR_FOPEN_SHARELOCK in sdbm files, and neither mod_perl nor librapreq2 seems to use it. But it does make a difference - although I don't see as many failures as you do, without APR_FOPEN_SHARELOCK I definitely get temp files left over. Is the change safe, or does it introduce any security issues with temporary spool files being shared somehow? That I'm not sure of, especially now that I'm not sure what it's affecting ... I still haven't been able to track down why the use of APR_FOPEN_SHARELOCK works in cleaning up the temp files. I did try a simple C apr-based program that just opens a temp file in the same way as is done within apreq_file_mktemp(), with the registered apreq_file_cleanup(), writes some random text to it, and then closes it - in this the temp files were cleaned up with or without APR_FOPEN_SHARELOCK, and also with or without APR_FILE_NOCLEANUP. So something more complex is involved. Nevertheless, unless someone objects in the next day or so, I'd like to commit this change, as I think leaving temp files lying around is a worse problem. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Tue, 25 Jul 2006, Steve Hay wrote: Yes, that works for me! I tried the individual test and the whole test suite dozens of times over and didn't get a single failure. I'm not sure how it makes any difference, though, or exactly what it does. I searched the whole of my httpd-2.2.2 folder and only found one use of it (actually, of its new name, APR_FOPEN_SHARELOCK) relating to sdbm files. What am I missing? I'm baffled now, too - as far as I can see too, apr only uses APR_FOPEN_SHARELOCK in sdbm files, and neither mod_perl nor librapreq2 seems to use it. But it does make a difference - although I don't see as many failures as you do, without APR_FOPEN_SHARELOCK I definitely get temp files left over. Is the change safe, or does it introduce any security issues with temporary spool files being shared somehow? That I'm not sure of, especially now that I'm not sure what it's affecting ... -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Mon, 24 Jul 2006, Steve Hay wrote:
Randy Kobes wrote:
Also, just to verify that it is the stray temp files
left over that are causing the problem, does it help
if you change the APR_EXCL flag in the
call to apr_file_mktemp on about line 832 of library/util.c
to APR_TRUNCATE?
Yep, that makes the errors go away: it didn't fail once in about two dozen
runs.
Does the following help?
=
Index: util.c
===
--- util.c (revision 425268)
+++ util.c (working copy)
@@ -811,6 +811,7 @@
apr_status_t rc;
char *tmpl;
struct cleanup_data *data;
+apr_int32_t flag;
if (path == NULL) {
rc = apr_temp_dir_get(&path, pool);
@@ -829,9 +830,13 @@
apr_pool_cleanup_register(pool, data,
apreq_file_cleanup,
apreq_file_cleanup);
-rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE!
see comment above */
- APR_CREATE | APR_READ |
APR_WRITE
- | APR_EXCL | APR_BINARY, pool);
+/* NO APR_DELONCLOSE! see comment above */
+flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL |
APR_BINARY;
+/* Win32 needs the following to remove temp files */
+#ifdef WIN32
+flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK;
+#endif
+rc = apr_file_mktemp(fp, tmpl, flag, pool);
if (rc == APR_SUCCESS) {
apr_file_name_get(&data->fname, *fp);
With the APR_SHARELOCK flag, I don't see any temp files
left over after about 50 runs of the upload.t test (without
it, but still with APR_FILE_NOCLEANUP, I would have 2-3
left over after 50 runs).
--
best regards,
Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
On Wed, 12 Jul 2006, Randy Kobes wrote: On Tue, 11 Jul 2006, Issac Goldstand wrote: I wanted to test the build, since Randy said he couldn't, but ran into troubles compiling mod_perl (my gut feeling is that it's related to all the apr-1.lib files, and the version of apxs, et al, (at least the one I have), seems to be giving the wrong lib names) - and haven't had time to really look at that. It's odd because I don't think libapreq has this issue, as it builds the C library quite nicely. I know that I had trouble with lib names in earlier RC's, but Randy sorted out the problems with changes to various components. Make sure you are using the latest mod_perl sources from SVN and you must get the latest apxs from http://perl.apache.org/dist/win32-bin/ (version 0.4). That helped. It builds cleanly now. First seuite of tests runs OK: C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness()" library\t\cookie.t library\t\parsers.t library\t\params.t library\t\version.t library\t\cookie.ok library\t\params.ok library\t\parsersok library\t\versionok All tests successful. Files=4, Tests=648, 9 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) However, I seem to have another apxs-related issue... mod_apreq_access_test.c seems to be linking against the old APR-0.x libraries: (hope formatting doesn't get too mutilated) C:\apache2\bin\apxs.bat -I../../../apache2 -I../../../../include -lD:\cpp\libapreq2-2.08\win32\libs\libapreq2.lib -lD:\cpp\libapreq2-2.08\win32\libs\mod_apreq2.lib -llibhttpd -D APACHE2 -p -ID:\cpp\libapreq2-2.08\module\t\c-modules -c mod_apreq_access_test.c cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -I"C:\apache2\include" /I"../../../apache2" /I"../../../../include" /I"D:\cpp\libapreq2-2.08\module\t\c-modules" /D "APACHE2" /c /Fomod_apreq_access_test.lo mod_apreq_access_test.c mod_apreq_access_test.c link kernel32.lib /nologo /subsystem:windows /dll /machine:I386 /libpath:"C:\apache2\lib" /out:mod_apreq_access_test.so D:\cpp\libapreq2-2.08\win32\libs\libapreq2.lib D:\cpp\libapreq2-2.08\win32\libs\mod_apreq2.lib libhttpd.lib C:\apache2\ lib\libaprutil.lib C:\apache2\lib\libapr.lib mod_apreq_access_test.lo LINK : fatal error LNK1181: cannot open input file 'C:\apache2\lib\libaprutil.lib' apxs:Error: Command failed with rc=10289152. NMAKE : fatal error U1077: 'C:\apache2\bin\apxs.bat' : return code '0x1' Stop. Will try keep you posted... Issac Thanks for pointing that out - I'll take a look at it early next week, when I get back. That problem (with using the wrong libaprutil.lib name with Apache-2.2) doesn't arise for me. I'm wondering if it's picking up an old Apache installation and/or is getting confused with a previous build? Can you try reinstalling apxs from http://perl.apache.org/dist/win32-bin/, rebuild and reinstall mod_perl2 from the svn sources, and then rebuild libapreq2 from clean sources? Does that help? -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Thu, 20 Jul 2006, Randy Kobes wrote: On Thu, 20 Jul 2006, Philip M. Gollucci wrote: Steve Hay wrote: repeatedly from the glue/perl sub-directory and see whether or not it ever fails for you. Did you get round to trying that? Just did. 24 times. 100% success. My usual combination of things. Like Steve, I still see this failing occasionally on Win32, but not in a predictable manner. And it's not always the same file that fails in the upload test. I'll try some things to try to make it reproduceable in the next couple of days, but if that doesn't pan out, I wouldn't want this to hold up the release. I think this problem lies in the cleanup of the temp files used by the upload; when the test fails, I see [Thu Jul 20 23:45:45 2006] [error] [client 127.0.0.1] (OS 80)The file exists. : apreq_brigade_concat failed; TempDir problem? which is coming from about line 288 of module/apache2/filter.c. The "file exists" message I think comes from the fact that, when the test fails, there's old temp files left over from a previous run. So perhaps the cleanup discussed in library/util.c at around line 797 is failing occasionally? -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
On Tue, 11 Jul 2006, Issac Goldstand wrote: I wanted to test the build, since Randy said he couldn't, but ran into troubles compiling mod_perl (my gut feeling is that it's related to all the apr-1.lib files, and the version of apxs, et al, (at least the one I have), seems to be giving the wrong lib names) - and haven't had time to really look at that. It's odd because I don't think libapreq has this issue, as it builds the C library quite nicely. I know that I had trouble with lib names in earlier RC's, but Randy sorted out the problems with changes to various components. Make sure you are using the latest mod_perl sources from SVN and you must get the latest apxs from http://perl.apache.org/dist/win32-bin/ (version 0.4). That helped. It builds cleanly now. First seuite of tests runs OK: C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness()" library\t\cookie.t library\t\parsers.t library\t\params.t library\t\version.t library\t\cookie.ok library\t\params.ok library\t\parsersok library\t\versionok All tests successful. Files=4, Tests=648, 9 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) However, I seem to have another apxs-related issue... mod_apreq_access_test.c seems to be linking against the old APR-0.x libraries: (hope formatting doesn't get too mutilated) C:\apache2\bin\apxs.bat -I../../../apache2 -I../../../../include -lD:\cpp\libapreq2-2.08\win32\libs\libapreq2.lib -lD:\cpp\libapreq2-2.08\win32\libs\mod_apreq2.lib -llibhttpd -D APACHE2 -p -ID:\cpp\libapreq2-2.08\module\t\c-modules -c mod_apreq_access_test.c cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -I"C:\apache2\include" /I"../../../apache2" /I"../../../../include" /I"D:\cpp\libapreq2-2.08\module\t\c-modules" /D "APACHE2" /c /Fomod_apreq_access_test.lo mod_apreq_access_test.c mod_apreq_access_test.c link kernel32.lib /nologo /subsystem:windows /dll /machine:I386 /libpath:"C:\apache2\lib" /out:mod_apreq_access_test.so D:\cpp\libapreq2-2.08\win32\libs\libapreq2.lib D:\cpp\libapreq2-2.08\win32\libs\mod_apreq2.lib libhttpd.lib C:\apache2\ lib\libaprutil.lib C:\apache2\lib\libapr.lib mod_apreq_access_test.lo LINK : fatal error LNK1181: cannot open input file 'C:\apache2\lib\libaprutil.lib' apxs:Error: Command failed with rc=10289152. NMAKE : fatal error U1077: 'C:\apache2\bin\apxs.bat' : return code '0x1' Stop. Will try keep you posted... Issac Thanks for pointing that out - I'll take a look at it early next week, when I get back. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
On Sat, 8 Jul 2006, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC3.tar.gz [ .. ] I'd like to make the actual release around Wednesday of next week (07/12/2006) I'm away next week on holiday - if someone could test this out on Win32, that'd be great. -- best regards, Randy
testing Apache/2.2 on Win32
For those Win32 users using ActivePerl 8xx, I've placed at http://theoryx5.uwinnipeg.ca/ppms/ ppm packages suitable for use with Apache/2.2: mod_perl-2.2, for mod_perl-2, and libapreq-2.2, for libapreq2 (Apache2::Request and friends). Note that if you're using Apache/2.2 you should use these packages; the mod_perl and libapreq2 packages also available in this repository were compiled against Apache/2.0, which aren't compatible with Apache/2.2. -- best regards, Randy Kobes
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC2
On Wed, 24 May 2006, Steve Hay wrote: [ ... ] I've installed the new apxs (0.4) and rebuilt and reinstalled mod_perl from SVN (rev 409101) and tried libapreq again: The t/apreq/cgi.t tests now pass OK, but I have an intermittent failure in some of the t/apreq/upload.t tests: sometimes I have some of tests 17-20 failing. The error log contains a couple of entries that say "The file exists."; I'm not sure if it is related or not. Do you see this at all, Randy? If I run the test suite half a dozen times then it almost always go wrong at least once. Now that you point it out, I see those failures too, occasionally, when running the tests multiple times. I'll look into it - thanks. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC2
On Wed, 24 May 2006, Philip M. Gollucci wrote: all the libapreq2 tests now pass for me with perl-5.8.8 (ActivePerl 817) and Apache/2.2.2. Good, so you didn't change anything in libapreq2. So does that count as a +1 ? Unfortunately, I forgot to change one thing in libapreq2, related to the change in the name of the apr and apu utilities. I'll do that later today, after testing it out. Sorry about that. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC2
On Tue, 23 May 2006, Steve Hay wrote: Philip M. Gollucci wrote:> Please download, test, and report back on the following> candidate tarball:> > http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC2.tar.gz All OK for me now on WinXP (Apache/2.2.2, Perl/5.8.8, mod_perl/SVN), except for the previously noted failures in t/apreq/cgi.t. The problem with the t/apreq/cgi.t tests is that the Win32 apr and apu config scripts were using the old names of apr-config and apu-config, while for Apache/2.2 they should be called apr-1-config and apu-1-config (to agree with the convention on Unix). I've changed the apxs_win32.tar.gz archive on perl.apache.org to use these new names, and after reinstalling these utilities, and rebuilding and installing mp2 in the svn tree (there was a minor change needed there), all the libapreq2 tests now pass for me with perl-5.8.8 (ActivePerl 817) and Apache/2.2.2. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
On Mon, 22 May 2006, Steve Hay wrote: [ ... ] I have one test script failing, though. When I ran "nmake test" from the top-level directory every test in glue\perl\t\apreq\cgi.t failed with a generic Windows popup error message saying "perl.exe has encountered a problem and needs to close...": Failed Test Stat Wstat Total Fail Failed List of Failed---t\apreq\cgi.t 41 41 100.00% 1-41Failed 1/10 test scripts, 90.00% okay. 41/191 subtests failed, 78.53% okay. When I cd into glue\perl and run "nmake test" from there I get different popups instead complaining about missing DLL's. If I add their locations to my PATH then I get the same "perl.exe has encountered..." messages as before. I believe that error is the same error that arises in many of the apr-ext tests in mod_perl (with Apache/2.2); with httpd-2.2.2, it arises on about line 798 of apr_pools.c of srclib/apr/memory/unix/, in the apr_pool_create_ex() function - the line if (allocator == NULL) allocator = parent->allocator; has "parent" apparently NULL. If anyone has tested mod_perl and/or libapreq under Apache/2.2 with unix, can you let us know if you encounter problems either with mod_perl's apr-ext tests or withj libapreq's glue/perl/t/apreq/cgi.t tests? Thanks. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
On Mon, 22 May 2006, Philip M. Gollucci wrote: Steve Hay wrote: Philip M. Gollucci wrote: - When I ran "perl Makefile.PL --with-apache2=C:/apache2" I got an error from win32/Configure.pl about Archive-Tar being missing, but this is not mentioned in the PREREQUISITES file and was not checked by test_prereq in Makefile.PL before calling this script. Committed revision 408136 This doesn't seem to do anything for me. When I run Makefile.PL without Archive-Tar present it just fails as before: Actually, it wasn't supposed to.. That commit just causes it to be listed in the PREREQUISITES file. Can't locate Archive/Tar.pm in @INC (@INC contains: C:/perl5mt/lib C:/perl5mt/site/lib .) at win32/Configure.pl line 11. BEGIN failed--compilation aborted at win32/Configure.pl line 11. system C:\perl5mt\bin\perl.exe win32/Configure.pl --with-apache2-apxs="C:\apache2\bin\apxs.bat" --with-perl="C:\perl5mt\bin\perl.exe" --with-apache2="C:/apache2" --enable-perl-glue failed: 512 at Makefile.PL line 88. Do we want to eval the this in Configure.pl ? I'll leave this one to Randy if he is still reading :) eval()ing it is a good idea, and then die()ing if it's not available - I've committed a fix for this. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
On Fri, 19 May 2006, Steve Hay wrote: Philip M. Gollucci wrote:> Please download, test, and report back on the following> candidate tarball:> > http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC1.tar.gz WinXP/VC++ 6.0, Apache-2.2.2, Perl-5.8.8: - When I extracted the tarball, I found two extra directories (docs and man) besides libapreq2-2.08. I trust these won't be in the release version. - When I ran "perl Makefile.PL --with-apache2=C:/apache2" I got an error from win32/Configure.pl about Archive-Tar being missing, but this is not mentioned in the PREREQUISITES file and was not checked by test_prereq in Makefile.PL before calling this script. - When I run "nmake", the build process falls over at library/error.c with the error: NMAKE : fatal error U1073: don't know how to make '"C:\apache2\lib\libapr.lib"'Stop.NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\Bin\NMAKE.EXE"' : return code '0x2' I assume this is the same problem that mod_perl-2.0 was having until Randy came to the rescue recently: the library in question is now called libapr-1.lib. The latter problem should now be fixed in the svn sources - thanks. -- best regards, Randy
Re: svn commit: r408136 - /httpd/apreq/trunk/build/version_check.pl
On Sun, 21 May 2006, Philip M. Gollucci wrote: I'd prefer that no version of Archive::Tar be specified for Win32, or perhaps even no such prerequisite at all; it's a core module in ActivePerl, and has a history of some instability on Win32 - an upgrade may break things on the local system. I was trying to address this from Steven Hay's post: - When I ran "perl Makefile.PL --with-apache2=C:/apache2" I got an >>error from win32/Configure.pl about Archive-Tar being missing, but >>this is not mentioned in the PREREQUISITES file and was not checked by >>test_prereq in Makefile.PL before calling this script. It's a trade-off - Steve builds his own perl, so having Archive::Tar as a prerequisite makes sense, but especially requiring a particular version may mess up an ActivePerl with an older version. So I think requiring version "0" may be safest. I'm fine with whatever you say is best... I'm not a MS guy. I guess people on cygwin using the cygwin perl shouldn't be using the win32/Configure.pl. (I don't think Steven is) That's right, on both counts. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
On Thu, 18 May 2006, Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC1.tar.gz Does this compile with Apache/2.2 on unix? I've been working on 2.2 support for Win32, but will need a few days, and am just wondering if I should rush it. Thanks. -- best regards, Randy
Re: File upload
On Sat, 25 Feb 2006, Franky Braem wrote: Randy Kobes wrote: On Sat, 25 Feb 2006, Franky Braem wrote: The directive LoadFile "C:/Path/to/Apache2/bin/libapreq2.dll" should specify the absolute location where the libapreq2.dll library resides. I've downloaded the latest Apache source 2.0.55 and build it using Visual C++ Express 2005. Now it works (The LoadFile is not needed anymore). The problems I had was with the previous version of Apache 2.0.54. Are there any prebuilt binaries for Windows? Or do I always have to build libapreq2 myself? I'm confused by the above, in whether you're having problems with httpd and/or apreq. The LoadFile directive would be needed with Apache 2.0.54 or 2.0.55 in using apreq, in order to load libapreq2.dll, unless the directory it resides in occurs in your PATH environment variable. Since you have a working C compiler, it'd be better to build libapreq2 yourself. For Win32, you should be able to do, in the unpacked source tree, perl Makefile.PL --with-apache2=C:\Path\to\Apache2 nmake nmake test nmake install You'll need ExtUtils::XSBuilder, Test::More, and mod_perl installed first. -- best regards, Randy
Re: File upload
On Sat, 25 Feb 2006, Franky Braem wrote: Try instead LoadFile "C:/Path/to/Apache2/bin/libarpeq2.dll" LoadModule apreq_module modules/mod_apreq2.so I get the following now: C:\Program Files\apachefriends\xampp\apache\bin>apache Syntax error on line 177 of C:/Program Files/apachefriends/xampp/apache/conf/httpd.conf: Cannot load libapreq2.dll into server: The specified module could not be found. The directive LoadFile "C:/Path/to/Apache2/bin/libapreq2.dll" should specify the absolute location where the libapreq2.dll library resides. -- best regards, Randy
Re: File upload
On Fri, 24 Feb 2006, Franky Braem wrote: Randy Kobes wrote: It should be possible - is that what you're using? If you are, you should ensure everything else (httpd, apr, ...) was also built with the same compiler - there are known problems mixing, for example, things compiled with VC++ 7 with those of VC++ 6. I've got the following in my httpd.conf: LoadFile modules/mod_apreq2.so Try instead LoadFile "C:/Path/to/Apache2/bin/libarpeq2.dll" LoadModule apreq_module modules/mod_apreq2.so -- best regards, Randy
Re: [RT] what's the roadmap?
On Thu, 23 Feb 2006, Ryan Perry wrote: On Feb 23, 2006, at 6:38 AM, Nikolay Ananiev wrote: I'd like to see the APR::* into a separate package on CPAN and apreq to stay as it is now. Why? Because it can be used on different environments and different servers. For example I want to use apreq with ActiveState's PerlEx on IIS without the need to install Apache and mod_perl. You bring up a good point. However, I think the masses are better off by moving apreq into httpd. Supporting a proprietary piece of software over enhancing an open source one that is more frequently used doesn't seem to make sense to me. Assuming the APR::* modules currently in mod_perl can be packaged in a separate distribution, one way to accommodate both viewpoints is to include the sources for the libapreq2 library in both httpd (used for the Apache mod_apreq2) and also in a separate Perl distribution (used for APR::Request and friends). -- best regards, Randy
Re: [RT] what's the roadmap?
On Tue, 21 Feb 2006, Geoffrey Young wrote: in principle I don't mind this idea, and we can certainly consider taking the perl glue under the mod_perl project. I guess the more difficult part would be in deciding how to package things so that it's the least complex for the end user. From the experiences I have had talking to people on the mod_perl list about mod_perl2, the most common issue for users coming from mod_perl 1 is how to handle the request data other than using $r->args or CGI. I think that having the perl glue install alongside the standard mod_perl libraries would be ideal. IMHO, a sizable chunk of mod_perl first timers are looking to process arguments from a form, which can of course be done with CGI but having native libraries to handle this would be a big win. Make the perl glue libs readily available to the user with a standard mod_perl install. I think that may be more difficult than it sound at first - currently, neither version of mod_perl depends on anything outside of core httpd for its API to function, so if apreq weren't part of httpd core it might be more complex. but I think discussions like this are secondary and belong as part of the normal development chatter. the real issue here is whether the parts of apreq are better served by two distinct communities - httpd for the base C module and mod_perl for the perl glue. and the more I think about it the more this really makes sense and would be very healthy for the project, communities, and users alike. There does seem to be consensus for this split for the C side to go into httpd. Is there some fundamental objection from somewhere opposing this? At one point in the past it was suggested, as an argument to get apreq into the core httpd, to have mod_autoindex use apreq to parse the query string; would it be useful to demonstrate this to push for apreq's inclusion? On the Perl side, one thing that we may wish to consider is splitting the APR::* modules that just rely on the apr libs from mod_perl into their own distribution. As well as making these modules potentially more useful in a wider context, this would also allow the perl glue of apreq to be built for use just in a cgi environment, without the need for a full mod_perl installation. -- best regards, Randy
Re: 2.07-rc4 available for testing
On Thu, 2 Feb 2006, Joe Schaefer wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~joes/libapreq2-2.07-rc4.tar.gz Sorry for the delay ... This builds and tests successfully, including the perl glue, on both: - Win32 (ActivePerl 815), with Apache/2.0.55 (winnt) - linux (perl-5.8.7), with Apache/2.0.54 (prefork). Nice work! -- best regards, Randy
Re: towards a 2.07 release
On Tue, 8 Nov 2005, Joe Schaefer wrote: [ ... ] What's the consensus of the group on this issue? Introducing another prereq, possibly on CPAN itself, seems like a bad idea to me. I like the fact that the current build system is cpan- friendly, but I also appreciate the simplicity of having the build fail immediately on an unsatisfied prereq. So I don't know how to proceed at this point. We could either 1) leave things as-is, which allows the cpan client to sift through the generated Makefile in order to pursue unsatisfied prereqs, or 2) change back the "warn" calls to "die", which will confuse the cpan client, but will allow human users to figure out exactly what needs to be done in order for the build to continue. Opinions? There are good arguments for both ways, but if I were to choose, I'd go for leaving things as they are - I think, currently, one could install libapreq2 entirely through the CPAN/CPANPLUS shells, including installing any prerequisites (except for mod_perl, probably, as this can't easily be done through the CPAN/CPANPLUS shell). This feature might prove quite useful to many. The fact that the build process doesn't die for manual installations in cases of unsatisfied prerequisites is no different than the usual CPAN distribution, so users who do things manually should be used to catching the warnings about unsatisfied prerequisites and following them up by hand. -- best regards, randy
Re: 2.07-rc3 (was Re: 2.07-rc2)
On Sun, 16 Oct 2005, Joe Schaefer wrote: Ok, please test rc3 instead: http://people.apache.org/~joes/libapreq2-2.07-rc3.tar.gz Builds and passes all tests, including the perl glue, on - Win32 (ActivePerl 813: perl-5.8.7), mp 2.0.2 (rc2), Apache/2.0.54 (winnt) - linux (perl-5.8.7), mp 2.0.1, Apache/2.0.54 (prefork) There is a warning on Win32 at the perl Makefile.PL stage about an unitialized value being used for the --with-apache2-apxs option, if this is not specified; this has been fixed in the current svn sources. -- best regards, randy
Re: 2.07-rc2 (was Re: towards a 2.07 release)
On Sat, 15 Oct 2005, Ville Skytt� wrote: But I found a way to fix it; immediately after unpacking the tarball, "rm glue/perl/pm_to_blib" and then proceeding as usual fixes it for me. I wonder why that file is shipped in the tarball (and the top-level MANIFEST) in the first place? It was not in 2.06-dev. Nice catch! You're right about removing the pm_to_blib fixing the problem; it was probably just a stray that got picked up when making the distribution, and normally shouldn't be included. -- best regards, randy
Re: 2.07-rc2 (was Re: towards a 2.07 release)
On Fri, 14 Oct 2005, Ville Skytt� wrote: On Fri, 2005-10-14 at 00:40 -0500, Randy Kobes wrote: On Thu, 13 Oct 2005, Ville Skytt wrote: On Thu, 2005-10-13 at 13:06 -0400, Joe Schaefer wrote: Note this is our second non-dev candidate, so please give it the extra scrutiny it deserves. Release Candidate #2 - None of the Apache2/*.pm files get installed with 2.07-rc2 here, but the Apache2::*.3 man pages do. In 2.06-dev, all the *.pm (and man pages) were installed as expected. I also find that - I think the following should fix this: [...] +PMLIBDIRS => ['lib'], Unfortunately it doesn't seem to, the problem persists and I didn't notice the above changing anything. It works for me in installing the Apache2::* modules. You might have to do a make clean; first, and then rerun make; so that the changed Makefile.PL will regenerate the new Makefile. If this still doesn't work, do the Apache2::* modules appear beneath glue/perl/blib/? -- best regards, randy
Re: 2.07-rc2 (was Re: towards a 2.07 release)
On Thu, 13 Oct 2005, Joe Schaefer wrote: Note this is our second non-dev candidate, so please give it the extra scrutiny it deserves. Release Candidate #2 - http://people.apache.org/~joes/libapreq2-2.07-rc2.tar.gz Thanks! There seems to be a problem (reported in another thread by Ville Skytta) with the perl glue, in that the Apache2::* modules don't get copied over to blib, and subsequently won't get installed. Also, there's a minor annoyance on Win32 with a warning about a non-existent configuration option in the top-level Makefile.PL - I'll fix this as soon as the svn server gets back up. However, all tests, including those of the perl glue, passed for me: - linux: Apache/2.0.54 (prefork), perl-5.8.7, mod_perl 2.0.1 - win32: Apache/2.0.54 (winnt), perl-5.8.7 (ActivePerl 813), (RC2 of mod_perl 2.0.2) -- best regards, randy
Re: 2.07-rc2 (was Re: towards a 2.07 release)
On Thu, 13 Oct 2005, Ville Skytt� wrote:
On Thu, 2005-10-13 at 13:06 -0400, Joe Schaefer wrote:
Note this is our second non-dev candidate, so please give it the
extra scrutiny it deserves. Release Candidate #2 -
None of the Apache2/*.pm files get installed with 2.07-rc2 here, but the
Apache2::*.3 man pages do. In 2.06-dev, all the *.pm (and man pages)
were installed as expected.
I also find that - I think the following should fix this:
=
--- glue/perl/Makefile.PL~ 2005-10-14 00:25:15.0 -0500
+++ glue/perl/Makefile.PL 2005-10-14 00:29:46.0 -0500
@@ -162,6 +162,7 @@
my %opts = (
NAME => 'libapreq2',
DIR => [qw(xs)],
+PMLIBDIRS => ['lib'],
clean => { FILES => "xs t/logs t/TEST @scripts" },
realclean => { FILES => "xsbuilder/tables" },
);
=========
--
best regards,
randy kobes
Re: towards a 2.07 release
On Wed, 5 Oct 2005, Steve Hay wrote: Joe Schaefer wrote: [ ... ] IMO submit a tested patch to libapreq's Param.xs that does this (where MY_PLATFORM is suitably defined to match the above): #ifdef MY_PLATFORM #undef PerlLIO_link #define PerlLIO_link(oldname, newname) win32_link(oldname, newname) #endif OK, patch attached does exactly that. With this patch in place libapreq2-2.07-rc1 now builds without error, and all tests pass too. (This is using perl-5.8.7, apache-2.0.54 and mod_perl-2.0.1 on WinXP with VC++ 6.) Thanks, Steve! Applied to apreq as 306508. -- best regards, randy
Re: towards a 2.07 release
On Mon, 3 Oct 2005, Philip M. Gollucci wrote: Randy Kobes wrote: On Sun, 2 Oct 2005, Joe Schaefer wrote: Note this is our first non-dev candidate, so please give it the extra scrutiny it deserves. Release Candidate #1 - http://people.apache.org/~joes/libapreq2-2.07-rc1.tar.gz Thanks! Nice work, Joe! All tests, including those of the perl glue, pass for me on linux: Apache/2.0.54 prefork, perl-5.8.7, mp 2.0.1 Win32: Apache/2.0.54 winnt, perl-5.8.7, mp 2.0.1 It may be worth while to wait a couple days. I'm going to release the first mod_perl-2.0.2-RC1 tonight. Or we should test against SVN (to be 2.0.2) Regarding the mp-2.0.2-RC1 (and assuming an Apache-Test rc), did you see a patch I proposed for Apache-Test yesterday (to the test-dev list)? It would be nice if this, or some variant, went in the Apache-Test rc, as without it, Apache-Test doesn't get the right system config file under some circumstances. -- best regards, randy
Re: towards a 2.07 release
On Sun, 2 Oct 2005, Joe Schaefer wrote: Note this is our first non-dev candidate, so please give it the extra scrutiny it deserves. Release Candidate #1 - http://people.apache.org/~joes/libapreq2-2.07-rc1.tar.gz Thanks! Nice work, Joe! All tests, including those of the perl glue, pass for me on linux: Apache/2.0.54 prefork, perl-5.8.7, mp 2.0.1 Win32: Apache/2.0.54 winnt, perl-5.8.7, mp 2.0.1 -- best regards, randy
Re: thaw() isn't a class method
On Thu, 29 Sep 2005, Philip M. Gollucci wrote: Joe Schaefer wrote: I didn't intend for APR::Request::Cookie::thaw() to be a class method, but somehow I documented it that way. Any objections to my applying this patch? +1 +1 -- best regards, randy
Re: [PATCH] Win32 doesn't have link()
On Thu, 8 Sep 2005, Steve Hay wrote: The attached patch, or something similar, is required to build the current svn version of libapreq2 on Win32. PerlLIO_link() is mapped to link(), which the Win32 CRT doesn't have. I will look at changing PerlLIO_link() to map it to win32_link() on Win32 in future versions of Perl (win32_link() is exported from the perl library, and implements hard links on NTFS), so some further version-checking trickery could be required later, but just falling back to a copy is probably the best thing to do for now. Thanks, Steve - I'll apply that. Might you know why, though, I didn't see a problem with my Win32 builds, either perl-5.8.0 or perl-5.8.7 (both ActiveState compatible). I'm on XP, if that makes any difference. Btw, are the build instructions in need of an update? The INSTALL document refers to a "mod_apreq" target for Win32 builds, but the Makefile doesn't contain any such target. You're right - I'll do that. Thanks again. -- best regards, randy
Re: Loading Apache2::Request under CGI on Win32
On Mon, 15 Aug 2005, Nikolay Ananiev wrote:
[ ... ]
The problem appears when libapreq2.dll and mod_apreq2.so are not in
$ENV{PATH}.
When eval{require Apache2::Request} is executed, on the desktop appears a
message saying that libapreq2.dll could not be found in the path.
This would hold the perl process until the administrator hits OK.
Is there any way to prevent this message from showing up?
Or maybe there should be a warning while installing apreq2
that in order to use Apache2::Request under CGI,
libapreq2.dll and mod_apreq2.so must be in the PATH?
For the libapreq2 ppm package in our repository:
http://theoryx5.uwinnipeg.ca/ppms/
I've added a message along these lines to the post-install
script that fetches and installs libapreq2.dll and
mod_apreq2.so (technically, in order to use these under
Apache, you don't need to put either in the PATH, as they
can be included via directives in httpd.conf).
I know I can just add the missing paths to the
environment, but I'm going to sell my application and I'd
like to prevent the problems that may appear on my
clients' servers.
If you have control over where the users install libapreq2,
you could have libapreq2.dll installed into some location in
the system PATH (eg, $ENV{SystemRoot}), and then try
APR::Request (which doesn't require mod_apreq2.so).
Permissions and/or system policy may prevent this option,
however.
If you have control over the installation of mod_perl,
you might consider editing Apache2::BuildConfig to
reflect the location of the installed Apache2 binary
(I thought about doing this for the mod_perl ppm
package in our repository, but decided not to, in
case something went wrong). What might be safer is to
use something like the code in install_libapreq2 in
http://theoryx5.uwinnipeg.ca/ppms/scripts/
to guess at the location of the installed Apache2; I
think this handles most of the common installation
locations.
Alternatively, if you know the installation of Apache
involves adding any Registry settings, you could get
at that information there.
Another approach is just to look for a *file*, for example,
Apache2/Request.pm, in @INC, and if it's there, assume
Apache2::Request is available. This of course has the
disadvantage that it doesn't check if it's a working
installation.
--
best regards,
randy
Re: Loading Apache2::Request under CGI on Win32
On Tue, 16 Aug 2005, Nikolay Ananiev wrote:
"Randy Kobes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On Mon, 15 Aug 2005, Nikolay Ananiev wrote:
Hello,
I'd like my application to do the following:
if(eval{require Apache2::Request}) {
use_apreq();
} else {
use_cgi_pm();
}
This works with mod_perl on Win32, but has problems under CGI (again on
Win32).
The problem appears when libapreq2.dll and mod_apreq2.so
are not in $ENV{PATH}.
When eval{require Apache2::Request} is executed, on the
desktop appears a message saying that libapreq2.dll could
not be found in the path. This would hold the perl process
until the administrator hits OK. Is there any way to
prevent this message from showing up? Or maybe there
should be a warning while installing apreq2 that in order
to use Apache2::Request under CGI, libapreq2.dll and
mod_apreq2.so must be in the PATH?
I know I can just add the missing paths to the
environment, but I'm going to sell my application and I'd
like to prevent the problems that may appear on my
clients' servers.
I've seen this problem too - what you might try is
testing for the presence of APR::Request instead.
This won't help me prevent the problem.
I missed that you were also missing libapreq2.dll in the
PATH - sorry about that. Testing for APR::Request only needs
libapreq2.dll (not mod_apreq2.so) in the PATH (and
potentially also the Apache apr dlls, which typically are in
the same directory as libapreq2.dll).
BTW, is there an equivalent of GNU ld's -rpath option for
the win32 linker? If there is, it will be easy to fix this
problem.
I'm not aware of one.
--
best regards,
randy
Re: Loading Apache2::Request under CGI on Win32
On Mon, 15 Aug 2005, Nikolay Ananiev wrote:
Hello,
I'd like my application to do the following:
if(eval{require Apache2::Request}) {
use_apreq();
} else {
use_cgi_pm();
}
This works with mod_perl on Win32, but has problems under CGI (again on
Win32).
The problem appears when libapreq2.dll and mod_apreq2.so
are not in $ENV{PATH}.
When eval{require Apache2::Request} is executed, on the
desktop appears a message saying that libapreq2.dll could
not be found in the path. This would hold the perl process
until the administrator hits OK. Is there any way to
prevent this message from showing up? Or maybe there
should be a warning while installing apreq2 that in order
to use Apache2::Request under CGI, libapreq2.dll and
mod_apreq2.so must be in the PATH?
I know I can just add the missing paths to the
environment, but I'm going to sell my application and I'd
like to prevent the problems that may appear on my
clients' servers.
I've seen this problem too - what you might try is
testing for the presence of APR::Request instead.
--
best regards,
randy kobes
Re: [APREQ1] Compile error on Win32
On Sun, 31 Jul 2005, Nikolay Ananiev wrote: "Randy Kobes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Sun, 31 Jul 2005, Nikolay Ananiev wrote: "Randy Kobes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [ ... ] Did you build mod_perl (and Perl) on your own? VC++ 7 (the .NET framework), which you're using, has some incompatibilities, in principle, with VC++ 6, which is what ActivePerl is compiled with. Yes, I've built MP on my own. Did you also build Perl using VC++ 7? Or are you using ActivePerl? The problem with using ActivePerl (which is built with VC++ 6) and compiling extensions with VC++ 7 is that the two versions use different C runtime libraries. These are responsible for I/O and for memory allocation/deallocation, so one can run into trouble, eg, if one runtime lib (from an extension built with VC++ 7) allocates a chunk of memory and a different runtime lib (from Perl, built with VC++ 6) tries to deallocate it; it may try to dellocate a the wrong block of memory. Perl is the standard ActivePerl binary from ActiveStates. Thanks for the help, Randy. Unfortunately, I don't have access to VC++ 7 at the moment, so I can't say for sure that this is the problem (I did verify that compiling libapreq using VC++ 6 with ActivePerl passes all the tests). So you might try compiling Perl with VC++ 7 - it should compile OK. Let us know if this helps. -- best regards, randy
Re: [APREQ1] Compile error on Win32
On Sun, 31 Jul 2005, Nikolay Ananiev wrote: "Randy Kobes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [ ... ] Did you build mod_perl (and Perl) on your own? VC++ 7 (the .NET framework), which you're using, has some incompatibilities, in principle, with VC++ 6, which is what ActivePerl is compiled with. Yes, I've built MP on my own. Did you also build Perl using VC++ 7? Or are you using ActivePerl? The problem with using ActivePerl (which is built with VC++ 6) and compiling extensions with VC++ 7 is that the two versions use different C runtime libraries. These are responsible for I/O and for memory allocation/deallocation, so one can run into trouble, eg, if one runtime lib (from an extension built with VC++ 7) allocates a chunk of memory and a different runtime lib (from Perl, built with VC++ 6) tries to deallocate it; it may try to dellocate a the wrong block of memory. -- best regards, randy
Re: [APREQ1] Compile error on Win32
On Sun, 31 Jul 2005, Nikolay Ananiev wrote: Compiles without problems but apreq/request.t segfaults The error_log is empty E:\Downloads\httpd-apreq>E:\Sites\Perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -verbose apreq/request.t e:/sites/servers/apache/apache.exe -d E:/Downloads/httpd-apreq/t -f E:/Download s/httpd-apreq/t/conf/httpd.conf -D APACHE1 -D PERL_USEITHREADS using Apache/1.3.33 waiting 60 seconds for server to start: .WARNING: StartServers has no effect on Win32 waiting 60 seconds for server to start: ok (waited 0 secs) server ananiev.discussion-works.com:8529 started Apache/1.3.33 (Win32) mod_perl/1.29_01-dev running... t\apreq\request1..2 # Running under perl version 5.008007 for MSWin32 # Win32::BuildNumber 813 # Current time local: Sun Jul 31 00:15:28 2005 # Current time GMT: Sat Jul 30 21:15:28 2005 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.27 # testing : basic param # expected: 42.5 # received: 42.5 ok 1 # Failed test 2 in t\apreq\request.t at line 26 # testing : basic upload # expected: data upload # received: 500 Unknown error not ok 2 FAILED test 2 Failed 1/2 tests, 50.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t\apreq\request.t21 50.00% 2 Failed 1/1 test scripts, 0.00% okay. 1/2 subtests failed, 50.00% okay. [ error] error running tests (please examine t\logs\error_log) Did you build mod_perl (and Perl) on your own? VC++ 7 (the .NET framework), which you're using, has some incompatibilities, in principle, with VC++ 6, which is what ActivePerl is compiled with. -- best regards, randy
Re: [APREQ1] Compile error on Win32
On Tue, 12 Jul 2005, Nikolay Ananiev wrote:
The latest svn of apreq 1.33 fails to compile on win32
ActivePerl 5.8.7, VisualStudio .NET, Apache 1.33
[ .. ]
I'm not sure what's been changed with the most recent
ActivePerl, but try the following patch:
=
Index: Makefile.PL
===
--- Makefile.PL (revision 226567)
+++ Makefile.PL (working copy)
@@ -106,6 +106,7 @@
VERSION => $myVERSION,
DIR => [qw(c Request Cookie)],
PREREQ_PM => \%require,
+DEFINE=> '-D_INC_MALLOC -D_INC_SIGNAL',
clean => {
FILES => "@{ clean_files() }",
},
======
--
best regards,
randy kobes
Re: PAUSE indexer report JOESUF/libapreq2-2.06-dev.tar.gz
On Wed, 20 Jul 2005, Ville [ISO-8859-1] Skytt� wrote:
> On Wed, 2005-07-20 at 14:20 -0400, Joe Schaefer wrote:
> > The indexer completely ignored META.yml again.
> > It looks like it can't parse the file; does
> > anyone see what's wrong with it?
>
> Dunno about "wrong", I'm not that familiar with YAML, but the stuff
> after "#YAML:1.0" trips ysh from YAML-0.39:
>
> $ ysh < META.yml
> --- !perl/YAML::Error
> code: YAML_PARSE_ERR_INCONSISTENT_INDENTATION
> [...]
>
> The attached patch should generate a META.yml that appeases ysh, and
> maybe the CPAN indexer.
I'm not completely sure either, but another change that
seems to work (if one wanted to keep the comment in) is
to use the following:
===
Index: build/version_check.pl
===
--- build/version_check.pl (revision 219681)
+++ build/version_check.pl (working copy)
@@ -149,7 +149,7 @@
if ($opts{version}) { # generate META.yml file content
print
Re: [VOTE] libapreq2-2.06-dev #5
On Tue, 19 Jul 2005, Joe Schaefer wrote: > Randy Kobes <[EMAIL PROTECTED]> writes: > > > On Tue, 19 Jul 2005, Joe Schaefer wrote: > >> > >> This is candidate #5, and hopefully the last. > >> Please test & vote for tomorrow's release of: > >> > >> http://people.apache.org/~joes/libapreq2-2.06-dev.tar.gz > >> > >> The pgp signature is also available: > >> > >> http://people.apache.org/~joes/libapreq2-2.06-dev.tar.gz.asc > > > > +1; tested on Win32 (perl-5.8.7) with Apache/2.0.54. > > > > By the way, I tried verifying the signature: > > > > gpg: WARNING: using insecure memory! > > gpg: please see http://www.gnupg.org/faq.html for more information > > gpg: Signature made Tue 19 Jul 2005 09:25:49 PM CDT using DSA key ID > > F8B0462F > > gpg: Good signature from "Joe Schaefer <[EMAIL PROTECTED]>" > > gpg: aka "Joe Schaefer <[EMAIL PROTECTED]>" > > gpg: Note: This key has expired! > > Primary key fingerprint: 984F B335 0C1D 5C7A 3282 255B B31B 213D 208F 5064 > > Subkey fingerprint: 8BD8 88D6 46A5 7ACC ED82 E32E 366D 6916 F8B0 462F > > > > which says the key has expired. I got the key from > >http://www.apache.org/dist/httpd/KEYS > > Is there a more recent one? > > How long ago? I updated KEYS earlier today. > My new key (really the same key, but the expiration > date has changed) should be in there now. Otherwise > grab it from > > http://people.apache.org/~joes/newkey I imported KEYS just before I sent that message, but perhaps the change hadn't propagated yet. In any case, ~joes/newkey works in verifying the signature- thanks! -- best regards, randy
Re: [VOTE] libapreq2-2.06-dev #5
On Tue, 19 Jul 2005, Joe Schaefer wrote: > > This is candidate #5, and hopefully the last. > Please test & vote for tomorrow's release of: > > http://people.apache.org/~joes/libapreq2-2.06-dev.tar.gz > > The pgp signature is also available: > > http://people.apache.org/~joes/libapreq2-2.06-dev.tar.gz.asc > +1; tested on Win32 (perl-5.8.7) with Apache/2.0.54. By the way, I tried verifying the signature: gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Tue 19 Jul 2005 09:25:49 PM CDT using DSA key ID F8B0462F gpg: Good signature from "Joe Schaefer <[EMAIL PROTECTED]>" gpg: aka "Joe Schaefer <[EMAIL PROTECTED]>" gpg: Note: This key has expired! Primary key fingerprint: 984F B335 0C1D 5C7A 3282 255B B31B 213D 208F 5064 Subkey fingerprint: 8BD8 88D6 46A5 7ACC ED82 E32E 366D 6916 F8B0 462F which says the key has expired. I got the key from http://www.apache.org/dist/httpd/KEYS Is there a more recent one? -- best regards, randy
Re: [VOTE] libapreq2-2.06-dev-rc4
On Tue, 19 Jul 2005, Joe Schaefer wrote: > > Please test & vote on rc4 for tomorrow's release of: > > http://people.apache.org/~joes/libapreq2-2.06-dev-rc4.tar.gz > > The pgp signature is also available: > > http://people.apache.org/~joes/libapreq2-2.06-dev-rc4.tar.gz.asc I don't think the commit I made today for library/t/at.h, changing the printing of AT_skip() from "not ok" to "ok", made it into the above. Or perhaps the above link is to an earlier tarball? -- best regards, randy
AT_skip
With the current apreq2 svn sources, I'm finding a problem with the first 3 tests of library/t/parsers.c on Win32, which use AT_skip() to skip them. The tests run, and AT_skip() is invoked, but then these tests are reported as failed. What's puzzling is that this worked before, but I've since upgraded my system to Perl-5.8.7, so I think it's something to do with the upgrade. I'm wondering though about AT_skip(), which is defined within library/t/at.h to print out "not ok %d - %s (%d) #skipped: %s (%s:%d)" However, skip() within Perl's Test.pm does my $ok = "ok $ntest # skip"; $ok .= " $whyskip" if length $whyskip; $ok .= "\n"; print $TESTOUT $ok; Should AT_skip() print "ok ...", rather than "not ok ..."? If I change this to do so, then the tests are reported as all pass; however, the message that these tests have been skipped aren't seen. Apart from the above, all tests on Win32 pass. -- best regards, randy
Re: 2.06-dev-rc2 (was Re: 2.0.6-dev [docs preview])
On Wed, 13 Jul 2005, Philip M. Gollucci wrote: > Randy Kobes wrote: > > Any chance of using cp of ExtUtils::Command, to be > > even more portable? > > While a good idea and more portable, I don't think so > because you don't neccessarily have to have perl > installed. You could be building without the PERL glue > code. Sorry about that - I must have misread the context of the patch, as I thought it was in the same section as the pod2html stuff, which would mean perl was available. -- best regards, randy
Re: 2.06-dev-rc2 (was Re: 2.0.6-dev [docs preview])
On Wed, 13 Jul 2005, Philip M. Gollucci wrote: > With the attached patch > gmake docs docs_install > actually make it all the way through. > > Note the addition of feather.gif (attached) > > It does: >Replace cp -a with cp -R b/c cp -a is not portable, [ .. ] Any chance of using cp of ExtUtils::Command, to be even more portable? -- best regards, randy
Re: Please test 2.06-dev-rc1
On Fri, 8 Jul 2005, Joe Schaefer wrote: > > Fresh roll of trunk (and backing off the stable release > plan for 2.06): > > http://people.apache.org/~joes/libapreq2-2.06-dev-rc1.tar.gz > > Please test and report back. I'm away from my Windows machine for a week - if there's any other Win32 users able to test this, that'd be great. I tested this about 10 days ago on Windows, and it was OK. -- best regards, randy
Re: expat install libapreq2-2.0.5-dev
On Mon, 23 May 2005, Philip M. Gollucci wrote: > Marc Lambrichs wrote: [ ... ] > > But wait, there's more. > > In file included from Apache2.xs:39 > > /home/mlambrichs/libapreq2-2.05-dev/glue/perl/xsbuilder/apreq_xs_postperl.h:21:34: > > modperl_unembed.h: No such file or directory > > > > Somehow I'm under the impression that the Makefile isn't fit for my > > system. That's strange - glue/perl/xsbuilder/apreq_xs_postperl.h of my copy is including modperl_perl_unembed.h, not modperl_unembed.h. Was this a cut-n-paste error, or is it really trying to include modperl_unembed.h? Also, do you have modperl_perl_unembed.h under your Apache2 include/ subdirectory? It should get installed there upon installing mod_perl-2. -- best regards, randy kobes
Re: Massive leak in Apache2::Upload?
On Thu, 19 May 2005, Joe Schaefer wrote: > Ville Skyttä <[EMAIL PROTECTED]> writes: > > > $r->discard_request_body() fixes it here too. > > Ok, here's what I'd like you (or Markus) to do. > > 1) grab our svn trunk and apply the attached patch to it. > 2) make clean; make > 3) cd module; make test > 4) ls -l /tmp > > When the tests finish, they should leave three temporary files > in /tmp: > >% ls -l /tmp >total 1493 >-rw--- 1 joe joe 500024 May 19 22:32 apreqStetos >-rw--- 1 joe joe 500039 May 19 22:32 apreqT5oOq1 >-rw--- 1 joe joe 500039 May 19 22:32 apreqs16lOA > > > We need to figure out which side the leak is happening on (writing > to the spool file or reading from it). The presence/absense of these > files on your box should help us make that determination, so let us > know what you see. On Win32, I get those 3 files in the analagous /tmp, with the same sizes. -- best regards, randy
PAUSE indexer problems
Regarding the TODO item in STATUS: - Sadly, the PAUSE indexer still doesn't speak META.yml. We need to find a way to get the APR::Request* packages indexed (with proper version numbers), and prevent the indexer from inspecting the supporting modules in */t, and glue/perl/xsbuilder/tables. I think the problem with not recognizing the APR::Request* packages is that the .pm files found under glue/perl/xsbuilder/APR/Request are skeletons, and hence don't contain a 'package' declaration, which I believe the PAUSE indexer looks for when parsing a file. What might work is supplying, like mod_perl-2 does, a APR::Request::DummyVersions module that just contains package APR::Request $APR::Request::VERSION = xxx package APR::Request::CGI $APR::Request::CGI::VERSION = xxx etc. As for getting PAUSE to ignore packages, I think adding = no_index: file: - whatever/file.pm - whatever/file2.pm package: - another::package - another::package2 to META.yml would work. I could work on adding these two things, if desired. -- best regards, randy
Re: svn commit: r170286 - in /httpd/apreq/trunk/glue/perl/xsbuilder: APR/Request/Cookie/APR__Request__Cookie.h APR/Request/Cookie/Cookie.xs maps/apreq_structures.map
On Mon, 16 May 2005 [EMAIL PROTECTED] wrote: > Author: joes > Date: Sun May 15 17:18:19 2005 > New Revision: 170286 > > URL: http://svn.apache.org/viewcvs?rev=170286&view=rev > Log: > Fix the domain/path bug. The problem is that EU::XSB generates > unsafe glue for char * attributes. We need to make a pool copy > of the SV when setting domain/path; you can't just do a pointer > assignment here. Nice catch! I was looking at this some this weekend; that's a subtle bug ... -- best regards, randy
Re: Ready to go?
- Original Message - From: "Jim Winstead" <[EMAIL PROTECTED]> To: "Matt Sergeant" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Randy Kobes" <[EMAIL PROTECTED]> Sent: Friday, February 02, 2001 3:26 PM Subject: Re: Ready to go? > On Thu, Feb 01, 2001 at 09:03:04AM +, Matt Sergeant wrote: > > Is the libapreq release ready to go now mod_perl 1.25 is out? > > i put an updated snapshot of libapreq from cvs at > http://www.apache.org/~jimw/httpd-apreq-20010202.tar.gz. if i could > get a few people to double-check that it compiles for them with 1.25 > (particularly under win32), i'll go ahead and put out 0.32. > > jim Hi, On Win32 the attached patch is needed to get rid of some warnings and fatal errors concerning certain symbols ... There's also a problem with an unresolved external symbol _PerlIO_importFILE with ActivePerl 6xx, but not with another Win32 perl I have that was compiled without fork emulation. The difference seems to be the presence of PERL_IMPLICIT_SYS - if I put into Request/Request.xs the line #undef PERL_IMPLICIT_SYS then it compiles fine on ActivePerl. Workarounds might be to put something like the following at the top of Request/Request.xs: #ifdef WIN32 #ifdef PERL_IMPLICIT_SYS #undef PERL_IMPLICIT_SYS #endif #endif However, I'm not sure if this is the right way, or even if it's only a problem with Win32 Another way might be to define PerlIO_importFILE, if it's not defined, as is done in Request/Request.xs at line 97 for when PerlIO is not defined. Finally, since when I last looked at it, an additional symbol from the mod_perl lib is required. For this, one must add, in the mod_perl sources, the line hvrv2table at the end of src/modules/win32/mod_perl.def to get this included in the mod_perl lib. With these changes, the request and cookie tests of mod_perl pass (mod_perl-1.25 and apache_1.3.17, on ActivePerl 620). best regards, randy ap.patch Description: Binary data
