You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Sander Stoks <sa...@stoks.nl> on 2003/09/14 17:50:35 UTC
Upgrade woes
Hello all,
I upgraded my subversion repository from 0.15.0 to 0.29.0 because I
wanted to start using Web::svn.
Grabbed the tar.gz and got a compile error in that an Apache header
file couldn't be found. I was using 2.0.43 so I upgraded to 2.0.47. I
verified that I could still view the repository with my browser, and
continued upgrading subversion.
I did a dump-and-load cycle as per the FAQ instructions, restarted
apache, but now I can't talk to the repository anymore.
If I try, I get an error such as
~/my/local/dir$ svn log http://10.0.0.2/svn/repos
sanders's password:
subversion/libsvn_ra_dav/util.c:81: (apr_err=175002, src_err=0)
svn: RA layer request failed
svn: PROPFIND of /: 405 Method Not Allowed
10.0.0.2 is my Linux server. I'm doing my work on a BeOS machine which
still has the svn 0.15 tools on it - can it be that it's a version
mismatch? I'm wary to upgrade on the BeOS side too because I can also
no longer see the repository by surfing to http://10.0.0.2/svn/repos,
like I used to.
Any ideas as to what's wrong here?
Thanks in advance,
Sander Stoks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Philip Martin <ph...@codematters.co.uk>.
"Sander Stoks" <sa...@stoks.nl> writes:
> I said this in response to people telling me "you should upgrade
> your svn client as well", and since I didn't know that was
> necessary, I didn't do that because of it needing manual tweaking to
> get to build.
So back to my original point: what command? What shell? What error?
What output?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Sander Stoks <sa...@stoks.nl>.
Philip Martin wrote:
> When you said that the reason you had not upgraded was because
>
> my client runs on BeOS, and the configure support there is not
> working "out of the box"
>
> I assumed you meant that you had trouble building Subversion because
> ./configure did not work. However, given your answer above I deduce
> that you didn't mean that, but rather that you have a run-time
> problem
> with ~/.subversion/.
It's both. I said this in response to people telling me "you should
upgrade your svn client as well", and since I didn't know that was
necessary, I didn't do that because of it needing manual tweaking to
get to build. I later found out that at the point where the build
failed (in libsvn_client-1.a, with a bunch of undefined references),
the svn commandline client had already been built. For some reason,
this is now a 6.4M binary (!) so I definitely will need to look at
what's getting included there. Anyhow, I got a svn which worked, apart
from the crash I mentioned.
> > I've debugged things a bit and found out that the problem starts in
> > get_creds() in providers.c - what it does there is
> >
> > config_dir = apr_hash_get (parameters,
> > SVN_AUTH_PARAM_CONFIG_DIR,
> > APR_HASH_KEY_STRING);
> >
> > (at around line 82). The problem is that this returns null on my
> > system.
>
> That's valid.
>
> > SVN_AUTH_PARAM_CONFIG_DIR is "svn:auth:config-dir", and
> > parameters seems like a valid pointer.
> >
> > Next, this null pointer is passed into svn_config_read_auth_data
> > with
> > cred_kind == svn.simple and realmstring == <http://pc1.stoks.nl:80>
> >
> > Subversion repository.
> >
> > svn_config_read_auth_data does a path_join() which dereferences the
> > null pointer and crashes.
>
> 1. There is no call to svn_path_join in svn_config_read_auth_data.
No; it calls auth_file_path() which calls svn_path_join(). Sorry for
the confusion.
> 2. It is valid to pass a NULL config_dir to
> svn_config_read_auth_data,
> so it should not cause a crash.
>
> > Simply putting an if(config_dir) around the call to
> > svn_config_read_auth_data() solved the problem for me, but I'm
> > probably
> > treating symptoms here...
>
> It's the wrong thing to do.
I found that out: It now wants me to enter my password for anything I
do :-)
> Does BeOS support the APR functions apr_uid_current,
> apr_uid_name_get,
> apr_uid_homepath_get? If it doesn't then
> svn_config__user_config_path
> will return a NULL path. The function auth_file_path in
> config_auth.c
> doesn't handle the NULL (it also leaks any error returned by
> svn_config__user_config_path).
>
> The auth stuff appears to assume that the users config area will
> always be available, which conflicts with the documentation for
> svn_config__user_config_path which says that it may return NULL.
This is indeed what happens. I put in some more debugging printf()s
and indeed the svn_config__user_config_path() in
config_auth.c::auth_file_path() makes authdir_path NULL. I will look
at the BeOS APR port - it's probably the cause of the problems.
Thanks for the suggestions. I'll get back with the results from my APR
endeavours.
Regards,
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Stoks" <sa...@stoks.nl> writes:
> svn now no longer crashes, but I still have to enter my password. For
> svn-0.15, this wasn't needed. I have .svn/auth/password and .svn/auth/
> username files; I use a different username for my checkins. The
> current svn apparently defaults to $USER and doesn't read those files?
Auth data is cached in ~/.subversion/auth/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Sander Stoks <sa...@stoks.nl>.
Philip Martin wrote:
> Does BeOS support the APR functions apr_uid_current,
> apr_uid_name_get,
> apr_uid_homepath_get? If it doesn't then
> svn_config__user_config_path
> will return a NULL path. The function auth_file_path in
> config_auth.c
> doesn't handle the NULL (it also leaks any error returned by
> svn_config__user_config_path).
>
> The auth stuff appears to assume that the users config area will
> always be available, which conflicts with the documentation for
> svn_config__user_config_path which says that it may return NULL.
I traced it back to BeOS' getpwnam() which is called in the
apr_uid_homepath_get(). This always returns NULL - BeOS is essentially
a single-user system.
I sent an email to the APR-dev mailing list because it could be fixed
for BeOS by using getpwuid(0) instead (the current user on BeOS is
essentially always 0). I'm awaiting their response.
svn now no longer crashes, but I still have to enter my password. For
svn-0.15, this wasn't needed. I have .svn/auth/password and .svn/auth/
username files; I use a different username for my checkins. The
current svn apparently defaults to $USER and doesn't read those files?
Thanks,
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Philip Martin <ph...@codematters.co.uk>.
"Sander Stoks" <sa...@stoks.nl> writes:
> Philip Martin wrote:
>
>> I suspect very few people attempt to build on BeOS, if nobody reports
>> the problems they may not get fixed.
>>
>> What command are you using? What shell are you using? What goes
>> wrong? What output do you get? Any errors in config.log?
>
> Using svn log in a directory which is part of my project. BeOS uses a
> bash variety. What goes wrong is a crash in svn_path_join. Config.log
> ends with "configure: exit 0".
When you said that the reason you had not upgraded was because
my client runs on BeOS, and the configure support there is not
working "out of the box"
I assumed you meant that you had trouble building Subversion because
./configure did not work. However, given your answer above I deduce
that you didn't mean that, but rather that you have a run-time problem
with ~/.subversion/.
> I've debugged things a bit and found out that the problem starts in
> get_creds() in providers.c - what it does there is
>
> config_dir = apr_hash_get (parameters,
> SVN_AUTH_PARAM_CONFIG_DIR,
> APR_HASH_KEY_STRING);
>
> (at around line 82). The problem is that this returns null on my
> system.
That's valid.
> SVN_AUTH_PARAM_CONFIG_DIR is "svn:auth:config-dir", and
> parameters seems like a valid pointer.
>
> Next, this null pointer is passed into svn_config_read_auth_data with
> cred_kind == svn.simple and realmstring == <http://pc1.stoks.nl:80>
> Subversion repository.
>
> svn_config_read_auth_data does a path_join() which dereferences the
> null pointer and crashes.
1. There is no call to svn_path_join in svn_config_read_auth_data.
2. It is valid to pass a NULL config_dir to svn_config_read_auth_data,
so it should not cause a crash.
> Simply putting an if(config_dir) around the call to
> svn_config_read_auth_data() solved the problem for me, but I'm probably
> treating symptoms here...
It's the wrong thing to do.
Does BeOS support the APR functions apr_uid_current, apr_uid_name_get,
apr_uid_homepath_get? If it doesn't then svn_config__user_config_path
will return a NULL path. The function auth_file_path in config_auth.c
doesn't handle the NULL (it also leaks any error returned by
svn_config__user_config_path).
The auth stuff appears to assume that the users config area will
always be available, which conflicts with the documentation for
svn_config__user_config_path which says that it may return NULL.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Sander Stoks <sa...@stoks.nl>.
Philip Martin wrote:
> I suspect very few people attempt to build on BeOS, if nobody reports
> the problems they may not get fixed.
>
> What command are you using? What shell are you using? What goes
> wrong? What output do you get? Any errors in config.log?
Using svn log in a directory which is part of my project. BeOS uses a
bash variety. What goes wrong is a crash in svn_path_join. Config.log
ends with "configure: exit 0".
I've debugged things a bit and found out that the problem starts in
get_creds() in providers.c - what it does there is
config_dir = apr_hash_get (parameters,
SVN_AUTH_PARAM_CONFIG_DIR,
APR_HASH_KEY_STRING);
(at around line 82). The problem is that this returns null on my
system. SVN_AUTH_PARAM_CONFIG_DIR is "svn:auth:config-dir", and
parameters seems like a valid pointer.
Next, this null pointer is passed into svn_config_read_auth_data with
cred_kind == svn.simple and realmstring == <http://pc1.stoks.nl:80>
Subversion repository.
svn_config_read_auth_data does a path_join() which dereferences the
null pointer and crashes.
Simply putting an if(config_dir) around the call to
svn_config_read_auth_data() solved the problem for me, but I'm probably
treating symptoms here...
Regards,
Sander Stoks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Philip Martin <ph...@codematters.co.uk>.
"Sander Stoks" <sa...@stoks.nl> writes:
>> Garrett Rooney <ro...@electricjellyfish.net> writes:
>>
>> You better upgrade your client.
>
> The reason I postponed this is because my client runs on BeOS, and the
> configure support there is not working "out of the box".
I suspect very few people attempt to build on BeOS, if nobody reports
the problems they may not get fixed.
What command are you using? What shell are you using? What goes
wrong? What output do you get? Any errors in config.log?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Sander Stoks <sa...@stoks.nl>.
> Was Apache built against 3.1.17? You'll need to rebuild Apache
> against
> 4.0.14. IIRC, just compiling mod_dav_svn with berkeley db 4.0.14
> isn't
> enough.
Thanks, that was it. I didn't think Apache would have anything to do
with the DB.
Current status: I can view the repository again using my web browser,
and am trying to get SVN::Web to work (having reconfigured subversion
with --with-swig); the documentation for this is rather sparse.
I'm also trying to debug the crash in svn_path_join() in my BeOS svn
client.
--Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by John Szakmeister <jo...@szakmeister.net>.
Was Apache built against 3.1.17? You'll need to rebuild Apache against
4.0.14. IIRC, just compiling mod_dav_svn with berkeley db 4.0.14 isn't
enough.
-John
PS Sorry you received this twice Sander, I forgot to reply-to-all the first
time. :-)
On Monday 15 September 2003 17:40, Sander Stoks wrote:
> Okay, my upgrade woes continue. If you just tuned in: I'm upgrading my
> svn server from 0.15.0 to 0.29 because I want to start using Web::svn.
> In the process, I upgraded Apache 2.0.43 to 2.0.47. I'm now getting
> "bad database version: got 3.1.17, should be at least 4.0.14" when I
> try to browse to my repository using a web browser.
>
> I tried grabbing the latest BerkeleyDB (4.1..25), but that wasn't the
> problem, because when I tried building, I didn't get past ./configure -
> -with-berkeley-db=/usr/local/BerkeleyDB.4.1, because it complained it
> couldn't find the correct db version. ./configure --with-berkeley-db=/
> usr/local/BerkeleyDB.4.0 worked. I remade subversion just in case,
> removed my newly created repository, created it again with the newly
> built svnadmin, loaded the database dump, and restarted Apache.
>
> Same error:
>
> <?xml version="1.0" encoding="utf-8"?>
> <D:error xmlns:D="DAV:" xmlns:m="http://apache.org/dav/xmlns" xmlns:C=
> "svn:">
> <C:error/>
> <m:human-readable errcode="160000">
> bad database version: got 3.1.17, should be at least 4.0.14
> </m:human-readable>
> </D:error>
>
> Using objdump on mod_dav_svn.so, I see that it dynamically links
> against libsvn_repos-1.so.0, libsvn_fs-1.so.0, libsvn_delta-1.so.0,
> libsvn_subr-1.so.0, libz.so.1, and libc.so.6 - no mention of any of the
> DB libs. I assume that's because they're statically linked.
>
> But in that case, the problem can't be that I have the 3.1.17 version
> of BerkeleyDB somewhere in my lib path, and I specifically add the full
> path to ./configure.
>
> Here's my full command line again:
>
> ./configure --with-aspx --with-zlib --with-berkeley-db=/usr/local/
> BerleleyDB.4.0; make; make install
>
> Hints are very welcome as my repository is now broken.
>
> Thanks,
> Sander
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Sander Stoks <sa...@stoks.nl>.
Okay, my upgrade woes continue. If you just tuned in: I'm upgrading my
svn server from 0.15.0 to 0.29 because I want to start using Web::svn.
In the process, I upgraded Apache 2.0.43 to 2.0.47. I'm now getting
"bad database version: got 3.1.17, should be at least 4.0.14" when I
try to browse to my repository using a web browser.
I tried grabbing the latest BerkeleyDB (4.1..25), but that wasn't the
problem, because when I tried building, I didn't get past ./configure -
-with-berkeley-db=/usr/local/BerkeleyDB.4.1, because it complained it
couldn't find the correct db version. ./configure --with-berkeley-db=/
usr/local/BerkeleyDB.4.0 worked. I remade subversion just in case,
removed my newly created repository, created it again with the newly
built svnadmin, loaded the database dump, and restarted Apache.
Same error:
<?xml version="1.0" encoding="utf-8"?>
<D:error xmlns:D="DAV:" xmlns:m="http://apache.org/dav/xmlns" xmlns:C=
"svn:">
<C:error/>
<m:human-readable errcode="160000">
bad database version: got 3.1.17, should be at least 4.0.14
</m:human-readable>
</D:error>
Using objdump on mod_dav_svn.so, I see that it dynamically links
against libsvn_repos-1.so.0, libsvn_fs-1.so.0, libsvn_delta-1.so.0,
libsvn_subr-1.so.0, libz.so.1, and libc.so.6 - no mention of any of the
DB libs. I assume that's because they're statically linked.
But in that case, the problem can't be that I have the 3.1.17 version
of BerkeleyDB somewhere in my lib path, and I specifically add the full
path to ./configure.
Here's my full command line again:
./configure --with-aspx --with-zlib --with-berkeley-db=/usr/local/
BerleleyDB.4.0; make; make install
Hints are very welcome as my repository is now broken.
Thanks,
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Sander Stoks <sa...@stoks.nl>.
Ben, Garrett, thanks for your responses.
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > > svn: PROPFIND of /: 405 Method Not Allowed
>
> And really, this looks the standard error you get when there's a
> permissions problem. (Apache doesn't have complete r/w access to the
> repos/db/ files.) What does the Apache error log say?
This was an interesting hint. I saw the following error:
"bad database version: got 3.1.17, should be at least 4.0.14"
So I probably built with the wrong BerkeleyDB version. I did a make
clean and a new configure with the following switches:
./configure --with-aspx --with-zlib --with-berkeley-db=/usr/local/
BerkeleyDB4.0
and a remake. I removed my new repository, created a new one and
loaded the dumpfile again. It seemed to work, but I get exactly the
same error :-( I see that the exact version of BerkeleyDB I have is
4.0.1a - I guess that's not 4.0.14, but still not 3.1.17, so I wonder
why my configure didn't pick that up. I see the path correctly
included when making. Any help there? The path is correct; my /usr/
local/BerkeleyDB4.0 has include, bin, and lib subdirs (and doc).
> And yes, if your server is 0.29, your client can only *safely* be
> 0.28
> or 0.29. You better upgrade your client.
The reason I postponed this is because my client runs on BeOS, and the
configure support there is not working "out of the box". I tried
though, and although it fails later on in the build process when
linking libsvn_wc (with "undefined reference to
`svn_wc__remove_wcprops'" and a load of others), but at that point the
actual svn binary _has_ been built, and runs. The problem there is
that it crashes when I type "svn log", in svn_path_join
(the call stack is this:
segment violation occurred
svn_path_join:
svn_path_join:
+003b 80048347: * 028b movl (%edx), %eax
svn:sc
frame retaddr
fd0011dc 8003902f auth_file_path + 0000003f
fd001220 800390ce svn_config_read_auth_data + 0000002a
fd001250 8002981f get_creds + 0000009f
fd00128c 80029ab2 simple_first_creds + 00000046
fd0012c4 80037b2a svn_auth_first_credentials + 0000009e
fd001304 800763ca request_auth + 000000a2
fd001330 80082cf8 get_credentials + 00000038
fd001350 80082d5e basic_challenge + 0000005e
fd001484 80084406 auth_challenge + 0000039e
fd0014c4 80084744 ah_post_send + 000000ec
fd0014f0 8008aefd ne_end_request + 00000071
fd001518 8008af8b ne_request_dispatch + 00000047
fd001530 80090e98 svn_ra_dav__parsed_request + 00000254
fd001584 8008efa7 svn_ra_dav__get_props + 00000247
fd00161c 8008f061 svn_ra_dav__get_props_resource + 00000099
fd001654 8008f1fb svn_ra_dav__get_starting_props + 00000033
fd001680 8008f2ca svn_ra_dav__search_for_starting_props + 000000c2
fd0016c4 8008f41e svn_ra_dav__get_baseline_props + 0000002e
fd00170c 8008f5ea svn_ra_dav__get_baseline_info + 0000003a
fd00174c 80080a2b svn_ra_dav__get_log + 000001af
fd0017cc 80027d2c svn_client_log + 000003dc
fd001844 80018c5a svn_cl__log + 000001d6
fd001898 8001a00d main + 0000106d
fd001af4 800165d5 _start + 00000061
I get the same crash whether I simply type "svn log" or "svn log http:/
/10.0.0.2/svn/repos". The old svn still works, but gives me
~/oaknix/kernel$ svn-0.15 log http://10.0.0.2/svn/repos
sanders's password:
subversion/libsvn_ra_dav/util.c:81: (apr_err=175002, src_err=0)
svn: RA layer request failed
svn: PROPFIND of /: 405 Method Not Allowed
which is probably the DB problem.
Many thanks for your help,
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Ben Collins-Sussman <su...@collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > svn: PROPFIND of /: 405 Method Not Allowed
And really, this looks the standard error you get when there's a
permissions problem. (Apache doesn't have complete r/w access to the
repos/db/ files.) What does the Apache error log say?
And yes, if your server is 0.29, your client can only *safely* be 0.28
or 0.29. You better upgrade your client.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Upgrade woes
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Sander Stoks wrote:
> Hello all,
>
> I upgraded my subversion repository from 0.15.0 to 0.29.0 because I
> wanted to start using Web::svn.
> Grabbed the tar.gz and got a compile error in that an Apache header
> file couldn't be found. I was using 2.0.43 so I upgraded to 2.0.47. I
> verified that I could still view the repository with my browser, and
> continued upgrading subversion.
>
> I did a dump-and-load cycle as per the FAQ instructions, restarted
> apache, but now I can't talk to the repository anymore.
>
> If I try, I get an error such as
>
> ~/my/local/dir$ svn log http://10.0.0.2/svn/repos
> sanders's password:
>
> subversion/libsvn_ra_dav/util.c:81: (apr_err=175002, src_err=0)
> svn: RA layer request failed
> svn: PROPFIND of /: 405 Method Not Allowed
>
> 10.0.0.2 is my Linux server. I'm doing my work on a BeOS machine which
> still has the svn 0.15 tools on it - can it be that it's a version
> mismatch? I'm wary to upgrade on the BeOS side too because I can also
> no longer see the repository by surfing to http://10.0.0.2/svn/repos,
> like I used to.
>
> Any ideas as to what's wrong here?
First off, the version mismatch WILL be a problem. It may not be THE
problem you're having now, but it definately will be going forward,
there are numerous incompatabilities between those two versions of
Subversion.
Second, you're going to have to give a lot more details about your
mod_dav_svn configuration. What do you have in httpd.conf? Also, can
you access the repository directly via ra_local?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org