On Sonntag, 19. Dezember 2010, Einar Rünkaru wrote:
> Hi
>
> Attached are couple of fixes for current j6t branch.
>
> First patch fixes crash that may be triggered by any plugin.
This patch sets:
plugin->thread = 0; \
On Sonntag, 19. Dezember 2010, Einar Rünkaru wrote:
> From 0585eda248483aae4d2f5340aaafedad7378f5c0 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Einar=20R=C3=BCnkaru?= <[email protected]>
> Date: Sun, 19 Dec 2010 19:41:46 +0200
> Subject: [PATCH] Fixed potential crash in plugins
>
> PLUGIN_THREAD macros use thread autodelete feature, so
> after run() completes, thread is destroyed.
> Clear thread pointer at the end of run(), then
> PLUGIN_DESTRUCTOR does not refer to already deleted
> thread object
> ---
> cinelerra/pluginclient.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/cinelerra/pluginclient.h b/cinelerra/pluginclient.h
> index f1a340b..2b20e66 100644
> --- a/cinelerra/pluginclient.h
> +++ b/cinelerra/pluginclient.h
> @@ -112,6 +112,7 @@ void thread_class::run() \
> int result = window->run_window(); \
> /* This is needed when the GUI is closed from itself */ \
> if(result) plugin->client_side_close(); \
> + plugin->thread = 0; \
> }
But PLUGIN_DESTRUCTOR_MACRO says this:
#define PLUGIN_DESTRUCTOR_MACRO \
if(thread) \
{ \
/* This is needed when the GUI is closed from elsewhere than itself */ \
/* Since we now use autodelete, this is all that has to be done, thread will
take care of itself ... */ \
/* Thread join will wait if this was not called from the thread itself or go
on if it was */ \
thread->window->lock_window("PLUGIN_DESTRUCTOR_MACRO"); \
thread->window->set_done(0); \
thread->window->unlock_window(); \
thread->join(); \
...
How does this make sense when you have to set plugin->thread to NULL manually?
I mean, even when the window is "closed from elsewhere", run_window() will
return eventually, and only after that can the desctructor run (so I hope,
otherwise we are in bigger trouble). And in this case, the destructor expects
thread to be non-NULL. It would not be the case anymore with your patch.
I haven't analyzed what's going on, but am only reasoning from what I see in
the code fragment and comments. I must be missing something. Please help.
> Second patch fixes audio-video synchronization while using ALSA sound
> output.
This second patch is identical to Monty's that we discussed here:
http://thread.gmane.org/gmane.comp.video.cinelerra-cv.general/12032/focus=12042
(it's my first comment in that message). I.e., it does not improve things for
me: Video is initially very jerky, and catches up with audio after a few
seconds. (At that time, synchronization *is* better than it used to be, but
it's not an improvement when video starts off jerky.)
-- Hannes
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
