search

philippe44 / AirConnect

Use AirPlay to stream to UPnP/Sonos & Chromecast devices
Other
3.5k stars 216 forks source link

Core dump with airupnp-arm '-o' option ("XMLGetFirstDocumentItem:1390 (BUG) ixmlNode_getFirstChild(tmpNode) returned NULL") #286

Closed pwt closed 3 years ago

pwt commented 3 years ago

Hi Philippe: I wonder if you can help with this.

In one particular network environment, airupnp-arm is crashing reliably when used with the -o option, as described below. I suspect it's something to do with the devices on that particular network.

  1. If I just run airupnp-arm, I get the following output and the program continues to run:
# ./airupnp-arm
[14:28:48.844462] main:1386 Starting airupnp version: v0.2.28.0 (Oct 22 2020 @ 23:04:32)
[14:28:48.844734] main:1394 no config file, using defaults
[14:28:48.898463] Start:1104 Binding to 192.168.87.193:49152
[14:28:48.918474] XMLGetFirstDocumentItem:1390 (BUG) ixmlNode_getFirstChild(tmpNode) returned NULL
[14:28:48.918601] XMLGetFirstDocumentItem:1390 (BUG) ixmlNode_getFirstChild(tmpNode) returned NULL
[14:28:48.926337] AddMRDevice:992 [0xf3456008]: adding renderer (55PUS6803/12)
[14:28:48.934040] MasterHandler:656 [0xf3456008]: subscribe success
[14:28:49.323491] AddMRDevice:992 [0xf3458450]: adding renderer (Stue)
[14:28:49.336875] MasterHandler:656 [0xf3458450]: subscribe success
[14:28:49.430132] AddMRDevice:990 [0xf345a898] skipping Sonos slave Køkken
[14:28:49.440601] MasterHandler:656 [0xf345a898]: subscribe success
[14:28:49.742974] AddMRDevice:992 [0xf345cce0]: adding renderer (SONY HT-ST9)
[14:28:49.754171] MasterHandler:656 [0xf345cce0]: subscribe success
^C[14:28:56.844566] Stop:1167 terminate update thread ...
[14:28:56.845056] Stop:1172 flush renderers ...
[14:28:56.849186] Stop:1175 terminate libupnp
[14:28:57.360822] Stop:1194 terminate main thread ..
#
  1. However, if I run using the -o option to specify which device model number(s) I want to include, I get a core dump every time:
# ./airupnp-arm -o S12
[14:29:15.389366] main:1386 Starting airupnp version: v0.2.28.0 (Oct 22 2020 @ 23:04:32)
[14:29:15.389645] main:1394 no config file, using defaults
[14:29:15.393180] Start:1104 Binding to 192.168.87.193:49153
[14:29:15.411801] XMLGetFirstDocumentItem:1390 (BUG) ixmlNode_getFirstChild(tmpNode) returned NULL
[14:29:15.411964] XMLGetFirstDocumentItem:1390 (BUG) ixmlNode_getFirstChild(tmpNode) returned NULL
Segmentation fault (core dumped)
#

It doesn't matter what I specify after the -o: same result. The issue doesn't occur with the -m and -n options.

I've also tried v0.2.26.1, with the same result, so it's not a new issue in the code. I'll also take a look at the relevant parts of the implementation in case I see anything obvious. Let me know if I can gather any further diagnostic information for you.

Thanks, Peter

pwt commented 3 years ago

OK, this has now stopped happening on the network in question. Inconvenient. I'm sure I've seen something similar quite a while ago, on a different network: core dumps that I couldn't explain, which also stopped happening without intervention.

My hunch is that there are UPnP devices that sometimes return malformed information. So, I wonder whether the calls to XMLGetFirstDocumentItem() should be checked for a NULL return before their values are used?

I pushed up a simple PR (#287). I've built, run and tested a binary including this change, but I don't know if it actually makes any difference to the error above because of its intermittent nature.

philippe44 commented 3 years ago

I've set a fix in 0.2.28.1

pwt commented 3 years ago

Looks good -- thanks!

pwt commented 3 years ago

Let's assume that v0.2.28.1 provides the fix. Thanks to @philippe44 for the fast response.