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 "Philip M. Gollucci" <pg...@p6m7g8.com> on 2006/07/20 08:16:06 UTC
[RELEASE CANDIDATE] libapreq2 2.08-RC4
Please download, test, and VOTE on the following
candidate tarball:
http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC4.tar.gz
Changes from RC3:
http://svn.apache.org/viewvc?rev=423429&view=rev
http://svn.apache.org/viewvc?rev=423439&view=rev
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Radoslaw Zielinski <ra...@pld-linux.org>.
Philip M. Gollucci <pg...@p6m7g8.com> [20-07-2006 07:17]:
> autotools set 3: ac - 2.60, am: 1.9.6, lt: 1.5.22 (latest stable releases)
> (autconf 2.60 does not work: gcc Apache2.c breaks ?????)
glue/perl/Makefile.PL messes with autoconf internals, reading
config.status and trying to read PACKAGE_VERSION (among other variables)
from there. For some reason, "|#_!!_#|" is prepended there. Then, gcc
is called with -DVERSION=\"|#_!!_#|2.08\" -- pipes and exclamation marks
(and probably hashes) are interpreted by shell.
Similar issue has been discussed on the bug-autoconf list:
http://lists.gnu.org/archive/html/bug-autoconf/2006-06/msg00127.html
--
Radosław Zieliński <ra...@pld-linux.org>
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Please download, test, and VOTE on the following
> candidate tarball:
>
> http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC4.tar.gz
>
> Changes from RC3:
> http://svn.apache.org/viewvc?rev=423429&view=rev
> http://svn.apache.org/viewvc?rev=423439&view=rev
+1
FreeBSD i386
perl 5.8.8 with and without ithreads
httpd 2.2.2 w/ mpms: prefork, prefork_threaded, worker, event
modperl 2.0.2 and svn trunk
gcc 3.4.4 and 4.2 (prerelease 20060715)
autotools set 1: ac - 2.53, am: 1.6.1, lt: 1.4.3 (mins)
autotools set 2: ac - 2.59, am: 1.9.6, lt: 1.5.22 (ports tree)
autotools set 3: ac - 2.60, am: 1.9.6, lt: 1.5.22 (latest stable releases)
(autconf 2.60 does not work: gcc Apache2.c breaks ?????)
built with:
tar (GNU tar) 1.15.1 (ports)
untarred with:
bsdtar(base system) and gtar(ports)
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Please download, test, and VOTE on the following
> candidate tarball:
>
> http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC4.tar.gz
>
> Changes from RC3:
> http://svn.apache.org/viewvc?rev=423429&view=rev
> http://svn.apache.org/viewvc?rev=423439&view=rev
+1
FreeBSD i386
perl 5.8.8 with and without ithreads
httpd 2.2.2 w/ mpms: prefork, prefork_threaded, worker, event
modperl 2.0.2 and svn trunk
gcc 3.4.4 and 4.2 (prerelease 20060715)
autotools set 1: ac - 2.53, am: 1.6.1, lt: 1.4.3 (mins)
autotools set 2: ac - 2.59, am: 1.9.6, lt: 1.5.22 (ports tree)
autotools set 3: ac - 2.60, am: 1.9.6, lt: 1.5.22 (latest stable releases)
(autconf 2.60 does not work: gcc Apache2.c breaks ?????)
built with:
tar (GNU tar) 1.15.1 (ports)
untarred with:
bsdtar(base system) and gtar(ports)
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
> 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.
No objection here :)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
> 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?
[...]
>
> 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).
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?
Is the change safe, or does it introduce any security issues with
temporary spool files being shared somehow?
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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-RC4
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
> On Mon, 24 Jul 2006, Steve Hay wrote:
>
>> Sorry, but I'm still seeing quite a few failures. I started with a
>> completely fresh build (with your patch applied) and the top-level
>> "nmake test" failed a bunch of upload.t tests first time. (So it's
>> not just running the test multiple times that causes the problem.)
>> I then cd'd to perl/glue and ran just the upload.t test a dozen times
>> over and it still failed 2 or 3 times.
>
> Sigh :) ... One thing I tried (that didn't make a difference
> for me, but might for you) is in the call to
> apr_pool_cleanup_register( ...) on about line 829 of
> library/util.c, change the last arguments
> apreq_file_cleanup, apreq_file_cleanup
> to
> apreq_file_cleanup, apr_pool_cleanup_null
> Does that change anything? The cleanup in apr_file_open
> uses this latter form.
Makes no difference for me either. I tried it with and without your
previous APR_FILE_NOCLEANUP change, but I still see failures either way.
>
> 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.
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 24 Jul 2006, Steve Hay wrote:
> Sorry, but I'm still seeing quite a few failures. I started with a
> completely fresh build (with your patch applied) and the top-level "nmake
> test" failed a bunch of upload.t tests first time. (So it's not just running
> the test multiple times that causes the problem.)
> I then cd'd to perl/glue and ran just the upload.t test a dozen times over
> and it still failed 2 or 3 times.
Sigh :) ... One thing I tried (that didn't make a difference
for me, but might for you) is in the call to
apr_pool_cleanup_register( ...) on about line 829 of
library/util.c, change the last arguments
apreq_file_cleanup, apreq_file_cleanup
to
apreq_file_cleanup, apr_pool_cleanup_null
Does that change anything? The cleanup in apr_file_open
uses this latter form.
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?
--
best regards,
Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Steve Hay <st...@uk.radan.com>.
Philip M. Gollucci wrote:
> Steve Hay wrote:
>> Sorry, but I'm still seeing quite a few failures. I started with a
>> completely fresh build (with your patch applied) and the top-level
>> "nmake test" failed a bunch of upload.t tests first time. (So it's not
>> just running the test multiple times that causes the problem.)
>>
>> I then cd'd to perl/glue and ran just the upload.t test a dozen times
>> over and it still failed 2 or 3 times.
> Is there an equivalent to 'strace' on 'that which you deem to call an OS' :)
>
> The 'open,access,stat*' might be useful ?
I have a Cygwin strace, but it doesn't seem to work trying to trace this.
I tried a couple of freeware strace's that I found via Google too, but
they were pretty crappy and I couldn't get anything useful out of them
either.
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Steve Hay wrote:
> Sorry, but I'm still seeing quite a few failures. I started with a
> completely fresh build (with your patch applied) and the top-level
> "nmake test" failed a bunch of upload.t tests first time. (So it's not
> just running the test multiple times that causes the problem.)
>
> I then cd'd to perl/glue and ran just the upload.t test a dozen times
> over and it still failed 2 or 3 times.
Is there an equivalent to 'strace' on 'that which you deem to call an OS' :)
The 'open,access,stat*' might be useful ?
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
> But I think you're on the right track, in that the
> problem with the temp files sticking around (and
> apparently causing the occasional errors when the
> upload.t test is run multiple times) comes from the
> cleanup set by apr_file_open. I tried this patch:
>
[...]
>
> which seems to help - when the upload.t test is run
> multiple times, I get far fewer temp files left over
> (although the occasional ones do stick around), and
> even when they are there, I haven't seen any failures
> yet. Steve, does this help you?
Sorry, but I'm still seeing quite a few failures. I started with a
completely fresh build (with your patch applied) and the top-level
"nmake test" failed a bunch of upload.t tests first time. (So it's not
just running the test multiple times that causes the problem.)
I then cd'd to perl/glue and ran just the upload.t test a dozen times
over and it still failed 2 or 3 times.
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
> But I think you're on the right track, in that the
> problem with the temp files sticking around (and
> apparently causing the occasional errors when the
> upload.t test is run multiple times) comes from the
> cleanup set by apr_file_open. I tried this patch:
Still seems happy on FreeBSD(unix) land.
I'll wait for Steve to verify and you to commit then I guess onto RC5 (ugggg)
Stop me if there is another outstanding issue I've forgotten about :)
Thanks!
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 21 Jul 2006, Philip M. Gollucci wrote:
> Philip M. Gollucci wrote:
>> Philip M. Gollucci wrote:
>>> Randy Kobes wrote:
>> Which means
>> apr_pool_cleanup_register(pool, data,
>> apreq_file_cleanup, apreq_file_cleanup);
>>
> Contrary to the comment in library/util.c
> 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);
>
> rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE! see comment above */
> APR_CREATE | APR_READ | APR_WRITE
> | APR_EXCL | APR_BINARY, pool);
>
> Win32 doesn't have mktemp, so thats not *strictly* true.
I think that refers to the cleanup set by apr_file_mktemp,
which in turn comes from apr_file_open (on Win32).
> FYI,
> http://svn.apache.org/viewvc/apr/apr/trunk/file_io/unix/mktemp.c?r1=62405&r2=62404&pathrev=62405
>
> The cleanup on Win32 was removed from apr here... I'll bet that's it!
The explicit cleanup was removed there, but replaced by
APR_DELONCLOSE (set by default), which if set would
delete the file on close. But, as the comment explains,
can't be used here ...
But I think you're on the right track, in that the
problem with the temp files sticking around (and
apparently causing the occasional errors when the
upload.t test is run multiple times) comes from the
cleanup set by apr_file_open. I tried this patch:
======================================================
Index: util.c
===================================================================
--- util.c (revision 424771)
+++ 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);
@@ -828,11 +829,14 @@
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;
+ /* needed on Win32 to cleanup temp files */
+#ifdef WIN32
+ flag |= APR_FILE_NOCLEANUP;
+#endif
+ rc = apr_file_mktemp(fp, tmpl, flag, pool);
- rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE!
see comment above */
- APR_CREATE | APR_READ |
APR_WRITE
- | APR_EXCL | APR_BINARY, pool);
-
if (rc == APR_SUCCESS) {
apr_file_name_get(&data->fname, *fp);
data->pool = pool;
===============================================================
which seems to help - when the upload.t test is run
multiple times, I get far fewer temp files left over
(although the occasional ones do stick around), and
even when they are there, I haven't seen any failures
yet. Steve, does this help you?
--
best regards,
Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Philip M. Gollucci wrote:
>> Randy Kobes wrote:
> Which means
> apr_pool_cleanup_register(pool, data,
> apreq_file_cleanup, apreq_file_cleanup);
>
Contrary to the comment in library/util.c
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);
rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE! see comment above */
APR_CREATE | APR_READ | APR_WRITE
| APR_EXCL | APR_BINARY, pool);
Win32 doesn't have mktemp, so thats not *strictly* true.
FYI,
http://svn.apache.org/viewvc/apr/apr/trunk/file_io/unix/mktemp.c?r1=62405&r2=62404&pathrev=62405
The cleanup on Win32 was removed from apr here... I'll bet that's it!
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Randy Kobes wrote:
>> [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?
You are absolutely correct. I can force duplicate on FBSD.
I changed this (dropped the XXXX) so I could predict the temp file name
and yanked out all the tests not for tempname in t/apreq/upload.t
rc = apr_filepath_merge(&tmpl, path, "apreq",
APR_FILEPATH_NOTRELATIVE, pool);
touch /tmp/apreq
t/error_log
[Fri Jul 21 04:02:42 2006] [error] [client 127.0.0.1] $param->upload_tempname($req): can't make spool bucket at
/usr/home/pgollucci/dev/repos/asf/httpd/apreq/trunk/glue/perl/t/response/TestApReq/upload.pm line 33.
Which means
apr_pool_cleanup_register(pool, data,
apreq_file_cleanup, apreq_file_cleanup);
which calls apr_file_remove() which on Win32 is way out of my league :(
I'm guessing this is failing, but silently..... or less likely the cleanup is just not being run ?
Question, are you both ASCII or UNICODE ?
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Randy Kobes wrote:
> [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?
If I had to guess, I'd say this did it in 2.04-dev:
- C API [Markus Wichitill, randyk, joes]
Drop APR_DELONCLOSE from apreq_file_mktemp implementation and install
apreq_file_cleanup. When passed to apr_file_open on Win32, APR_DELONCLOSE
sets the FILE_SHARED_DELETE flag, which is, unfortunately, a property that
is preserved across NTFS "hard" links. This breaks apps that link()
the temp file to a permanent location, and subsequently expect to open it
without FILE_SHARED_DELETE before the original tempfile is closed+deleted.
In fact, even Apache::Upload does this, so it is a common enough event that
the apreq_file_cleanup workaround is necessary.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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-RC4
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
--
best regards,
Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Steve Hay <st...@uk.radan.com>.
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.
OK, that would definitely have made it fail several times here.
Let's hope Randy can find time to look at this sometime soon. If not
then I'll try and look at it eventually, but I don't know how far I'll
get with it myself.
I don't know if you'd want to hold up 2.08 for this or not. Problems
with uploading could potentially be quite significant so I don't think
it is ignorable, but I know you had a significant problem with 2.07 too...
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
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.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Steve Hay wrote:
> Philip M. Gollucci wrote:
>> Please download, test, and VOTE on the following
>> candidate tarball:
>>
>> http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC4.tar.gz
>
> I still have glue/perl/t/apreq/upload.t failing intermittently, but
> seems OK otherwise.
>
> Philip, you were going to try running something like:
>
> perl -Iblib/arch -Iblib/lib t/TEST -verbose=1 t/apreq/upload.t
>
Damn I completely forgot!!!!
Grumble...
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Steve Hay <st...@uk.radan.com>.
Philip M. Gollucci wrote:
> Please download, test, and VOTE on the following
> candidate tarball:
>
> http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC4.tar.gz
I still have glue/perl/t/apreq/upload.t failing intermittently, but
seems OK otherwise.
Philip, you were going to try running something like:
perl -Iblib/arch -Iblib/lib t/TEST -verbose=1 t/apreq/upload.t
repeatedly from the glue/perl sub-directory and see whether or not it
ever fails for you. Did you get round to trying that?
I know Randy said he'd seen this before, so it may be a Win32 thing, but
it's definitely not just me.
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting "Philip M. Gollucci" <pg...@p6m7g8.com>:
> Please download, test, and VOTE on the following
> candidate tarball:
>
> http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC4.tar.gz
The Fedora Extras package (development) will be available after signing.
--
Bojan