Exception in Pool.__Del__

[reed@…]

I'm getting this exception in Pool.__Del__ in timeline, browser, and trac-admin.

[Sun Dec 11 03:20:54 2005] [error] [client 68.117.216.48] Exception , referer: http://scit.us/projects/dawg/browser/
[Sun Dec 11 03:20:54 2005] [error] [client 68.117.216.48] exceptions.AssertionError, referer: http://scit.us/projects/dawg/browser/
[Sun Dec 11 03:20:54 2005] [error] [client 68.117.216.48] : , referer: http://scit.us/projects/dawg/browser/
[Sun Dec 11 03:20:54 2005] [error] [client 68.117.216.48] <exceptions.AssertionError instance at 0x828922c>, referer: http://scit.us/projects/dawg/browser/
[Sun Dec 11 03:20:54 2005] [error] [client 68.117.216.48]  in , referer: http://scit.us/projects/dawg/browser/
[Sun Dec 11 03:20:54 2005] [error] [client 68.117.216.48] <bound method Pool.__del__ of <trac.versioncontrol.svn_fs.Pool object at 0x857922c>>, referer: http://scit.us/projects/dawg/browser/

[cboos]

Which version of the SVN bindings are you using?

Does this error prevents the page to be displayed, or does everything seem to work normally and you only see this error in the apache log?

Also, what does the Trac log shows? (see TracLogging for info about how to enable it)

[reed@…]

The pages display fine as far as I can tell. I'm only seeing this in the apache log (and on the console when I run trac-admin.)

I've installed the subversion-python port for FreeBSD, which I think is 1.30-r2. 1.30-r4 is now out. I will try it.

[reed@…]

The exception is still thrown in 1.3.0-r4.

[cboos]

... which is not that surprising, as 1.3.0 features an automatic pool management, which apparently conflicts with our own pool management.

[pjenvey@…]

I received this same error, but during the tests, on 1.0dev (r2682), FreeBSD 4, subversion 1.3.0-r4:

pjenvey@ns:/usr/local/src/trac$ sudo cp trac/test.py .
Password:
pjenvey@ns:/usr/local/src/trac$ python ./test.py
.................................................................................................................................................................................................................................................................................................................................................................................................................................
----------------------------------------------------------------------
Ran 417 tests in 13.152s
OK
Exception exceptions.AssertionError: <exceptions.AssertionError instance
at 0x8596a8c> in <bound method Pool.__del__ of
<trac.versioncontrol.svn_fs.Pool object at 0x85500cc>> ignored

I was lead to try the tests because of another issue -- after upgrading to the latest apache + subversion, my trac site started receiving this error intermittently during page loads:

[Thu Dec 29 19:21:19 2005] [error] [client 66.249.66.168] PythonHandler
trac.web.modpython_frontend:
   File "/usr/local/lib/python2.4/site-packages/libsvn/core.py", line
1097, in svn_pool_create\n
return apply(_core.svn_pool_create, args)
[Thu Dec 29 19:21:19 2005] [error] [client 66.249.66.168] PythonHandler
trac.web.modpython_frontend:
 TypeError: argument number 0: a 'apr_pool_t *' is expected,
'instance(<libsvn.core.GenericSWIGWrapp
er instance at 0xbd1a62c>)' is received

They result in 500 error responses from the web server. Reloading the page one or more times resolves the issue temporarily The same problem is documented here: http://svn.haxx.se/users/archive-2005-12/0569.shtml Are these two problems related? Is this a trac problem, a subversion python bindings problem, or both? This is an especially nasty problem for FreeBSD users, as the FreeBSD port is up to subversion 1.3.0-r4 (looks like they had to upgrade from 1.2.3 because of other port dependencies http://www.freshports.org/commit.php?message_id=200512111105.jBBB5RV8001594@repoman.freebsd.org)

[anonymous]

i farted

[ben@…]

I'm experiencing this issue too, and its pretty catastrophic. I mean, I don't see how another release can occur without repairing this since it essentially makes Trac un-usable with the latest (now fully released) subversion 1.3.0. Is this only happening on FreeBSD, or does this hit every single subversion 1.3.0 + Trac combo? If it's the latter, this is without a doubt a release blocker if there ever was one. If its purely FreeBSD with the ports, I'd still consider it critical due to the large amount of FBSD users out there. Of course, I'm not too thrilled with the subversion people for not testing their new pool gizmo with Trac and at least helping the trac dev's fix it. Considering how many people use Trac with subversion, seems rather odd they wouldn't do such a test.

[pjenvey@…]

It's not just a FreeBSD/FreeBSD ports issue, according to the original poster on that subversion-users thread: http://svn.haxx.se/users/archive-2005-12/0569.shtml He's seeing it on Linux with the exact same software versions I have. I'll also note, I just upgraded to subversion 1.3.0. The error I saw at the end of the trac tests no longer occurs (this was with trac r2721), however the intermittent 500 errors (and the accompanying "argument number 0: a 'apr_pool_t *' is expected" in the error_logs) still occur

[cboos]

Sorry, this is not going to be a blocker, as the Subversion bindings don't appear to be very stable as of 1.3.0. I tried to build them on Windows, and after a good deal of hacking, I finally got them to run, only to get the same

a 'apr_pool_t *' is expected, 'instance(<libsvn.core.GenericSWIGWrapper
instance at ...>)'

even for the simplest usage...

[cboos]

OTOH, everything seems to work flawlessly on Linux for me... I built the bindings from the 1.3.0 source package (r17949), using python 2.3.4 and the bundled .i. ... which makes me think that maybe the bundled .i are specific to a given python version (2.3 vs. 2.4). That seems to be a possible reason for the error. I'll investigate further.

[cboos]

OK. The situation is clearer now:

• on Windows, I did some mistakes, forget the `a 'apr_pool_t *' is

expected`

error that I reported above. It now works for me, excepted for the error reported in this ticket.

• on Linux, it works flawlessly ... except that I also get the error

reported

in this ticket.

... which can be fixed by the following patch (from David James)

Index: subversion/bindings/swig/python/svn/core.py
===================================================================
--- subversion/bindings/swig/python/svn/core.py (revision 17941)
+++ subversion/bindings/swig/python/svn/core.py (working copy)
@@ -189,7 +189,7 @@
   # app tries to destroy a pool during the shutdown process. Instead, we
   # check to make sure the application_pool is still around before
calling
   # pool.destroy().
-  if application_pool:
+  if application_pool and application_pool.valid():
     pool.destroy()
 apr_pool_destroy = svn_pool_destroy

This patch will be integrated in a later 1.3.x release. So the only remaining problem are the TypeError: argument number 0: a 'apr_pool_t *' is expected errors reported in pjenvey comment above.

[pjenvey@…]

After further investigation I noticed: o I see the "TypeError?: argument number 0: a 'apr_pool_t *' is expected" when running trac with mod_python. The person reporting the same problem on the subversion-users list is also using mod_python (you can see modpython_frontend.py at the bottom of his stack trace). This error causes 500 error responses o After switching trac to the slower CGI, the "TypeError?: argument number 0: a 'apr_pool_t *' is expected" does not occur -- however the original error reported on this bug, "bound method Pool.del" occurs instead. This error did not cause 500 error responses as reed described (reed is probably using CGI mode) o David James patch does in fact solve the Pool.del error, but doesn't affect the mod_python apr_pool_t problem (as you probably already know)

[cboos]

Let's close this one, as the Exception in Pool.__Del__ issue is "fixed" (at least there's an explanation and a patch for the SVN bindings available).

There's now a dedicated ticket about the apr_pool_t *' is expected problem: #2611.

[anonymous]

update to subversion 1.3.2,this problem still exists. I must use vhost to support ssl.

[cboos]

anonymous: What problem? The Exception in Pool.__Del__ (that would be a regression) or the apr_pool_t *' is expected one? If the latter, please follow-up on #2611, which is dedicated to that specific problem.

[asmodai@…]

My Apache error log with Subversion 1.4.0, apr 1.2.7 and swig 1.3.29 fills with

Exception exceptions.AssertionError: <exceptions.AssertionError instance at 0x81
52e6c> in <bound method Pool.__del__ of <trac.versioncontrol.svn_fs.Pool object
at 0x88bc4ec>> ignored

[cboos]

Replying to cboos:

Let's close this one, as the Exception in Pool.__del__ issue is "fixed" (at least there's an explanation and a patch for the SVN bindings available).

Well, according to our recent discussions for the bug triage, I think it's not OK to keep this one as "fixed", as apparently the problem is still there in 1.4.0.

So we'll handle it the same way as #2611.

I'll use the Milestone 2.0 until we find a better way to distinguish the tickets not yet triaged (currently those having an empty milestone) from the others.

Also, keeping it opened will have the benefit of making this ticket visible in the Known Issues list in TracSubversion#KnownIssues.

[camior@…]

Patch to fix this bug.

[cboos]

Well, the attachment:patch1.patch above is the one presented in comment:13.

This patch has been applied one year ago, and is available in mainline since Subversion 1.3.1.