[Ambulant-users] Multi-threading libambulant

[Kees Blom]

Hi João,

due to some public holidays in the Netherlands, lots of people are 
absent this week,
therefore I'll try to give a quick answer to your message.

The message: "Invalid write of size 4" in your valgrind output indicates 
a serious problem
in the code, and may easily result in segmentation violation.
I do not see this with valgrind on my Ambulant 2.0.2 installation.

 From quick code inspection, I would like to know whether or not you 
turned the configuration
option with_smil30 was on or off. I think it was off, but should be on 
(which is the default).

Bye,

Kees Blom.


João Pedro Cadinha wrote:
> Hi,
>
> I was using the 2.0.1 version. I changed to the 2.0.2 but since I made some small changes in the lib I got some segmentation faults. So I changed the unix_thread.cpp and the unix_thread.h files and rebuilt the libambulant.
>
> I still have the same problem. I used the valgrind like you suggested. I found a few problems but, since I'm not very experienced with valgrind, can you give me your opinion about the output? I'm attaching the output to this mail.
>
> Here's a small explanation about what I'm doing. In the main program I create an instance of a thread manager. Then I call the new session method of the thread manager class who starts a thread that first initializes the factories (datasource_factory, expat_factory, none_window_factory and a playable_factory created by me), then a smil document is loaded using the method create_from_file of the document class. After that, the player is inicialized (smil2::smil_player) and the start method of the player is called. When the method done of the embedder is called the thread is terminated (all destructors are called) and the thread is exited (using the pthread_exit(0) function. Using the gdb there are no threads hanging and after the player ends playing the document the only thread that exists is the main thread, witch is the thread manager.
>
>
> -----Original Message-----
> From: Jack Jansen [mailto:Jack.Jansen at cwi.nl]
> Sent: quarta-feira, 29 de Abril de 2009 9:27
> To: João Pedro Cadinha
> Cc: ambulant-users at ambulantplayer.org
> Subject: Re: [Ambulant-users] Multi-threading libambulant
>
>
> 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
>
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ambulant-users mailing list
> Ambulant-users at ambulantplayer.org
> http://www.ambulantplayer.org/mailman/listinfo/ambulant-users