Edgewall Software
Modify

Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#2472 closed defect (fixed)

Exception in Pool.__Del__

Reported by: reed@… Owned by: Christopher Lenz
Priority: normal Milestone: not applicable
Component: version control Version: 0.9.2
Severity: major Keywords: svn
Cc: mark@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Emmanuel Blot)

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/

Attachments (1)

patch1.patch (586 bytes ) - added by camior@… 14 years ago.
Patch to fix this bug.

Download all attachments as: .zip

Change History (24)

comment:1 by Christian Boos, 15 years ago

Component: generalversion control
Milestone: 0.9.3
Owner: changed from Jonas Borgström to Christopher Lenz

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)

comment:2 by Emmanuel Blot, 15 years ago

Description: modified (diff)

comment:3 by reed@…, 15 years ago

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.

comment:4 by reed@…, 15 years ago

The exception is still thrown in 1.3.0-r4.

comment:5 by Christian Boos, 15 years ago

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

comment:6 by Christopher Lenz, 15 years ago

Milestone: 0.9.31.0

comment:7 by pjenvey@…, 15 years ago

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)

comment:8 by anonymous, 15 years ago

i farted

comment:9 by ben@…, 15 years ago

Milestone: 1.00.9.3
Severity: normalblocker

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.

comment:10 by pjenvey@…, 15 years ago

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

comment:11 by Christian Boos, 15 years ago

Milestone: 0.9.30.9.4
Severity: blockermajor

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…

comment:12 by Christian Boos, 15 years ago

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.

comment:13 by Christian Boos, 15 years ago

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.

comment:14 by pjenvey@…, 15 years ago

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)

comment:15 by Christian Boos, 15 years ago

Resolution: fixed
Status: newclosed

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.

comment:16 by mark@…, 15 years ago

Cc: mark@… added

comment:17 by anonymous, 14 years ago

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

comment:18 by Christian Boos, 14 years ago

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.

comment:19 by asmodai@…, 14 years ago

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

in reply to:  15 comment:20 by Christian Boos, 14 years ago

Milestone: 0.9.42.0
Resolution: fixed
Status: closedreopened

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.

comment:21 by Christian Boos, 14 years ago

Keywords: svn added

comment:22 by Christian Boos, 14 years ago

Milestone: 2.0none

by camior@…, 14 years ago

Attachment: patch1.patch added

Patch to fix this bug.

comment:23 by Christian Boos, 14 years ago

Resolution: fixed
Status: reopenedclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.