From: SourceForge.net <no...@so...> - 2005-05-06 19:36:12
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-07 07:20:44
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-09 20:28:56
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by tmattern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-09 20:40:27
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-10 07:57:06
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Settings changed) made by tmattern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) >Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-10 07:56:37
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by tmattern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-10 11:15:07
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-10 20:38:09
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-10 21:33:44
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by tmattern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 23:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-14 22:19:57
|
Bugs item #1196819, was opened at 2005-05-06 16:36 Message generated for change (Comment added) made by miguelfreitas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Miguel Freitas (miguelfreitas) Date: 2005-05-14 19:19 Message: Logged In: YES user_id=148691 i believe i've fixed this on cvs. Thomas, may you confirm? ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 18:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 17:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 08:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 04:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 17:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 17:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 04:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-15 13:57:26
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-15 15:57 Message: Logged In: YES user_id=975532 Nope, sorry, but I have finally been able to generate a backtrace with more symbols. The code hangs in one or more threads trying to do XLock / XUnlock. I'm attaching a backtrace where the code actually hangs in an XUnlock. I've added a macro to all libviaXvMC XLocks / Unlocks as well as the xxmc plugin codes, that prints out all locking / unlocking attempts and at least that code doesn't seem responsible for not releasing a lock. However, hanging in UnLock worries me a little. (Although this is not always the case) . Makes me fear memory corruption. /Thomas ---------------------------------------------------------------------- Comment By: Miguel Freitas (miguelfreitas) Date: 2005-05-15 00:19 Message: Logged In: YES user_id=148691 i believe i've fixed this on cvs. Thomas, may you confirm? ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 23:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-15 19:28:51
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-15 21:28 Message: Logged In: YES user_id=975532 Hmm, I suggest halting the search for this bug in xine for a while: While Thibauts commit triggers it, It may well be that is just exposes another bug in libviaXvMC or libraries it depends on. If I use libviaXvMC versions prior to libdri was brought in, The deadlock doesnt't occur. I will investigate further /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 15:57 Message: Logged In: YES user_id=975532 Nope, sorry, but I have finally been able to generate a backtrace with more symbols. The code hangs in one or more threads trying to do XLock / XUnlock. I'm attaching a backtrace where the code actually hangs in an XUnlock. I've added a macro to all libviaXvMC XLocks / Unlocks as well as the xxmc plugin codes, that prints out all locking / unlocking attempts and at least that code doesn't seem responsible for not releasing a lock. However, hanging in UnLock worries me a little. (Although this is not always the case) . Makes me fear memory corruption. /Thomas ---------------------------------------------------------------------- Comment By: Miguel Freitas (miguelfreitas) Date: 2005-05-15 00:19 Message: Logged In: YES user_id=148691 i believe i've fixed this on cvs. Thomas, may you confirm? ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 23:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-16 08:30:12
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-16 10:30 Message: Logged In: YES user_id=975532 OK, I have not completely verified this, but is seems like changing the external names of the DRI utilities that libviaXvMC links to fixes the problem. I'll try to confirm tonight. It appears like, for example XF86DRIOpenConnection is also used by via_dri.so, which is used by libGL.so which is used by the OpenGL plugin (and possibly also by guis like kaffeine). Apparently xine calls any of these, but I can't immediately see how this messes up the Xlib display lock. Fixing it involves remaining those symbols that are used by libviaXvMC or convincing the xorg guys to make a small shared library out of these routines. Also, during the searching gdb tells me that libviaXvMC calls Xv routines that are statically linked with the xvmc plugin although libviaXvMC was called from the xxmc plugin, but this doesn't seem to cause any errors. Is this a side-effect of the new plugin code or just something we will have to live with? /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 21:28 Message: Logged In: YES user_id=975532 Hmm, I suggest halting the search for this bug in xine for a while: While Thibauts commit triggers it, It may well be that is just exposes another bug in libviaXvMC or libraries it depends on. If I use libviaXvMC versions prior to libdri was brought in, The deadlock doesnt't occur. I will investigate further /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 15:57 Message: Logged In: YES user_id=975532 Nope, sorry, but I have finally been able to generate a backtrace with more symbols. The code hangs in one or more threads trying to do XLock / XUnlock. I'm attaching a backtrace where the code actually hangs in an XUnlock. I've added a macro to all libviaXvMC XLocks / Unlocks as well as the xxmc plugin codes, that prints out all locking / unlocking attempts and at least that code doesn't seem responsible for not releasing a lock. However, hanging in UnLock worries me a little. (Although this is not always the case) . Makes me fear memory corruption. /Thomas ---------------------------------------------------------------------- Comment By: Miguel Freitas (miguelfreitas) Date: 2005-05-15 00:19 Message: Logged In: YES user_id=148691 i believe i've fixed this on cvs. Thomas, may you confirm? ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 23:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-05-16 10:26:22
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-05-16 12:26 Message: Logged In: YES user_id=975532 Yes, this will indeed fix the problem. However I'm leaving the bug open since I don't know wether the plugin loader behaves correctly in this case? See message below. /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-16 10:30 Message: Logged In: YES user_id=975532 OK, I have not completely verified this, but is seems like changing the external names of the DRI utilities that libviaXvMC links to fixes the problem. I'll try to confirm tonight. It appears like, for example XF86DRIOpenConnection is also used by via_dri.so, which is used by libGL.so which is used by the OpenGL plugin (and possibly also by guis like kaffeine). Apparently xine calls any of these, but I can't immediately see how this messes up the Xlib display lock. Fixing it involves remaining those symbols that are used by libviaXvMC or convincing the xorg guys to make a small shared library out of these routines. Also, during the searching gdb tells me that libviaXvMC calls Xv routines that are statically linked with the xvmc plugin although libviaXvMC was called from the xxmc plugin, but this doesn't seem to cause any errors. Is this a side-effect of the new plugin code or just something we will have to live with? /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 21:28 Message: Logged In: YES user_id=975532 Hmm, I suggest halting the search for this bug in xine for a while: While Thibauts commit triggers it, It may well be that is just exposes another bug in libviaXvMC or libraries it depends on. If I use libviaXvMC versions prior to libdri was brought in, The deadlock doesnt't occur. I will investigate further /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 15:57 Message: Logged In: YES user_id=975532 Nope, sorry, but I have finally been able to generate a backtrace with more symbols. The code hangs in one or more threads trying to do XLock / XUnlock. I'm attaching a backtrace where the code actually hangs in an XUnlock. I've added a macro to all libviaXvMC XLocks / Unlocks as well as the xxmc plugin codes, that prints out all locking / unlocking attempts and at least that code doesn't seem responsible for not releasing a lock. However, hanging in UnLock worries me a little. (Although this is not always the case) . Makes me fear memory corruption. /Thomas ---------------------------------------------------------------------- Comment By: Miguel Freitas (miguelfreitas) Date: 2005-05-15 00:19 Message: Logged In: YES user_id=148691 i believe i've fixed this on cvs. Thomas, may you confirm? ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 23:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-06-02 07:21:29
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by totte67 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thomas Hellström (totte67) Date: 2005-06-02 09:21 Message: Logged In: YES user_id=975532 Thibaut, I saw a commit referencing this bug. I have full functionality now after removing some symbols from libviaXvMC that were replicated in libraries loaded by the openGL plugin. Should this one be considered fixed? /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-16 12:26 Message: Logged In: YES user_id=975532 Yes, this will indeed fix the problem. However I'm leaving the bug open since I don't know wether the plugin loader behaves correctly in this case? See message below. /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-16 10:30 Message: Logged In: YES user_id=975532 OK, I have not completely verified this, but is seems like changing the external names of the DRI utilities that libviaXvMC links to fixes the problem. I'll try to confirm tonight. It appears like, for example XF86DRIOpenConnection is also used by via_dri.so, which is used by libGL.so which is used by the OpenGL plugin (and possibly also by guis like kaffeine). Apparently xine calls any of these, but I can't immediately see how this messes up the Xlib display lock. Fixing it involves remaining those symbols that are used by libviaXvMC or convincing the xorg guys to make a small shared library out of these routines. Also, during the searching gdb tells me that libviaXvMC calls Xv routines that are statically linked with the xvmc plugin although libviaXvMC was called from the xxmc plugin, but this doesn't seem to cause any errors. Is this a side-effect of the new plugin code or just something we will have to live with? /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 21:28 Message: Logged In: YES user_id=975532 Hmm, I suggest halting the search for this bug in xine for a while: While Thibauts commit triggers it, It may well be that is just exposes another bug in libviaXvMC or libraries it depends on. If I use libviaXvMC versions prior to libdri was brought in, The deadlock doesnt't occur. I will investigate further /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 15:57 Message: Logged In: YES user_id=975532 Nope, sorry, but I have finally been able to generate a backtrace with more symbols. The code hangs in one or more threads trying to do XLock / XUnlock. I'm attaching a backtrace where the code actually hangs in an XUnlock. I've added a macro to all libviaXvMC XLocks / Unlocks as well as the xxmc plugin codes, that prints out all locking / unlocking attempts and at least that code doesn't seem responsible for not releasing a lock. However, hanging in UnLock worries me a little. (Although this is not always the case) . Makes me fear memory corruption. /Thomas ---------------------------------------------------------------------- Comment By: Miguel Freitas (miguelfreitas) Date: 2005-05-15 00:19 Message: Logged In: YES user_id=148691 i believe i've fixed this on cvs. Thomas, may you confirm? ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 23:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-06-02 21:16:33
|
Bugs item #1196819, was opened at 2005-05-06 21:36 Message generated for change (Comment added) made by tmattern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: xine Group: current cvs version Status: Open Resolution: None Priority: 7 Submitted By: Thomas Hellström (totte67) Assigned to: Thibaut Mattern (tmattern) Summary: Deadlock at Xine startup Initial Comment: Xine deadlocks when the video_out plugin is not in-memory cached, for example after a fresh install. The deadlock started appearing after the following commit: Wed Feb 9 20:03:22 2005 UTC (2 months, 3 weeks ago) by tmattern Branch: MAIN CVS Tags: HEAD Changes since 1.22: +2 -2 lines Diff to previous 1.22 Finally commit the plugin loader improvements. see my last mail about this stuff: http://thread.gmane.org/gmane.comp.video.xine.devel/12547 and this thread: http://thread.gmane.org/gmane.comp.video.xine.devel/11213 I've so far only seen it appear with the xxmc plugin and Unichrome PM800 acceleration. I'll be around to test patches. /Thomas ---------------------------------------------------------------------- >Comment By: Thibaut Mattern (tmattern) Date: 2005-06-02 23:16 Message: Logged In: YES user_id=532851 Hi Thomas, there was 3 problems: - the plugin loader bug fixed by miguel - the libviaxvmc/opengl symbol problem fixed by you - xxmc plugin calling functions linked to the xvmc plugin sounds a bit strange, it's easy to check, launch xine -V xxmc (the xvmc plugin will not be loaded) if it works then the bug is definitely fixed Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-06-02 09:21 Message: Logged In: YES user_id=975532 Thibaut, I saw a commit referencing this bug. I have full functionality now after removing some symbols from libviaXvMC that were replicated in libraries loaded by the openGL plugin. Should this one be considered fixed? /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-16 12:26 Message: Logged In: YES user_id=975532 Yes, this will indeed fix the problem. However I'm leaving the bug open since I don't know wether the plugin loader behaves correctly in this case? See message below. /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-16 10:30 Message: Logged In: YES user_id=975532 OK, I have not completely verified this, but is seems like changing the external names of the DRI utilities that libviaXvMC links to fixes the problem. I'll try to confirm tonight. It appears like, for example XF86DRIOpenConnection is also used by via_dri.so, which is used by libGL.so which is used by the OpenGL plugin (and possibly also by guis like kaffeine). Apparently xine calls any of these, but I can't immediately see how this messes up the Xlib display lock. Fixing it involves remaining those symbols that are used by libviaXvMC or convincing the xorg guys to make a small shared library out of these routines. Also, during the searching gdb tells me that libviaXvMC calls Xv routines that are statically linked with the xvmc plugin although libviaXvMC was called from the xxmc plugin, but this doesn't seem to cause any errors. Is this a side-effect of the new plugin code or just something we will have to live with? /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 21:28 Message: Logged In: YES user_id=975532 Hmm, I suggest halting the search for this bug in xine for a while: While Thibauts commit triggers it, It may well be that is just exposes another bug in libviaXvMC or libraries it depends on. If I use libviaXvMC versions prior to libdri was brought in, The deadlock doesnt't occur. I will investigate further /Thomas ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-15 15:57 Message: Logged In: YES user_id=975532 Nope, sorry, but I have finally been able to generate a backtrace with more symbols. The code hangs in one or more threads trying to do XLock / XUnlock. I'm attaching a backtrace where the code actually hangs in an XUnlock. I've added a macro to all libviaXvMC XLocks / Unlocks as well as the xxmc plugin codes, that prints out all locking / unlocking attempts and at least that code doesn't seem responsible for not releasing a lock. However, hanging in UnLock worries me a little. (Although this is not always the case) . Makes me fear memory corruption. /Thomas ---------------------------------------------------------------------- Comment By: Miguel Freitas (miguelfreitas) Date: 2005-05-15 00:19 Message: Logged In: YES user_id=148691 i believe i've fixed this on cvs. Thomas, may you confirm? ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 23:33 Message: Logged In: YES user_id=532851 That's strange. Have you forgotten to do a "make clean" before recompiling with debug symbol ? You should also recompile xine-ui or a smaller frontend with debug symbol. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 22:38 Message: Logged In: YES user_id=975532 Hmm, I've attached a primary log. Running gdb it seems like the deadlock occurs earlier than before, The banner haven't even disappeared. Anyway, judging from the output, xine-lib doesn't provide many debugging symbols. I've compiled with make debug and installed using make install-debug Any suggestions? Log attached to the tracker item. ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-10 13:15 Message: Logged In: YES user_id=975532 OK, I'll try to fix a backtrace tonight or tomorrow. /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-10 09:56 Message: Logged In: YES user_id=532851 Hi Thomas, I mean a gdb backtrace of all threads gdb xine (gdb) handle SIG32 noprint nostop (gdb) run then press Ctrl-c when the deadlock occurs (gdb) thread apply all bt of course xine-lib must be compiled with debug symbols. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-09 22:40 Message: Logged In: YES user_id=975532 Hi, Thibaut, Do you mean the output from a --verbose=x run? /Thomas ---------------------------------------------------------------------- Comment By: Thibaut Mattern (tmattern) Date: 2005-05-09 22:28 Message: Logged In: YES user_id=532851 Hi Thomas, please provide a backtrace of the deadlock, this will help me to fix the problem. Thibaut ---------------------------------------------------------------------- Comment By: Thomas Hellström (totte67) Date: 2005-05-07 09:20 Message: Logged In: YES user_id=975532 I noticed that with this commit a dlopen() statement in the dxr3 code was changed. The xxmc code links to the XvMC wrapper which uses dlopen() extensively. Could this be related? /Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1196819&group_id=9655 |