null argument to internal routine in Browse Source

[c.unfried@…]

I get

null argument to internal routine

when i click on Browse Source and Timeline.

Here is the Traceback:

Traceback (most recent call last):
  File "C:\Python23\Lib\site-packages\trac\web\modpython_frontend.py", line 206, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "C:\Python23\Lib\site-packages\trac\web\main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "C:\Python23\Lib\site-packages\trac\web\main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "C:\Python23\Lib\site-packages\trac\versioncontrol\web_ui\browser.py", line 92, in process_request
    repos = self.env.get_repository(req.authname)
  File "C:\Python23\Lib\site-packages\trac\env.py", line 162, in get_repository
    repos = SubversionRepository(repos_dir, authz, self.log)
  File "C:\Python23\Lib\site-packages\trac\versioncontrol\svn_fs.py", line 192, in __init__
    self.repos = repos.svn_repos_open(self.path, self.pool())
SystemError: null argument to internal routine

I run trac 0.9.3 on python 2.3.5 on a windows 2003 server. Subversion is installed on another machine and i use a fileshare to access the repository path.

Here is how i installed SVN for python:

• SVN 1.2.3 for Python
  • unpacked svn-win32-1.2.3_py.zip
  • copied libsvn and svn to C:\python23\lib\site-packages
  • copied all *.dll from the Subversion bin Directory (from the other server) into libsvn

initenv succeeded with the fileshare.

Thanks for your support.

Regards,

Christoph

[Christian Boos]

What's your repository_dir? Is it an UNC path? Any chance you could try with a mounted drive?

[c.unfried@…]

Yes it is an UNC path \\ipadress\share.

i tried to mount a network drive R: to
ipadress\share. but then i get an error when i try to resync the repository.

Trac [p:\TRAC\default]> resync
Resyncing repository history...
Assertion failed: is_canonical (base, blen), file C:\Home\brane\src\svn\releases
\subversion-1.2.3\subversion\libsvn_subr\path.c, line 114

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

---

After this i tried to mount r: as
ipadress\drive. and set r:\share as Repository path. Resync works fine.

R:/CodeRepository does not appear to be a Subversion repository.

I can access the repository with TortoiseSVN without any problems.

Regards,

Christoph

[c.unfried@…]

Sorry little mistake in my last post:

I get the following error, want to open the Browser:

R:/CodeRepository does not appear to be a Subversion repository.

[Christian Boos]

Wait, if you can resync using r:\share as the repository path, you should be able to use the TracBrowser as well, using that same setting, because that's using the same code for accessing the repository.

In the error message, it's written R:/CodeRepository, did you forget to restart the server?

Also, I did some tests, and it appears I can access remote repository using UNC paths (both for writing, using cat repos.dump | svnadmin load '\\host\path\repos' and for reading, using trac-admin ... resync), at least if the repository is using the fsfs backend. If the repository is using bdb, I have an error (even for reading), because there's a mismatch in the BDB library versions. I was not able to try with matching versions in order to check if this would be enough to make it work .

[c.unfried@…]

My share is called CodeRepository. i configured R:\CodeRepository in the trac.ini. I just tried to abstract my paths, that's why i used share before ;).

i am not sure which backend i use, i just used the 1-click setup from ​http://svn1clicksetup.tigris.org (version 0.8.6) to install subversion (on a different machine!!).

How do i know that a version mismatch occurs?

Does this error message indicate this?

R:/CodeRepository does not appear to be a Subversion repository.

[Manuzhai]

So what exactly is in R: when you browse there using Explorer?

[c.unfried]

Screenshot of the mapped network drive

[c.unfried]

This is what Explorer shows me:

[Christian Boos]

And what's in R:\CodeRepository\db? If there are subfolders (revprops, revs, transactions), then it's FSFS, otherwise it's BDB.

[c.unfried]

It's FSFS! i have the mentioned subdirectories.

[c.unfried]

i added the additional debug message from ticket #2560 and my log says:

Trac[svn_fs] DEBUG: Using Subversion bindings 1.2.3

I should use Subversion 1.2.3 (see ​http://svn1clicksetup.tigris.org/changelog.htm, i installed 0.8.6)

[c.unfried]

i found the function where the problem is located:

its in the svn_fs.py near line 185:

# Remove any trailing slash or else subversion might abort
path = os.path.normpath(path).replace('\\', '/')
self.path = repos.svn_repos_find_root_path(path, self.pool())
log.debug('Self.Path is %s' % self.path)
if self.path is None:
    raise TracError, \
	  "%s does not appear to be a Subversion repository." % path

with this additional logging message i found out, that self.path is None

Logmessage:

Trac[svn_fs] DEBUG: Self.Path is None

That means repos.svn_repos_find_root_path() returns None.

i hope this helps.

[Christian Boos]

Try upgrading to the 1.3.0 bindings: that won't solve your problem per se, but will probably give you a more detailed error message.

For instance, after some changes in the Samba config of the remote share, I didn't have access anymore to one of the repo file: 1.2.3 simply produced an internal error, whereas 1.3.0 gave me this during resync:

Command failed: ("Can't open file '\\\\dmachine\\profiles\\testfsfs\\db\\current': Access is denied.  ", 720005)

Ok, in that particular case, I could also get that error simply by trying to do an svnadmin dump:

svnadmin: Can't open file '\\dmachine\profiles\testfsfs\db\current': Access is denied.

But if svnadmin dump R:\CodeRepository works for you and not the resync, try the upgrade.

[c.unfried]

i think that was the final hint :)

as you know resync worked for me in trac-admin, but apache service runs under another user on the windows server → it is possible that the service user has no rights on this folder…

i will test this out with our admin next week and let you know if the problem is solved.

[Christian Boos]

I assume that now it worksforyou :)

If not, please reopen…

[anonymous]

I had a very similar problem under Solaris 10 with trac 10.3. It failed with the same null pointer in the same routine. The problem could be solved by setting the LANG environment variable to en_US.ISO8859-1.

Most likely this won't help for the Windows platform but hopefully other with the same problem under a UNIX flavor will find this hint.

-jay