You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Andy McCarty <mc...@lom.med.va.gov> on 2003/06/21 09:17:19 UTC
compile 0.24.2 errors
Hello all,
I am having trouble trying to upgrade to 0.24.2.
I have a FreeBSD 4.7 box (I know I am
not the only BSD user here) that is
giving me fits.
I guess APR defualts to --disable-threads
on FreeBSD. Up until now this has been fine.
Trying to compile svn now I get this error
./subversion/bindings/swig/swigutil_py.c:52: #error The python
bindings require threads. APR was compiled without threads.
*** Error code 1
I can recompile APR --enable-threads and svn compiles
but apache complains on startup
Undefined symbol: apr_allocator_mutex_set
Can someone give me a hint on how to proceed?
Even RTFM pointers would be welcome at this point.
I finally got my python bindings working and mailer.py
setup with 0.23.0. I would hate to lose them in the upgrade.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: compile 0.24.2 errors
Posted by Robert Pluim <rp...@bigfoot.com>.
Andy McCarty writes:
>
> Hello all,
>
> I am having trouble trying to upgrade to 0.24.2.
> I have a FreeBSD 4.7 box (I know I am
> not the only BSD user here) that is
> giving me fits.
>
> I guess APR defualts to --disable-threads
> on FreeBSD. Up until now this has been fine.
> Trying to compile svn now I get this error
>
> ./subversion/bindings/swig/swigutil_py.c:52: #error The python
> bindings require threads. APR was compiled without threads.
> *** Error code 1
>
> I can recompile APR --enable-threads and svn compiles
> but apache complains on startup
>
> Undefined symbol: apr_allocator_mutex_set
>
> Can someone give me a hint on how to proceed?
> Even RTFM pointers would be welcome at this point.
>
Are you using the same apr for apache and svn? It looks like apache
is linking to a different copy of libapr than svn. Does 'ldd
/path/to/svn' show different paths for libapr than 'ldd
/path/to/httpd'?
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: compile 0.24.2 errors
Posted by "Bruce A. Mah" <bm...@freebsd.org>.
If memory serves me right, plasma wrote:
> On Sat, Jun 21, 2003 at 02:17:19AM -0700, Andy McCarty wrote:
> >
> > I can recompile APR --enable-threads and svn compiles
> > but apache complains on startup
> >
> > Undefined symbol: apr_allocator_mutex_set
> >
> > Can someone give me a hint on how to proceed?
> > Even RTFM pointers would be welcome at this point.
> >
> > I finally got my python bindings working and mailer.py
> > setup with 0.23.0. I would hate to lose them in the upgrade.
> >
>
> Please see PR #53190
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/53190). Maybe
> they'll settle on a conclusion. Let's wait and see.
Well, I probably know less about subversion than anybody else
associated with this PR (and I *own* the PR, isn't that special), and
I'm just outright confused at this point. :-p
Bruce.
Re: compile 0.24.2 errors
Posted by Andy McCarty <mc...@lom.med.va.gov>.
* Ben Collins-Sussman <su...@collab.net> [2003-06-21 15:02:42 -0500]:
> I use one more flag than you, when configuring apache:
>
> --with-devrandom=/dev/urandom
>
[snip]
>
> I wonder if you're experiencing something similar. How is the commit
> "hanging"? What output do you see on the client? What do the apache
> error/access logs say? What is the last bit of HTTP to traverse the
> network (use etheral to capture)? Be more specific.
>
>
Thank you very much. --with-devrandom=/dev/urandom appears to have
solved my problem.
Just for reference
$svn ci -F svn-commit.tmp
would just sit and not return. After 2 - 10 minutes I would
get frustrated and ^C. I could not find any errors in the
apache log and the client would acted normally when ^C was
trapped. This happened on the local machine with mod_dav and
remotely with mod_dav. But ra_local seemed to work fine.
Again, thank you very much.
--
~Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [OT] Re: FreeBSD and threads was Re: compile 0.24.2 errors
Posted by "Bruce A. Mah" <bm...@freebsd.org>.
If memory serves me right, Justin Erenkrantz wrote:
> --On Sunday, June 22, 2003 12:17 PM -0400 Greg Hudson <gh...@MIT.EDU>
> wrote:
> The pthread_cond_signal calls appear to be delayed in this wakeup. A
> request can not be serviced until *another* request comes in. This is the
> core problem, but we were also able to trivially kernel panic FreeBSD by
> placing a load on a threaded MPM. (I personally haven't tried 5.x/-CURRENT
> in a while, but we know 4.8 still doesn't work. I have lost access to
> boxes that can run -CURRENT.)
>
> We'll note that the worker code works correctly, at least, on Linux,
> Solaris, Darwin, and I believe, AIX. So, we don't believe we're doing
> anything massively wrong. From a conversation with Alfred (one of the core
> FreeBSD kernel guys), libc_r never really was tested with network code (why
> a rewrite was thought to be necessary). sendfile() and threads were broken
> until we came along and were able to talk with Alfred to get it fixed.
>
> One reason to keep this on dev@svn is that I'm aware that more FreeBSD
> developers read this than dev@httpd. ;-) -- justin
Heh. I'm "a" FreeBSD developer, but probably not the one you want.
I'm one of the release engineers (the poor sod who writes most of the
release notes) and the new maintainer of the subversion port in the
ports collection. I'm doing the latter mostly because I have a vested
interest in having an up-to-date subversion, and I was committing most
of the changes for the old maintainer anyways.
IIRC, Alfred (Perlstein, right?) is not really a libc_r person, but
more of a sendfile person. Dan Eischen is probably the guy you want
to ask about thread-related issues. I can point you to him if you are
interested.
Someone mentioned a new libc_r in FreeBSD 5.X. Beginning with 5.1,
there are three threading libraries in various stages of development.
There's: 1) libc_r (which is similar if not identical to 4.X). This
is the default threading library that's in use when you first install
a system. 2) libkse. This is the M:N threading package that uses the
work-in-progress Kernel Scheduled Entities support in kernel (similar
to scheduler activations). Dan Eischen (mentioned above) is probably
the best contact for this. 3) libthr. This is a 1:1 threading
package. Mike Makonnen is the main person working on this now.
It's my personal opinion that eventually libkse will become the
default threads package, but at least for 5.1-RELEASE we (the RE team)
still consider libkse and libthr to be experimental. (The main
concerns from the RE perspective are stability and cross-platform
portability.) That having been said I've seen some fairly encouraging
reports with users running libkse on recent 5.1-HEAD snapshots
(post-release).
Although this isn't quite my area, I'd be happy to try to work with
you (or any other concerned parties) and the appropriate FreeBSD
developers to make this situation (whatever it is!) better.
Bruce.
[OT] Re: FreeBSD and threads was Re: compile 0.24.2 errors
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, June 22, 2003 12:17 PM -0400 Greg Hudson <gh...@MIT.EDU> wrote:
> server/mpm/worker/fdqueue.c's second use is also questionable; it
> re-checks its condition once and returns an "interrupted" error code if
> the condition is still false. Depending on how callers handle such an
> error, that could also cause problems.
The problem is that wakeups don't occur correctly.
(server/mpm/worker/fdqueue.c is the relevant one for this topic.)
Specifically, the pthread_cond_wait calls only return after two
pthread_cond_signals. The pattern is this:
- Request comes in.
- Request pushed onto stack by 'main' thread
- This triggers pthread_cond_signal in the main thread
(At this point, all 'workers' are idle and are in pthread_cond_wait.
So, pthread_cond_signal should wake up at least *one* of them...but...)
- ...Nothing happens until...
- Another request comes in.
- Request pushed onto queue by 'main' thread
- Call pthread_cond_signal
- One worker thread *now* is woken up and services the first request
...repeat pattern...
The pthread_cond_signal calls appear to be delayed in this wakeup. A request
can not be serviced until *another* request comes in. This is the core
problem, but we were also able to trivially kernel panic FreeBSD by placing a
load on a threaded MPM. (I personally haven't tried 5.x/-CURRENT in a while,
but we know 4.8 still doesn't work. I have lost access to boxes that can run
-CURRENT.)
We'll note that the worker code works correctly, at least, on Linux, Solaris,
Darwin, and I believe, AIX. So, we don't believe we're doing anything
massively wrong. From a conversation with Alfred (one of the core FreeBSD
kernel guys), libc_r never really was tested with network code (why a rewrite
was thought to be necessary). sendfile() and threads were broken until we
came along and were able to talk with Alfred to get it fixed.
One reason to keep this on dev@svn is that I'm aware that more FreeBSD
developers read this than dev@httpd. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FreeBSD and threads was Re: compile 0.24.2 errors
Posted by Greg Hudson <gh...@MIT.EDU>.
(Sorry for the off-topic continuation here. Feel free to forward this
to a relevant Apache list.)
On Sat, 2003-06-21 at 21:26, Justin Erenkrantz wrote:
> To the best of our knowledge, we've isolated it to problems in the pthread
> condition variables used with libc_r. We've heard reports from some FreeBSD
> kernel developers that some later versions of FreeBSD (i.e. next major release
> after 5) might have a rewritten libc_r that may address some of these problems.
Interesting.
I found three failures to use condition variables in the httpd source,
one in server/mpm/experimental/leader/leader.c and two in
srclib/apr-util/misc/apr_queue.c. These uses are not properly wrapped
in a while loop checking the condition, so a spurious wakeup (which is
allowed by the POSIX specification) could cause bugs. Perhaps FreeBSD's
condition variable code sometimes generates spurious wakeups, and other
platforms do not.
server/mpm/worker/fdqueue.c's second use is also questionable; it
re-checks its condition once and returns an "interrupted" error code if
the condition is still false. Depending on how callers handle such an
error, that could also cause problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
FreeBSD and threads was Re: compile 0.24.2 errors
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, June 21, 2003 3:02 PM -0500 Ben Collins-Sussman
<su...@collab.net> wrote:
> Not at all. I've been building apache/subversion almost every day on
> FreeBSD for the last three years. I started at FreeBSD 4.2, and I
> have gradually "built world" through every release, and now I'm
> running 4.8. And I've always configured just like you, with
> --enable-threads forced for apache/apr/apu. Never had a problem.
Apache httpd's threaded MPMs (i.e. worker) do not even serve pages correctly
on FreeBSD. This is due to a number of problems residing in the core of
libc_r pertaining to network code. The APR developers have decided that
FreeBSD's threading code is not stable enough to be turned on by default.
To the best of our knowledge, we've isolated it to problems in the pthread
condition variables used with libc_r. We've heard reports from some FreeBSD
kernel developers that some later versions of FreeBSD (i.e. next major release
after 5) might have a rewritten libc_r that may address some of these problems.
From the reports we've heard, FreeBSD 4.8 and 5.x are still broken and can not
serve pages. But, I've heard rumors that the 'right' people in FreeBSD land
are aware that libc_r is just broken and strongly discourage its use.
If Subversion uses any APR thread-level locking code (which I don't think it
does), don't expect it to work on FreeBSD if libc_r is linked in. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: compile 0.24.2 errors
Posted by Ben Collins-Sussman <su...@collab.net>.
Michael <ma...@yahoo.com> writes:
> --- Ben Collins-Sussman <su...@collab.net> wrote:
> > I use one more flag than you, when configuring apache:
> >
> > --with-devrandom=/dev/urandom
> >
> > I discovered than on FreeBSD 4.X series, /dev/random blocks
> > *hard* for entropy, and apparently it only gets entropy from the
> > keyboard.
>
> Add a "rand_irqs" to your rc.conf file. For instance, mine has:
>
> rand_irqs="10 14"
>
> Otherwise its keyboard entropy only.
Wow, thanks! I should R my OS's FM.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: compile 0.24.2 errors
Posted by Michael <ma...@yahoo.com>.
--- Ben Collins-Sussman <su...@collab.net> wrote:
> I use one more flag than you, when configuring apache:
>
> --with-devrandom=/dev/urandom
>
> I discovered than on FreeBSD 4.X series, /dev/random blocks
> *hard* for entropy, and apparently it only gets entropy from the
> keyboard.
Add a "rand_irqs" to your rc.conf file. For instance, mine has:
rand_irqs="10 14"
Otherwise its keyboard entropy only.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: compile 0.24.2 errors
Posted by Ben Collins-Sussman <su...@collab.net>.
Andy McCarty <mc...@lom.med.va.gov> writes:
>
> OK I finally got everything to compile with threads
> on my FreeBSD box. But now "svn ci" hangs when run
> over ra_dav. It seems to work fine with ra_local.
> I am assuming this is an APR threads issue on FreeBSD.
Not at all. I've been building apache/subversion almost every day on
FreeBSD for the last three years. I started at FreeBSD 4.2, and I
have gradually "built world" through every release, and now I'm
running 4.8. And I've always configured just like you, with
--enable-threads forced for apache/apr/apu. Never had a problem.
> setup is
> httpd-2.0.46
> configured with --enable-threads --enable-dav --enable-so
I use one more flag than you, when configuring apache:
--with-devrandom=/dev/urandom
I discovered than on FreeBSD 4.X series, /dev/random blocks *hard* for
entropy, and apparently it only gets entropy from the keyboard. For
me, at least, Subversion was unable to generate random UUIDs unless I
was pressing the keyboard, so 'make check' wouldn't run at all, unless
I was typing. (I'm told that /dev/random and the entropy generator
are "all fixed" in FreeBSD 5.X.) /dev/urandom, however, doesn't block
for entropy, and is good enough for the UUID hashing function to work.
I wonder if you're experiencing something similar. How is the commit
"hanging"? What output do you see on the client? What do the apache
error/access logs say? What is the last bit of HTTP to traverse the
network (use etheral to capture)? Be more specific.
> Maybe this could be solved with an upgrade to FreeBSD 4.8?
Nope.
>
> If APR_HAS_THREADS is required should it be checked for at
> configure?
It's not required for svn, so svn's configure doesn't check for it.
> Not that it would solve my problem but it is very frustrating to get
> to the last file to compile, swigutil_py.c, to find out it won't
> compile with the configured APR.
The *swig* bindings, however, *do* require thread support. They're
not technically part of the svn "core". And I believe Sander(?)
recently added a compile-time check to them. If APR_HAS_THREADS is
undefined, then 'make swig-py' will simply bomb out with an
appropriate error message.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: compile 0.24.2 errors
Posted by Andy McCarty <mc...@lom.med.va.gov>.
OK I finally got everything to compile with threads
on my FreeBSD box. But now "svn ci" hangs when run
over ra_dav. It seems to work fine with ra_local.
I am assuming this is an APR threads issue on FreeBSD.
setup is
httpd-2.0.46
configured with --enable-threads --enable-dav --enable-so
subversion 0.24.2
configured with --with-apr=/usr/local/apache2/bin/apr-config
--with-apr-util=/usr/local/apache2/bin/apu-config
--with-apxs=/usr/local/apache2/bin/apxs
Maybe this could be solved with an upgrade to
FreeBSD 4.8?
If APR_HAS_THREADS is required should it be
checked for at configure? Not that it would solve
my problem but it is very frustrating to get to the
last file to compile, swigutil_py.c, to find out it
won't compile with the configured APR.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: compile 0.24.2 errors
Posted by plasma <pl...@pchome.com.tw>.
On Sat, Jun 21, 2003 at 02:17:19AM -0700, Andy McCarty wrote:
>
> I can recompile APR --enable-threads and svn compiles
> but apache complains on startup
>
> Undefined symbol: apr_allocator_mutex_set
>
> Can someone give me a hint on how to proceed?
> Even RTFM pointers would be welcome at this point.
>
> I finally got my python bindings working and mailer.py
> setup with 0.23.0. I would hate to lose them in the upgrade.
>
Please see PR #53190
(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/53190). Maybe
they'll settle on a conclusion. Let's wait and see.
plasma
==========================================================
�罺�x�_�ʪ��v��K�AIDEE SHOP�S�������I
http://edm-prg.epaper.com.tw/click.php?ad_code=11989
==========================================================
PChome�u�W�ʪ��g�~�y�G��T���BDV�ѤѰe
http://shopping.pchome.com.tw/
==========================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org