Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1642729 - vlc crashes when trying to open Universal Plug'n'Play stream
Summary: vlc crashes when trying to open Universal Plug'n'Play stream
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libupnp
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nicolas Chauvet (kwizart)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1664767 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-24 22:00 UTC by Jonathan Dieter
Modified: 2019-01-13 02:31 UTC (History)
5 users (show)

Fixed In Version: libupnp-1.8.4-1.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-13 02:31:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Partial logs (3.38 KB, text/plain)
2018-10-24 22:00 UTC, Jonathan Dieter
no flags Details
core_backtrace (25.09 KB, text/plain)
2018-10-25 18:32 UTC, Jonathan Dieter
no flags Details
Return pointer rather than pointer to pointer (501 bytes, patch)
2018-10-27 20:44 UTC, Jonathan Dieter
no flags Details | Diff

Description Jonathan Dieter 2018-10-24 22:00:55 UTC
Created attachment 1497245 [details]
Partial logs

Description of problem:
vlc crashes whenever I try to open a uPnP stream, pointing at a problem in UpnpString_get_String in libupnp.

Version-Release number of selected component (if applicable):
libupnp-1.8.3-3.fc29

How reproducible:
Always

Steps to Reproduce:
1. Open a uPnP stream in vlc
2. Wait a few seconds
3.

Actual results:
vlc crashes

Expected results:
uPnP stream opens

Additional info:
The uPnP streams are provided by Kodi on a Fedora 28 system.

Downgrading libupnp to 1.6.25 and rebuilding vlc against that version fixes the problem.

Comment 1 Nicolas Chauvet (kwizart) 2018-10-25 09:09:47 UTC
I don't reproduce with vlc from rpmfusion and kodi (both on f29).
I confirm that I can browse upnp and mDNS content

Can you submit a stacktrace ?

Comment 2 Jonathan Dieter 2018-10-25 18:32:06 UTC
Created attachment 1497542 [details]
core_backtrace

Here's core_backtrace from abrt.  I could also submit the coredump, but I'd rather send that to you directly as it has personal data in it.

Comment 3 Jonathan Dieter 2018-10-27 20:44:01 UTC
Created attachment 1498108 [details]
Return pointer rather than pointer to pointer

Ok, I spent a couple of hours on this this evening and I've tracked it down to this:  in ssdp_ctrlpt.c, we return the address of param to the callback, but param is already a pointer.  Returning param rather than the address of param fixes the crashes on my system.

I've build an updated rpm with this patch at:
https://www.jdieter.net/downloads/libupnp-1.8.3-4.fc29.src.rpm

Comment 4 Jonathan Dieter 2018-10-27 20:50:58 UTC
FWIW, I've just looked at the code in 1.6.25 (the older version of libupnp), and param is allocated off the stack there rather than being a pointer, so this looks like someone forgot to change how the callback is called.

Comment 5 Nicolas Chauvet (kwizart) 2018-11-05 11:03:41 UTC
/me is back from vacation

@Jonathan
Can you forward this upstream directly if not done already ?
Thx

Comment 6 Jonathan Dieter 2018-11-05 16:48:38 UTC
@kwizart, I'm happy to report this, but where exactly *is* upstream?  https://sourceforge.net/p/pupnp/bugs doesn't look very promising.  Is there a better place to file this?

Comment 7 Jean-Francois Dockes 2018-12-07 20:35:30 UTC
I think that the sourceforge.net project is still more or less monitored, but the center of libupnp activity is currently https://github.com/mrjimenez/pupnp

Comment 8 Jonathan Dieter 2018-12-09 21:56:44 UTC
(In reply to Jean-Francois Dockes from comment #7)
> I think that the sourceforge.net project is still more or less monitored,
> but the center of libupnp activity is currently
> https://github.com/mrjimenez/pupnp

Thanks for pointing me to this.  Apparently this was fixed upstream in August and the patch is in 1.8.4, which was released at the end of October.  Nicolas, is there any chance we could get an update to 1.8.4?

Comment 9 Nicolas Chauvet (kwizart) 2019-01-07 08:31:01 UTC
...
> Thanks for pointing me to this.  Apparently this was fixed upstream in
> August and the patch is in 1.8.4, which was released at the end of October. 
> Nicolas, is there any chance we could get an update to 1.8.4?
Please apply to co-maintainer, I'm not using upnp at all myself

Comment 10 Jonathan Dieter 2019-01-07 19:05:21 UTC
(In reply to Nicolas Chauvet (kwizart) from comment #9)
> ...
> > Thanks for pointing me to this.  Apparently this was fixed upstream in
> > August and the patch is in 1.8.4, which was released at the end of October. 
> > Nicolas, is there any chance we could get an update to 1.8.4?
> 
> Please apply to co-maintainer, I'm not using upnp at all myself

Thanks for adding me.  I've put together 1.8.4, but there's a so-name bump that comes with it (it should have come with 1.8.3, but they missed it there).  I've never pushed a library with a so-name bump before, so I want to make sure I get this right.  Should I just put out a so-name bump announcement on both the Fedora and RPM Fusion mailing lists?  What about pushing out an update to F29?  Is there some documentation on this part of the process that I should be following?

The Fedora packages that depend on libupnp are:
gerbera
linphone
linphone-mediastreamer

The RPM Fusion packages that depend on libupnp are:
amule
amule-nogui
mpd
vlc-core

Comment 11 Nicolas Chauvet (kwizart) 2019-01-07 20:44:05 UTC
A soname bump in rawhide (f30) is appropriate (then there is a need for an announcement there)

But for f29 since there is a no ABI changes I would say that reverting the ABI bump could be more appropriate here. As the ABI won't change between 1.8.3 and 1.8.4, only SO number. (this would need to be verified with rpmsodiff or abigail).
Maybe it could even be possible to coordinate and allow to keep the ABI number for f29 also. (I don't know what folk in #fedora-devel would say. But according to the guideline, it's forbidden).

Comment 12 Nicolas Chauvet (kwizart) 2019-01-08 14:49:21 UTC
Okay, so I went ahead and made the update with the SONAME reverted to the one in fc29's libupnp 1.8.3 for both rawhide and f29.

Please confirm usability.
(also it seems like a recent update broke vlc, I suspect qt5 update to 5.11.3), but there are also few issue on the vlc side.
Please try to reproduce with vlc-3.0.5-14.fc29 at least
(http://koji.rpmfusion.org/koji/taskinfo?taskID=286234)

Comment 13 Fedora Update System 2019-01-08 15:10:53 UTC
libupnp-1.8.4-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2bdfbe1908

Comment 14 Jonathan Dieter 2019-01-08 19:48:09 UTC
I've tested it with vlc-3.0.5-14 and it's working perfectly in F29.  I've left feedback in Bodhi.  Thanks so much!

Comment 15 Nicolas Chauvet (kwizart) 2019-01-09 17:13:53 UTC
*** Bug 1664767 has been marked as a duplicate of this bug. ***

Comment 16 Fedora Update System 2019-01-10 22:14:59 UTC
libupnp-1.8.4-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2bdfbe1908

Comment 17 Fedora Update System 2019-01-13 02:31:10 UTC
libupnp-1.8.4-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.