After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724244 - Lync calls crash Pidgin using SIPE plugin
Lync calls crash Pidgin using SIPE plugin
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.19
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-12 17:34 UTC by Michael Cronenworth
Modified: 2014-09-03 20:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Cronenworth 2014-02-12 17:34:28 UTC
Is the 0.10 branch still receiving bug fixes?

The Pidgin SIPE plugin to connect to Microsoft Lync servers will crash if a phone call is attempted. The backtrace seems to indicate an issue in gst-plugins-ugly. You may find backtraces in the fd.o or sf.net bugs.

See these bug reports for more information:
http://sourceforge.net/p/sipe/bugs/217/
https://bugs.freedesktop.org/show_bug.cgi?id=71253
https://bugzilla.redhat.com/show_bug.cgi?id=1028784
Comment 1 Tim-Philipp Müller 2014-02-12 18:03:12 UTC
Thanks for the bug report, but as you noted in the RH bug, 0.10 is no longer maintained, and hasn't been for years now, so it's unlikely anyone will look into it.

A stack trace with debugging symbols for both libx264 and the x264enc plugin might be useful though. It seems to crash when initing the encoder, I don't remember ever having seen a problem like this. Could be a bug in GStreamer or in libx264.
Comment 2 Daniel 2014-09-02 14:46:38 UTC
(In reply to comment #1)
> Thanks for the bug report, but as you noted in the RH bug, 0.10 is no longer
> maintained, and hasn't been for years now, so it's unlikely anyone will look
> into it.
> 
> A stack trace with debugging symbols for both libx264 and the x264enc plugin
> might be useful though. It seems to crash when initing the encoder, I don't
> remember ever having seen a problem like this. Could be a bug in GStreamer or
> in libx264.


Hi T.P.,
and is there actually any action being taken in order to fix this?
Also is there perhaps any bug report opened handling your "speculation", since you closed this one?
Comment 3 Michael Cronenworth 2014-09-02 14:55:07 UTC
@Daniel, I traced the bug to farstream and created a patch to stop the crash from occurring. Since upstream has moved on from the 0.1 branch I doubt they'll apply my patch, but you're welcome to use it. It was generated against farstream 0.1.2.

https://bugzilla.redhat.com/attachment.cgi?id=925254
Comment 4 Daniel 2014-09-02 15:16:43 UTC
(In reply to comment #3)
> @Daniel, I traced the bug to farstream and created a patch to stop the crash
> from occurring. Since upstream has moved on from the 0.1 branch I doubt they'll
> apply my patch, but you're welcome to use it. It was generated against
> farstream 0.1.2.
> 
> https://bugzilla.redhat.com/attachment.cgi?id=925254


Hi,
Since I'm not a developer, I doubt it I would be able to make such tracing.
So you think it's in the farstream after all, and not in gstream?

Do you think the farstream developers will at least involve your patch to any further 2.* versions and so on?

Perhaps you also should share your findings with them https://bugs.freedesktop.org/show_bug.cgi?id=71253 , where they declined farstream's side problem.
Comment 5 Tim-Philipp Müller 2014-09-02 21:07:56 UTC
Daniel, no action is going to be taken from our side to investigate this, since it concerns a version that's two and a half years old and a major version that has been unmaintained for multiple years now. It does not make sense for us to spend resources on this, and even if we wanted to, there's not really much actionable information for us in here, sorry.
Comment 6 Daniel 2014-09-03 10:30:27 UTC
(In reply to comment #5)
> Daniel, no action is going to be taken from our side to investigate this, since
> it concerns a version that's two and a half years old and a major version that
> has been unmaintained for multiple years now. It does not make sense for us to
> spend resources on this, and even if we wanted to, there's not really much
> actionable information for us in here, sorry.


Sorry, perhaps I forgot to clarify that obsolete version detail you've spoken already before.
The problem is still present even with newer versions of gstreamer (e.g. I have the recent ver. 1.4.1 in my Arch Linux).
And despite of what has been written before, that Michael Cronenworth possibly traced that problem to the farstream, it's still not fully confirmed, I think.
However farstream developers claim https://bugs.freedesktop.org/show_bug.cgi?id=71253 , that the problem is not in farstream and point back here to gstreamer.
BUt as I'm just a simple user, I don't know who is right in this.

Therefore, because this particular bug 724244 is focusing as you said to "Version: 0.10.19", would you like us to open a new bug which would be focusing on the latest versions?
At least so that it's fully examined on your side too, so that you can throw the stick back to farstream devs.?
Comment 7 Tim-Philipp Müller 2014-09-03 15:50:57 UTC
I missed that bit about 1.4, sorry. If it's still reproducible with 1.4 then please file a new bug with the relevant updated details (I think filing a new one makes more sense than re-opening this one). Full debugging symbols for all involved libraries would be good. Perhaps also run pidgin in valgrind to see if it picks up anything.

The main problem for us is a way to reproduce this reliably, or narrow down the cause at least.
Comment 8 Daniel 2014-09-03 20:51:12 UTC
(In reply to comment #7)
> I missed that bit about 1.4, sorry. If it's still reproducible with 1.4 then
> please file a new bug with the relevant updated details (I think filing a new
> one makes more sense than re-opening this one). Full debugging symbols for all
> involved libraries would be good. Perhaps also run pidgin in valgrind to see if
> it picks up anything.
> 
> The main problem for us is a way to reproduce this reliably, or narrow down the
> cause at least.


No problem, actually that part about 1.4 wasn't mentioned before.
But since we were still talking about it in this old report, I somehow thought it was obvious.
Bug 735993 has been opened.

I'm affraid I can't provide you with that debugging details as I'm not that skilled with debugging myself.
@Michael Cronenworth: could you please perhaps share your actuall debugging findings about this problem with the guys in the new bug 735993?

thx to all of you guys.