GNOME Bugzilla – Bug 683668
Segfault in `/usr/lib/opal-3.10.4/codecs/video/mpeg4_ffmpeg_ptplugin.so` after quitting video call
Last modified: 2013-01-12 14:19:39 UTC
This is Debian bug report #684999 [1]. ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x72606)[0x7f78e839b606] /usr/lib/x86_64-linux-gnu/libavutil.so.51(av_freep+0xc)[0x7f78d711433c] /usr/lib/x86_64-linux-gnu/libavutil.so.51(av_opt_free+0x3c)[0x7f78d7114a7c] /usr/lib/x86_64-linux-gnu/libavcodec.so.53(avcodec_close+0xf5)[0x7f78d738bd9d] /usr/lib/opal-3.10.4/codecs/video/mpeg4_ffmpeg_ptplugin.so(_ZN13FFMPEGLibrary12AvcodecCloseEP14AVCodecContext+0x38)[0x7f78d8609e50] /usr/lib/opal-3.10.4/codecs/video/mpeg4_ffmpeg_ptplugin.so(_ZN19MPEG4EncoderContext10CloseCodecEv+0x50)[0x7f78d8603794] /usr/lib/opal-3.10.4/codecs/video/mpeg4_ffmpeg_ptplugin.so(_ZN19MPEG4EncoderContextD1Ev+0x19)[0x7f78d86026b7] /usr/lib/opal-3.10.4/codecs/video/mpeg4_ffmpeg_ptplugin.so(+0xa058)[0x7f78d8605058] /usr/lib/libopal.so.3.10.4(_ZN20OpalPluginTranscoderD1Ev+0x4a)[0x7f78eb1c9cee] /usr/lib/libopal.so.3.10.4(_ZN25OpalPluginVideoTranscoderD1Ev+0x78)[0x7f78eb1cad30] /usr/lib/libopal.so.3.10.4(_ZN25OpalPluginVideoTranscoderD0Ev+0x18)[0x7f78eb1cadbe] /usr/lib/libopal.so.3.10.4(_ZN14OpalMediaPatch4SinkD1Ev+0x4b)[0x7f78eacfb12d] /usr/lib/libopal.so.3.10.4(_ZN14OpalMediaPatch4SinkD0Ev+0x18)[0x7f78eacfb25c] /usr/lib/libpt.so.2.10.4(_ZN13PAbstractList13RemoveElementEP12PListElement+0xc4)[0x7f78ea25938a] /usr/lib/libpt.so.2.10.4(_ZN13PAbstractList6RemoveEPK7PObject+0x45)[0x7f78ea25945d] /usr/lib/libopal.so.3.10.4(_ZN5PListIN14OpalMediaPatch4SinkEE5eraseERKNS2_8iteratorE+0x3c)[0x7f78eacff786] /usr/lib/libopal.so.3.10.4(_ZN14OpalMediaPatch10RemoveSinkERK8PSafePtrI15OpalMediaStream12PSafePtrBaseE+0x125)[0x7f78eacfa973] /usr/lib/libopal.so.3.10.4(_ZN15OpalMediaStream5CloseEv+0x212)[0x7f78eacf2c62] /usr/lib/libopal.so.3.10.4(_ZN18OpalRTPMediaStream5CloseEv+0xc1)[0x7f78eacf493b] /usr/lib/libopal.so.3.10.4(_ZN14OpalMediaPatch5CloseEv+0x14b)[0x7f78eacf9503] /usr/lib/libopal.so.3.10.4(_ZN15OpalMediaStream5CloseEv+0x251)[0x7f78eacf2ca1] /usr/lib/libopal.so.3.10.4(_ZN20OpalVideoMediaStream5CloseEv+0x18)[0x7f78eacf6e48] /usr/lib/libopal.so.3.10.4(_ZN14OpalConnection16CloseMediaStreamER15OpalMediaStream+0x27)[0x7f78eacc60cb] /usr/lib/libopal.so.3.10.4(_ZN14OpalConnection17CloseMediaStreamsEv+0x84)[0x7f78eacc62e4] /usr/lib/libopal.so.3.10.4(_ZN14OpalConnection10OnReleasedEv+0x7c)[0x7f78eacc439a] /usr/lib/libopal.so.3.10.4(_ZN14OpalConnection7ReleaseENS_13CallEndReasonE+0x1df)[0x7f78eacc40e1] /usr/lib/libopal.so.3.10.4(_ZN8OpalCall5ClearEN14OpalConnection13CallEndReasonEP10PSyncPoint+0x1a0)[0x7f78eacd8bbe] ekiga(_ZN4Opal4Call6hangupEv+0x3a)[0x59efaa] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x11a03)[0x7f78e9373a03] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x6f6)[0x7f78e938c076] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_by_name+0x500)[0x7f78e938cdd0] [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684999
dpkg -l libavcodec53 libavutil51 libc6 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii libavcodec53 7:0.10.3-dmo1 Library to encode decode multimedia streams ii libavutil51 7:0.11.1-dmo4 FFmpeg avutil library - runtime files ii libc6 2.13-21 Embedded GNU C Library: Shared libraries so the codecs (ffmpeg) are from debian-multimedia, but that shouldn't make any odds. no, i believe the problem to be in opal 3.10 because i've tried openphone from opal's latest svn, and it works absolutely fine. even when i tried openphone from the opal 3.10.4 tarball release, that *still* segfaulted. every application using opal 3.10.4, whether it be qt-based, gtk-based, wxwidgets-based (in the case of openphone), has been unstable. so i believe it may be worthwhile attempting to compile ekiga from latest svn and updating it to opal 3.11alpha2 and see how it goes. unfortunately it will need updating: i tried recently and got build errors.
A new release will be updated very soon, ekiga 3.9.90, please try it and tell if the bug is still there (it is very probably fixed). I notice that you do not use debian official libavcodec. Why? Using debian-multimedia might lead to problems, as far as I know.
> A new release will be updated very soon, ekiga 3.9.90, please try it and tell > if the bug is still there (it is very probably fixed). ok - which revision of opal and ptlib are used? unless it is opal 3.11 there is no point in trying. i know for a fact from prior testing that opal 3.10.6 does not work. only opal from latest svn (marked as of 8 or so days ago as 3.11alpha2) works. > I notice that you do not use debian official libavcodec. Why? numerous codecs are not available otherwise. H.264 and so on cannot be qualified even as "non-free" and so are removed entirely.
(In reply to comment #3) > > A new release will be updated very soon, ekiga 3.9.90, please try it and tell > > if the bug is still there (it is very probably fixed). > > ok - which revision of opal and ptlib are used? unless it is opal > 3.11 there is no point in trying. i know for a fact from prior > testing that opal 3.10.6 does not work. only opal from latest svn > (marked as of 8 or so days ago as 3.11alpha2) works. Eugen uploaded new packages to Debian experimental [1]. This includes OPAL 3.10.5 [1], which according to Eugen fix the reported problems in connection with newer ptlib and Ekiga. Eugen in your message to the release team [1], you do not explicitly mention the OPAL versions which confused me. (Also a libopal package would be nice depending on the latest libopa version.) > > I notice that you do not use debian official libavcodec. Why? > > numerous codecs are not available otherwise. H.264 and so on > cannot be qualified even as "non-free" and so are removed entirely. I thought it includes x264 to decode and encode H.264? But I have not looked into it. If you have test systems it would be great if you could test with the official Debian libav packages, because at least the trace you posted points to a bug in your libav packages. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685880 [2] http://packages.debian.org/experimental/libopal3.10.5
(In reply to comment #3) > > A new release will be updated very soon, ekiga 3.9.90, please try it and tell > > if the bug is still there (it is very probably fixed). > > ok - which revision of opal and ptlib are used? unless it is opal > 3.11 there is no point in trying. i know for a fact from prior > testing that opal 3.10.6 does not work. only opal from latest svn > (marked as of 8 or so days ago as 3.11alpha2) works. In debian, ptlib 3.10.7 (last stable release) is in experimental. opal and ekiga will follow (opal is already in NEW, but needs an update). > > I notice that you do not use debian official libavcodec. Why? > > numerous codecs are not available otherwise. H.264 and so on > cannot be qualified even as "non-free" and so are removed entirely. No, they have been available in debian official since a few months!! Note also that ekiga master needs to be built with ptlib/opal stable branches (not trunk), cf. http://wiki.ekiga.org/index.php/Download_Ekiga_sources So I propose to wait until ekiga appears in experimental and check that this bug is fixed.
(In reply to comment #4) > (In reply to comment #3) > Eugen uploaded new packages to Debian experimental [1]. This includes OPAL > 3.10.5 [1], which according to Eugen fix the reported problems in connection > with newer ptlib and Ekiga. > > Eugen in your message to the release team [1], you do not explicitly mention > the OPAL versions which confused me. You are right. Note that it is about opal 3.10.7 (currently in NEW), not .5. > I thought it includes x264 to decode and encode H.264? But I have not looked > into it. If you have test systems it would be great if you could test with the > official Debian libav packages, because at least the trace you posted points to > a bug in your libav packages. The current opal upload in NEW does not have libavcodec-dev and libx264-dev in Build-Depends. I added them, and asked Mark to do a new upload of opal. There is no need to test them, I am sure that those codecs work. I propose to just wait until they appear in experimental.
as i have already tested opal 3.10.7 and found that with openphone and opalmcu, opal 3.10.7 completely fails to interoperate (that's openphone from 3.10.7 connecting with opalmcu from 3.10.7) i am *not* going to spend *any* time or resources on this until opal 3.11 is released. i repeat: i tested *every* single release of opal from sourceforge - i downloaded absolutely all of them - as far back as 3.8 and could not find a *single* release that was stable enough for even their own test client and their own test server to actually do videoconferencing. in desperation and with a sense of incredulity, i downloaded the latest svn... and it worked. opal 3.11 direct from the latest svn as of about 10 days ago was the *only* version of opal that actually worked.
(In reply to comment #7) > as i have already tested opal 3.10.7 and found that with openphone and opalmcu, > opal 3.10.7 completely fails to interoperate (that's openphone from 3.10.7 > connecting with opalmcu from 3.10.7) I did not know that 3.10 series do not work with openphone and opalmcu, I suppose this is a major problem. Have you informed about that on opalvoip mailing list or on voip bugzilla? I do not remember having done that. > i repeat: i tested *every* single release of opal from sourceforge - i > downloaded absolutely all of them - as far back as 3.8 and could not find a > *single* release that was stable enough for even their own test client and > their own test server to actually do videoconferencing. What does it mean stable? Here, 3.10.7 is sufficiently stable here. > in desperation and with a sense of incredulity, i downloaded the latest svn... > and it worked. > > opal 3.11 direct from the latest svn as of about 10 days ago was the *only* > version of opal that actually worked. Unfortunately, trunk (3.11) is too unstable for ekiga to be based on, so we decided to base ekiga on stable branches. If you really need ekiga with 3.11, there is a small patch I have for a few function renaming. But beware that nobody has tested ekiga with opal trunk!
(In reply to comment #8) > (In reply to comment #7) > > as i have already tested opal 3.10.7 and found that with openphone and opalmcu, > > opal 3.10.7 completely fails to interoperate (that's openphone from 3.10.7 > > connecting with opalmcu from 3.10.7) > > I did not know that 3.10 series do not work with openphone and opalmcu, I > suppose this is a major problem. Have you informed about that on opalvoip > mailing list or on voip bugzilla? I do not remember having done that. i've been discussing it with the opalvoip developers. robert i think his name is. i fixed macosx audio in opal 3.11 about 10 days ago; i'm still psyching myself up to tackle video :) btw ekiga will benefit from that if it has a macosx compile option. certainly on darwinports that would potentially work. > > i repeat: i tested *every* single release of opal from sourceforge - i > > downloaded absolutely all of them - as far back as 3.8 and could not find a > > *single* release that was stable enough for even their own test client and > > their own test server to actually do videoconferencing. > > What does it mean stable? Here, 3.10.7 is sufficiently stable here. try compiling up opalmcu (it's in the samples directory of each opalmcu distribution) and connect to it with at least two instances, preferably 3, of ekiga. remember to check videoconferencing capabilities, and also try using the different CODECs (H.261, H.263, H.263+ and H.264 at least). if it works i will be absolute flat-out amazed. remember: if you see segfaults in opalmcu, it means that there's something wrong with libopal and that has stability implications for ekiga because they use the same library. likewise vice-versa. > > in desperation and with a sense of incredulity, i downloaded the latest svn... > > and it worked. > > > > opal 3.11 direct from the latest svn as of about 10 days ago was the *only* > > version of opal that actually worked. > > Unfortunately, trunk (3.11) is too unstable for ekiga to be based on, so we > decided to base ekiga on stable branches. If you really need ekiga with 3.11, > there is a small patch I have for a few function renaming. But beware that > nobody has tested ekiga with opal trunk! i've decided instead to focus on using openphone, for now, and to work on getting video capabilities into opal for macosx. the reason for that is because i need a solution that works and is easy to maintain and stands a chance of interoperability across all 3 platforms - macosx, w32 and linux. if however ekiga turns out a macosx port that is easy to install i.e. is just a .dmg download for people then you could well change my mind for me. but for now, by choosing to go with openphone+opalmcu, if i get a working stable combination i can stick with it and have confidence that it's going to stay working.
Please test with ekiga 4.0.0 and open a new bug report if there is still an issue.