[Ambulant-users] Multi-threading libambulant

Jack Jansen Jack.Jansen at cwi.nl
Wed Apr 29 10:26:52 CEST 2009


On 27 apr 2009, at 17:13, João Pedro Cadinha wrote:

> Hi,
>
> I’m trying to use libambulant in a multi-thread architecture and I’m  
> having some memory leak problems. I have a thread manager class that  
> creates threads that implement several players (using the  
> smil2::player class). I think my problem is in the destructor of the  
> player because I had some segmentation faults when I tried to use  
> the smil_player destructor. This error occurs in these invocations:
> - m_scheduler->reset_document();
> - delete m_scheduler;
> - delete m_event_processor;
>
> I don’t think that the scheduler and the event processor are shared  
> across all threads, but being shared can be the reason why they  
> can’t be destruct. A lock is being applied to the player destructor.  
> Are there any other plausible causes for this memory leak problem?
>
> I have also created a simple example that creates several threads  
> that simply loaded a document, parsed it and destructed it and after  
> several threads there was also a memory leak problem. Any ideas?


Joào,
which version of ambulant are you using?

There was a thread leak until very recently, it was fixed in release  
2.0.2 (last week), and since then the fix has also been propagated to  
the CVS main branch.

So, if you're using sourcecode that you got more than a week or so ago  
you should try to start from fresh source, if possible. If you've made  
heavy modifications to the source: the only things that were changed  
(wrt. this problem) are unix_thread.cpp and unix_thread.h, so you can  
probably simply replace them with the newer version.

That said: there could definitely be problems with multiple  
invocations of the player: we still miss a global class to hold all  
sorts of things like factories, so it is a bit random which objects  
need to be retained between players, and which need to be released.  
But: your segmentation fault seems to point to a double free, which is  
pretty much the reverse of a leak. If the problem persists after  
updating the thread code, as outlined above, your best bet is to use  
valgrind. It will tell you both about double frees (or referencing  
memory already freed) and leaks. In both cases, you'll get the stack  
trace for the place where the memory area with trouble was initially  
allocated. The only problem with valgrind is that you have to wade  
through lots of things that are technically errors, but not your fault  
(problems deep down in the ffmpeg or X11 library, for example).

If you find something: please be sure to let us know so we can fix it,
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman





More information about the Ambulant-users mailing list