Bug#288202: potential fixes

[Stuart Anderson]

I have prepared fixes for all 3 of these grave bugs. Support for libxine
is still enabled.

The hanging on open problem turned out to be caused by multiple threads using
XLockDisplay(). In addition to the main thread which is opening the video
plugins, the OpenGL video plugin also starts up a new thread that then tries
to lock the displsy.  I suspect this was an ehancement in libxine that caught
pornview off guard.

The fix for the crash is the patch which was already contained in 345100.

The hang on close problem was cause by things not getting destroyed in
the reverse order in which they were created. Keeping the threads properly
in sync seems to work better when cleaning up in reverse order.

I've verified these fixes on the systems I have available, but would appreciate
it if some of the folks contributing to the threads in these bugs could also
confirm that it works for them. Packages are available at

http://www4.netsweng.com/~anderson/video/

or

deb http://www.netsweng.com/~anderson/video/ binary/



 Stuart

Stuart R. Anderson   [EMAIL PROTECTED]
Network & Software Engineering   http://www.netsweng.com/
1024D/37A79149:  0791 D3B8 9A4C 2CDC A31F
  BD03 0A62 E534 37A7 9149


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#356736: The patch for the fixes

[Stuart Anderson]

Ooops. I meant to attach the patch to my previous message. Here are the
changes I made.


Stuart

Stuart R. Anderson   [EMAIL PROTECTED]
Network & Software Engineering   http://www.netsweng.com/
1024D/37A79149:  0791 D3B8 9A4C 2CDC A31F
 BD03 0A62 E534 37A7 91490a1,19
> --- pornview-0.2pre1.orig/src/browser.c
> +++ pornview-0.2pre1/src/browser.c
> @@ -138,6 +138,7 @@
>  browser->window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
>  gtk_window_set_title (GTK_WINDOW (browser->window), "PornView");
>  gtk_widget_realize (browser->window);
> +gtk_widget_show (browser->window);
>  
>  icon_pix =
>   gdk_pixmap_create_from_xpm_d (G_WINDOW (browser->window), &icon_mask,
> @@ -207,7 +208,7 @@
>NULL);
>  
>  hpaned = gedo_hpaned_new ();
> -gtk_container_add (GTK_CONTAINER (vbox), hpaned);
> +gtk_box_pack_start (GTK_BOX (vbox), hpaned, TRUE, TRUE, 0);
>  gtk_widget_show (hpaned);
>  
>  vpaned = gedo_vpaned_new ();
89c108,146
< @@ -632,7 +632,7 @@
---
> @@ -519,7 +519,16 @@
>   return;
>  }
>  
> +/*
> + * SRA: 2006/05/26
> + * Don't lock this here. The OpenGL video plugin creates another thread
> + * and uses XLockDisplay() from within it while initializing the plugin.
> + * If we lock the displsy here, then the plugin initialization will hang.
> + * Note that the xine thread doesn't get started until after this was
> + * unlocked anyway, so this is probably safe. If not, then we need a lock
> + * at a higher level anyway.
>  XLockDisplay (this->display);
> + */
>  
>  this->screen = DefaultScreen (this->display);
>  
> @@ -568,7 +577,11 @@
>  this->gc = XCreateGC (this->display, this->video_window,
> (GCForeground | GCBackground), &values);
>  
> +/*
> + * SRA: 2006/05/26
> + * See above.
>  XUnlockDisplay (this->display);
> +*/
>  
>  /*
>   * create mouse cursors
> @@ -623,19 +636,19 @@
>  this->stream = NULL;
>  
>  /*
> - * stop event thread 
> - */
> -pthread_cancel (this->thread);
> -
> -/*
>   * kill the drivers 
98c155,163
< @@ -1920,7 +1920,7 @@
---
> + * stop event thread 
> + */
> +pthread_cancel (this->thread);
> +
> +/*
>   * save configuration 
>   */
>  printf ("gtkxine: saving configuration...\n");
> @@ -1920,7 +1933,7 @@
121c186,199
< @@ -0,0 +1,97 @@
---
> @@ -0,0 +1,110 @@
> +pornview (0.2pre1-6) unstable; urgency=low
> +
> +  * Fix a segv when starting up (Closes: #345100) 
> +  * Tear down the xine instance in the reverse order that it was built to 
> keep
> +thread managment sane. (Closes: #288202) 
> +  * The opengl xine plugin starts upa thread and uses XLockDisplay(). Avoid
> +locking it in gtk_xine_realize() to prevent the hang on startup. This
> +should be OK since the xine thread isn't created until after the display
> +was unlocked anyway. If this ends up just moving the problem, a higher
> +level lock may be needed. (Closes: #356736)
> +
> + -- Stuart R. Anderson <[EMAIL PROTECTED]>  Fri, 26 May 2006 08:17:31 -0400
> +