failure to initialise repository

[loaf@…]

I'm getting this errror at the end of initialisation on redhat EL 4. The environment is created nonetheless and is accessible via apache 2.2.3, but for revision 204 of my 218 revisions in subversion I get a "Can't set internal pointer" error.

I've followed all the other threads to do with this pointer error but to no avail.

trac 0.9.6 subversion 1.4.0 apache 2.2.3

stack trace:

 Indexing repository
Failed to initialize environment. /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: gss_delete_sec_context
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/scripts/admin.py", line 616, in do_initenv
    repos = self.__env.get_repository()
  File "/usr/lib/python2.3/site-packages/trac/env.py", line 155, in get_repository
    from trac.versioncontrol.svn_fs import SubversionRepository
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 25, in ?
    from svn import fs, repos, core, delta
  File "/usr/local/lib/svn-python/svn/fs.py", line 19, in ?
    from libsvn.fs import *
  File "/usr/local/lib/svn-python/libsvn/fs.py", line 5, in ?
    import _fs
ImportError: /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: gss_delete_sec_context

[loaf@…]

Further to that, here is the stack trace for the pointer error from "browse source" on changeset 204. Strangely the error seems to be happening in revision 199.

As I mentioned previously this error only appears on this particular changeset view.

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/modpython_frontend.py", line 206, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/web_ui/changeset.py", line 86, in process_request
    self._render_html(req, repos, chgset, diff_options)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/web_ui/changeset.py", line 199, in _render_html
    old_node = repos.get_node(base_path or path, base_rev)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/cache.py", line 103, in get_node
    return self.repos.get_node(path, rev)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 261, in get_node
    self.pool)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 380, in __init__
    self.root = fs.revision_root(fs_ptr, rev, self.pool())
  File "/usr/lib/python2.3/site-packages/libsvn/fs.py", line 217, in svn_fs_revision_root
    return apply(_fs.svn_fs_revision_root, args)
SubversionException: ("Can't set position pointer in file '/usr/local/svn/worksmart/db/revs/199': Invalid argument", 22)

I have no idea if these 2 errors are related, so for now I kept them together. It made more sense to me to change the component to "changeset view".

[Christian Boos]

Are you able to dump that rev?

svnadmin dump /usr/local/svn/worksmart -r199 --incremental

(same user as Trac)

[anonymous]

Replying to cboos:

Are you able to dump that rev?

I can dump the rev from the command line and also browse the changeset for it with trac.

[Christian Boos]

And what about rev 204, can you dump that one too?

Also, in the description, you're talking about a Can't set position pointer in file, but the actual traceback shows a libsvn_ra_dav-1.so.0: undefined symbol: gss_delete_sec_context error, likely due to a missing or conflicting GSSAPI library within Apache (missing heimdal-lib package?).

[anonymous]

I can dump 204 as well, no problem. The position pointer thing is happening whilst browsing the changeset for 204, whilst the libsvn_ra_dav-1.so.0: undefined symbol happens when I initenv.

My apache and svn libs have the same libgssapi_krb5.so and libkrb5.so. Do you think I need to install heimdal on top of that? I have never heard of Heimdal before.

$ ldd /usr/local/apache2/bin/httpd
        libssl.so.4 => /lib/libssl.so.4 (0x04fe5000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x04bcd000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x04b2d000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x04b43000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00ded000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x04baa000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00396000)
        libz.so.1 => /usr/lib/libz.so.1 (0x0028f000)
        libm.so.6 => /lib/tls/libm.so.6 (0x0026a000)
        libaprutil-1.so.0 => /usr/local/apache2/lib/libaprutil-1.so.0 (0x00f63000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00540000)
        libapr-1.so.0 => /usr/local/apache2/lib/libapr-1.so.0 (0x00520000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x00111000)
        librt.so.1 => /lib/tls/librt.so.1 (0x005a3000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x004d7000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x002a1000)
        libdl.so.2 => /lib/libdl.so.2 (0x00264000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00138000)
        /lib/ld-linux.so.2 (0x0011f000)

$ ldd /usr/local/bin/svn
        libsvn_client-1.so.0 => /usr/local/lib/libsvn_client-1.so.0 (0x008ec000)
        libsvn_wc-1.so.0 => /usr/local/lib/libsvn_wc-1.so.0 (0x00984000)
        libsvn_ra-1.so.0 => /usr/local/lib/libsvn_ra-1.so.0 (0x006d8000)
        libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0 (0x004e1000)
        libsvn_ra_local-1.so.0 => /usr/local/lib/libsvn_ra_local-1.so.0 (0x003f6000)
        libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0 (0x00869000)
        libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0 (0x0030b000)
        libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0 (0x003cd000)
        libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0 (0x00c39000)
        libsvn_ra_dav-1.so.0 => /usr/local/lib/libsvn_ra_dav-1.so.0 (0x0068b000)
        libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x006b7000)
        libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x0059e000)
        libaprutil-1.so.0 => /usr/local/apache2/lib/libaprutil-1.so.0 (0x001f5000)
        libapr-1.so.0 => /usr/local/apache2/lib/libapr-1.so.0 (0x00d05000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x0026a000)
        librt.so.1 => /lib/tls/librt.so.1 (0x00136000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x0014a000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x002a1000)
        libdl.so.2 => /lib/libdl.so.2 (0x00264000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x04b2d000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x04b43000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x04baa000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00ded000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00396000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00540000)
        libz.so.1 => /usr/lib/libz.so.1 (0x0028f000)
        libc.so.6 => /lib/tls/libc.so.6 (0x006dc000)
        /lib/ld-linux.so.2 (0x0011f000)}}}

[loaf@…]

the strange "browse changeset" behaviour seems to have disappeared without me knowingly having done anything so I can now happily browse any changeset in the repository. However init-env is still failing at the end with the same message as above.

[sgorilla]

Ok here is what I did. I had the same problem on my machine

I am using subversion 1.4.0

in neon, in ne_auth.c, it does not load up the correct header that contains the structure for gss_delete_sec_context.

I believe this is has to do with the CentOS 4.4 or RHEL 4 krb5-devel package which includes the header files for /usr/include/gssapi. This header files possibly are different than different Linux disros (they are fairly old).

Just disable neon on compilation. ./configure —without-neon

You can use neon if you want to upgrade kerberos, which is insane and I do not recommend it on CentOS 4.4 or RHEL 4.

[Christian Boos]

So this is mainly a Subversion installation/build issue. I think the workarounds described here are enough. If someone wants to contribute other fixes, he's free to do so, but please don't reopen the ticket as it's not really a Trac issue.

[liucougar]

if you indeed need neon support in subversion, try to modify the subversion Makefile: change this line:

SVN_APR_LIBS =  /usr/local/src/subversion-1.4.0/apr/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread -ldl

to

SVN_APR_LIBS =  /usr/local/src/subversion-1.4.0/apr/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread -ldl -lgssapi

you may also need to link /usr/lib/libgssapi.so.2 to /usr/lib/libgssapi.so

[rob]

Replying to liucougar:

Thanks - this was my problem too. Old Red Hat version 8, I think. Needed a bit more, but absolutely correct.

I changed mine from

SVN_APR_LIBS =  /home/rob/build/subversion-1.4.2/apr/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread -ldl

to

SVN_APR_LIBS =  /home/rob/build/subversion-1.4.2/apr/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread -ldl -L/usr/kerberos/lib -lgssapi_krb5 -lkrb5 -lk5crypto

I found this bit of linking info when I realized I had a neon-config sitting the subversion bin directory. A ./bin/neon-config --libs gives the full link line. Cut and paste whatever you need (or think you need, like I did).

[anonymous]

This link solved my problem ​http://www.gossamer-threads.com/lists/trac/users/28073

Replying to cboos:

Are you able to dump that rev?

svnadmin dump /usr/local/svn/worksmart -r199 --incremental

(same user as Trac)