#168 closed defect (released)
Possible thread related problem with Xapian bindings
| Reported by: | Richard Boulton | Owned by: | Richard Boulton |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Xapian-bindings | Version: | SVN trunk |
| Severity: | normal | Keywords: | |
| Cc: | Sidnei da Silva, Mark Hammond | Blocked By: | |
| Blocking: | Operating System: | All |
Description
I have a test case which repeatedly tries to open (the same) xapian database from multiple threads, checking for thread related problems. It usually fails with a segmentation fault. Occasionally, this failure is preceded by an error message stating "Fatal Python error: GC object already tracked". Occasionally, it completes successfully.
Attachments (1)
Change History (5)
by , 18 years ago
| Attachment: | threadtest.py added |
|---|
comment:1 by , 18 years ago
| Cc: | added |
|---|
comment:2 by , 18 years ago
| Cc: | added |
|---|
comment:3 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I believe that this is fixed in revision 8920. There was a problem in the Python bindings - specifically, the GIL was not being re-acquired when an exception was thrown before setting the Python exception state. This was causing various memory corruption symptoms. Fixed by explicitly calling SWIG_PYTHON_THREAD_END_ALLOW() in the catch() clause (except for directory classes); this is a bit ugly, but I can't see how SWIG could be fixed to do this automatically, since it doesn't know what's going on in the "exception" clause.
comment:4 by , 17 years ago
| Operating System: | → All |
|---|---|
| Resolution: | fixed → released |
Fix is in upcoming 1.0.2 release.
Sample script demonstrating the failure