Device.list_children() crashes minidlna on Ubuntu 14.04

[tkem]

Using test/dbus/mediaconsole.py from dleyna-server master branch on GitHub (v0.5.0), this crashes minidlna version 1.1.2, as provided with Ubuntu 14.04:

mediaconsole.Device('/com/intel/dLeynaServer/server/0').list_children(0, 0, ['Path'])

Syslog reports this:

minidlnad[1278]: segfault at 0 ip 000000000040d080 sp 00007fffa84bcdb0 error 4 in minidlnad[400000+3b000]

I'm well aware that it would probably be more appropriate to file an issue with minidlna (or ReadyMedia as it now seems to be called), but since minidlna is widely deployed and is also shipped with a variety of NETGEAR routers, and various other DLNA clients seem to work fine with it, I guess this should at least be reviewed by the dLeyna developers. If I can contribute in any way to find the cause (or even better, a workaround) for this, just let me know.

[tkem]

Update: turns out minidlna is in trusty-backports for Ubuntu 14.04.

[tkem]

Problem seems related to the filter argument not being handled correctly:

Program received signal SIGSEGV, Segmentation fault.
set_filter_flags (filter=filter@entry=0x0, h=0x6646a0) at upnpsoap.c:354
354         if (strcmp(filter, "*") == 0 && samsung) {
(gdb) bt
#0  set_filter_flags (filter=filter@entry=0x0, h=0x6646a0) at upnpsoap.c:354
#1  0x0000000000410c94 in BrowseContentDirectory (h=0x6646a0, action=<optimized out>) at upnpsoap.c:1154
#2  0x000000000040bab4 in Process_upnphttp (h=h@entry=0x6646a0) at upnphttp.c:1090
#3  0x0000000000405fa1 in main (argc=<optimized out>, argv=<optimized out>) at minidlna.c:1227
(gdb) p filter
$1 = 0x0

[jku]

It's not just more appropriate: helping fix the bug in minidlna is the best way to get dleyna compatible. At that point it would be clear what exactly triggers the problem and working around becomes possible. Currently it's basically a game of guessing.

Alternatively you could try some things blindly:

• try another filter: maybe 'Path' is not valid. Filter '*' should certainly be supported.
• test with another child count (0 is totally valid but ...)
• use e.g. wireshark to make sure the actual UPnP exchange is sensible, compare the exchange to one made with another control point

Spec for the container API is here if you're wondering: https://wiki.gnome.org/Projects/Rygel/MediaServer2Spec#org.gnome.UPnP.MediaContainer2

[tkem]

@jku: Thanks, using "*" as a filter actually seems to work!
As for reporting this to minidlna: May I kindly suggest that this is done by the dLeyna developers? I have very little knowledge of UPnP/DLNA protocols (just started learning), and I guess the dLeyna developers could provide much better input...

[jku]

Great, sometimes debug by guesswork is all it takes...

Sorry, I don't have the time to work with minidlnad now and I'm not actively involved with dleyna at the moment. In any case what you have looks quite useful already.

If you want to be really useful, find out what the upnp message that dleyna sends that crashes minidlnad looks like -- if you kill dleyna-server-service and start it by hand with "GUPNP_DEBUG=1 /path/to/dleyna-server-service" that should print out the HTTP traffic, if I still remember things correctly. That should be more than enough for minidlnad guys to reproduce -- and to also show whether dleyna sends something strange...

[tkem]

Okay, so let's hope dLeyna is still actively supported and somebody with more knowledge about this stuff than me will take care of this issue. For now, I'd like to focus on my initial goals, i.e. actually start using dLeyna ;-) But once more, thanks for your support!

[tkem]

For starters, this is the output of GUPNP_DEBUG=1 /usr/local/libexec/dleyna-server-service when calling mediaconsole.Device('/com/intel/dLeynaServer/server/0').list_children(0, 0, ['Path']):

> POST /ctl/ContentDir HTTP/1.1
> Soup-Debug-Timestamp: 1428514224
> Soup-Debug: SoupSessionAsync 1 (0x2644220), SoupMessage 16 (0x2650370), SoupSocket 16 (0x2654470)
> Host: 192.168.1.103:8200
> SOAPAction: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"
> Accept-Encoding: gzip
> Content-Type: text/xml; charset="utf-8"
> User-Agent: dLeyna/0.5.0 GUPnP/0.20.13 DLNADOC/1.50
> Connection: Keep-Alive
> 
> <?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><ObjectID>0</ObjectID><BrowseFlag>BrowseDirectChildren</BrowseFlag><Filter></Filter><StartingIndex>0</StartingIndex><RequestedCount>0</RequestedCount><SortCriteria></SortCriteria></u:Browse></s:Body></s:Envelope>

< HTTP/1.1 8 Message Corrupt
< Soup-Debug-Timestamp: 1428514224
< Soup-Debug: SoupMessage 16 (0x2650370)

As I said before, I'm no expert on these subjects, but the empty Filter tag looks suspicious to me...

[jku]

<Filter></Filter>

That looks fishy. I don't remember what the specs say but ... there should probably be a value there.

Now minidlna shouldn't crash of course but that Filter could still be a bug in dleyna.

[jku]

Actually,

1. empty string as filter does make sense (indicating that the control point just wants the default set of metadata) ... so my guess is that dleyna does the right thing by the spec (someone should check that).
2. That said, nothing prevents dleyna from setting filter to the default filter set, or at least one of the default filter values if the value would end up empty otherwise. Of course this could lead to some other buggy devices to crash...
3. I wonder why the filter "Path" gets cleared somewhere along the way... @tkem is that a valid filter for some purpose?

[tkem]

@jku: I was just kind of learning/experimenting with the dLeyna API, and I just wanted to list the paths to reduce screen clutter. So I guessed passing "Path" as filter would just do that. Also wanted to use filters straight away to reduce bandwidth in my final application, but I guess that was just premature optimization. So, no real reason, just toying around with the API.

[tkem]

BTW, this works as expected using BubbleUPnP as a media server, otherwise I would have spent more time debugging my own code.

[rsbells]

I want to make sure I understand the BubbleUPnP data point. Are you using dLeyna as the client and BubbleUPnP as DMS on server side or are use using BubbleUPnP Client APIs with BubbleUPnP DMS? The crash occurs when you are using Rygel as the DMS along with dLeyna? I have an Ubuntu 14.04 that I can setup to reproduce the issue. Please provide with the DMS (?Rygel version) and GUPnP package version you are using? Provide with all packages you installed and all the steps.

[tkem]

• I was using both minidlna and BubbleUPnP as DMS for testing my one-liner. minidlna crashes while BubbleUPnP worked fine.
• I didn't use Rygel as DMS.
• All packages were installed on current Ubuntu 14.04 using apt-get, except for dLeyna, which I compiled myself using the instruction given in 01org/dleyna-linux.

[rsbells]

So if you are using using dLeyna with BubbleUPnP as the DMS and it is not crashing and using dLeyna with minidlna as DMS and it is crashing. Sounds like an issue need minidnla to be filed but we should still look at it to see if there corner case that dLeyna is doing that BubbleUPnP handles better than miniDNLA. We want to make sure we don't have any compatibility issues with other DMS.

[tkem]

Exactly. I could have filed a bug report with minidlna myself, but I'm new to this whole DLNA stuff, and I think it would be more efficient if dLeyna developers explain to minidlna developers what is wrong.