I am currently using swig 1.3.40 to wrap a C++ library for use in PERL
and PHP. I am having issues with threading in PERL that I am unable to
resolve. When run without threading, or with PERL level locks at
critical sections, there are no issues. When run in a heavily threaded
environment, I get random segfaults as well as errors like this:
Thread 100 terminated abnormally: TypeError in method 'url_base',
argument 1 of type 'eSoft::url *'
I rewrote an example application in C++ to verify that it works when
threaded and it is fine. The issues is definitely at the swig level.
After examining the core dumps and reading the swig documentation, I
am fairly certain that the issue lies with the swig runtime type
I know that the documentation says that swig modules should be loaded
serially since the type system is stored in static memory -- this is
the case with my application. My perl application loads the module
once at the beginning and there is only one swig module.
Here is my best guess at what is occurring. When looking through the
wrapper code, it appear that the static swig_types array is modified
after initialization and is therefore not thread safe. There are
several functions like SWIG_TypeCheck, SWIG_TypeCheckStruct, etc...
that get pointers to items in the static array. It then gets the
possible types it can cast to from the cast property. The cast
properties are linked by next and prev pointers. These pointers are
modified while iterating through the possible cast types. If several
threads are modifying these iterators simultaneously, the outcome is
Almost all of the core dumps I get are related to lines that look like:
iter->prev->next = iter->next;
Does anyone have any solutions to this? I am not using any other swig
modules, and the type map does not need to be shared. Is it possible
to build the module without a static type map and bootstrap it once
per thread, rather than the static once per process system that