Browse gives null argument error (FSFS repo)

[dneuer@…]

Hitting "browse" gives the error:

Traceback (most recent call last):
  File "C:\PYTHON23\lib\site-packages\trac\core.py", line 531, in cgi_start
    real_cgi_start()
  File "C:\PYTHON23\lib\site-packages\trac\core.py", line 526, in real_cgi_start
    dispatch_request(path_info, args, req, env)
  File "C:\PYTHON23\lib\site-packages\trac\core.py", line 439, in dispatch_request
    module = module_factory(args, env, database, req)
  File "C:\PYTHON23\lib\site-packages\trac\core.py", line 175, in module_factory
    pool, rep, fs_ptr = open_svn_repos(repos_dir)
  File "C:\PYTHON23\lib\site-packages\trac\core.py", line 458, in open_svn_repos
    rep = repos.svn_repos_open(repos_dir, pool)
SystemError: null argument to internal routine

• Windows XP sp 2
• SVN 1.1.4
• svn-win32-1.1.4.py (for Python 2.3)
• docutils 0.3.7 (happens w/ 0.3.5, too — Win install docs for trac say to use 0.3.7)
• Python 2.3
• sqlite 3.2.1
• clearserver-python-0.9.12-win32
• pysqlite version 1.1.6

The interesting thing is, if I add logging to trac\core.py before the call to repos.svn_repos_open() and do a repr() on the pool and the repos_dir vars, they're both set to seemingly valid values. However, the error still occurs. Furthermore, if I fire up the Python interpreter from the command line and do the *exact* same series of operations (minus the slash escaping, but set up my directory string the same as my logging output indicated it was done by core.py), I can open the repository just fine! (repr() on the returned object shows a valid p_repos_t object):

C:\>python
Python 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from svn import core, repos, util
>>> core.apr_initialize()
0
>>> pool = core.svn_pool_create(None)
>>> mydir = 'c:\\shared\\svnDevWeb'
>>> rep = repos.svn_repos_open(mydir, pool)
>>> repr(rep)
"'_e01ca600_p_svn_repos_t'"
>>> ^Z

Thanks, Dave

[Christopher Lenz]

Description readablized.

[oliver@…]

I had the same problem with SVN 1.1.3 and Trac 0.8.1 and a BerkleyDB repository on win32. After a "svnadmin recover pathtorepos" it works again.

[oliver@…]

In my case it was after a large file upload (attachment) in the wiki page. I hope this can help.

[Christian Boos]

Same experience as oliver, yesterday evening: after I crashed tracd, I had to recover the repository too. Until then, I got the null argument to internal routine error.

But that error is fairly generic, and the original reporter apparently didn't do a recovery before being able to open the repository with the python interpreter, and he also didn't mention BDB. These would need to be clarified.

[dneuer@…]

As the original reporter, I will clarify: I never had any type of crash, and I'm using FSFS file store (as the title states), not Berkely DB. Nor was I running tracd, merely trying to browse the repo from Apache using trac.cgi.

[osamu.hashimoto@…]

In my trouble case,using BDB,there exist dead trunsaction. Following operation resolve "null argument to internal routine" problem.

C:\SVNRPST>svnadmin lstxns MYREPO
c

C:\SVNRPST>svnadmin rmtxns MYREPO c
Transaction 'c' removed.

C:\SVNRPST>svnadmin lstxns MYREPO

C:\SVNRPST>svnadmin recover MYREPO
Repository lock acquired.
Please wait; recovering the repository may take some time...

Recovery completed.
The latest repos revision is 76.
C:\SVNRPST>

[jams@…]

I'm experiencing the same problem with an FSFS repository, and the problem definitely appeared after I upgraded my Windows SVN installation to 1.2.0. I've uninstalled and reinstalled the trac binary packages, and the problem persists. Has anyone fixed this and can offer some more advice?

[Christian Boos]

I've made the normalization of the repository_dir more strict in r2461 (now in trunk), so this should not(?) happen anymore.

Please reopen if this problem reappears.