Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Crash in DviSessionUpnp::~DviSessionUpnp()
08-10-2012, 04:15 PM
Post: #4
RE: Crash in DviSessionUpnp::~DviSessionUpnp()
(08-10-2012 04:02 PM)simoncn Wrote:  Yes, I could do this. Another option is for me to try to replicate these conditions on my NAS by starting it with the Ethernet port disconnected and then connecting the port after the ohNet device stack has been created. I'll probably try this first.

Yes, that would be useful if you could replicate the problem. I tried doing something similar on Windows (start a device stack running on all adapters with all adapters disabled, enable an adapter, watch loopback get removed and the enabled adapter added) but couldn't replicate the crash. Maybe you'll have more luck on Linux though...

(08-10-2012 04:02 PM)simoncn Wrote:  Would it also be useful to log the addition and removal of adapters? It's possible that the user scenario is more complex than you've described. The failure was reported on a NAS with a bonded failover dual connection, so the startup sequence might be somewhat unusual. For example, multiple non-loopback adapters might be added, or an adapter might be added and then removed. Where is the best place to put print statements to log adapter additions and removals?

Extra logging would be useful. If you add Debug::SetLevel(Debug::kTrace); to UpnpLibrary::Initialise you'll get a note of subnet changes. (This logging will either go to stdout or the callback you registered with InitParams.SetLogOutput)
Find all posts by this user


Messages In This Thread
RE: Crash in DviSessionUpnp::~DviSessionUpnp() - simonc - 08-10-2012 04:15 PM

Forum Jump: