Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Hang in DviDevice::Destroy
22-07-2012, 07:37 PM (This post was last modified: 22-07-2012 07:38 PM by bubbleguuum.)
Post: #11
RE: Hang in DviDevice::Destroy
This may help explaining what happens:

http://mailinglists.945824.n3.nabble.com...93781.html
Find all posts by this user
22-07-2012, 08:10 PM
Post: #12
RE: Hang in DviDevice::Destroy
(22-07-2012 07:33 PM)simoncn Wrote:  I've had confirmation that nothing was happening on the Parallels adapters at the time of the destroy() call.

Another Mac user has reported the same problem with additional adapters created by VMware Fusion.

At the risk of showing up my lack of knowledge about mac, how do you know nothing was happening on the Parallels adapter? If the client app doesn't select a specific subnet then ohNet will try to operate on every subnet returned by getifaddrs.

On Windows, the only way to exclude an adapter would be to explicitly disable it in the network settings. Has your user done something like this or does he mean that he isn't deliberately using the Parallels adapter?
Find all posts by this user
22-07-2012, 08:13 PM
Post: #13
RE: Hang in DviDevice::Destroy
(22-07-2012 07:37 PM)bubbleguuum Wrote:  This may help explaining what happens:

http://mailinglists.945824.n3.nabble.com...93781.html

Thanks, this looks like a very useful change to make.

It won't fix the underlying bug but might make it far harder to reproduce (you'd need a mac with two network cards, both active and on different subnets, to reproduce the hang if we excluded VMs etc. As an added bonus, It'd also make any subnet selection UI far simpler.
Find all posts by this user
22-07-2012, 10:08 PM (This post was last modified: 22-07-2012 10:12 PM by simoncn.)
Post: #14
RE: Hang in DviDevice::Destroy
(22-07-2012 08:10 PM)simonc Wrote:  
(22-07-2012 07:33 PM)simoncn Wrote:  I've had confirmation that nothing was happening on the Parallels adapters at the time of the destroy() call.

Another Mac user has reported the same problem with additional adapters created by VMware Fusion.

At the risk of showing up my lack of knowledge about mac, how do you know nothing was happening on the Parallels adapter? If the client app doesn't select a specific subnet then ohNet will try to operate on every subnet returned by getifaddrs.

On Windows, the only way to exclude an adapter would be to explicitly disable it in the network settings. Has your user done something like this or does he mean that he isn't deliberately using the Parallels adapter?

Perhaps my wording wasn't very clear. At the time of the hang, he's not running anything in Parallels. He's just using MinimServer and ohNet. So nothing else is happening on these adapters except what ohNet and MinimServer are doing with them.
(22-07-2012 08:13 PM)simonc Wrote:  
(22-07-2012 07:37 PM)bubbleguuum Wrote:  This may help explaining what happens:

http://mailinglists.945824.n3.nabble.com...93781.html

Thanks, this looks like a very useful change to make.

It won't fix the underlying bug but might make it far harder to reproduce (you'd need a mac with two network cards, both active and on different subnets, to reproduce the hang if we excluded VMs etc.

As I said in an earlier post, the hang doesn't occur with two real active network cards on different subnets.

Quote:As an added bonus, It'd also make any subnet selection UI far simpler.

Which UI are you referring to? I wasn't aware that ohNet has a UI.
Find all posts by this user
23-07-2012, 08:21 AM (This post was last modified: 23-07-2012 08:21 AM by simonc.)
Post: #15
RE: Hang in DviDevice::Destroy
(22-07-2012 10:08 PM)simoncn Wrote:  
(22-07-2012 08:13 PM)simonc Wrote:  As an added bonus, It'd also make any subnet selection UI far simpler.

Which UI are you referring to? I wasn't aware that ohNet has a UI.

ohNet doesn't have any UI. Many users of the device stack (Songcast and Songbox for example) provide an adapter selection UI. This can be confusing for many users so it'd be nice to reduce the prominence of this user option.
Find all posts by this user
23-07-2012, 04:31 PM
Post: #16
RE: Hang in DviDevice::Destroy
I've committed fixes for system time jumping backwards or subnet changes while byebyes are being sent. I'm sure they won't make any difference here but can you humour me and confirm this please?

After some discussion, we don't propose hiding network adapters for Parallels or VMs. We assume a tiny number of users are running apps which use ohNet over these virtual adapters; there'd be no way for them to workaround ohNet ignoring them. We'll obviously review this if we can't make progress towards fixing the hang.
Find all posts by this user
23-07-2012, 06:49 PM (This post was last modified: 23-07-2012 06:53 PM by simoncn.)
Post: #17
RE: Hang in DviDevice::Destroy
(23-07-2012 04:31 PM)simonc Wrote:  I've committed fixes for system time jumping backwards or subnet changes while byebyes are being sent. I'm sure they won't make any difference here but can you humour me and confirm this please?

After some discussion, we don't propose hiding network adapters for Parallels or VMs. We assume a tiny number of users are running apps which use ohNet over these virtual adapters; there'd be no way for them to workaround ohNet ignoring them. We'll obviously review this if we can't make progress towards fixing the hang.

I'll install a trial verison of Parallels and try to reproduce this hang myself.

At the moment, my impression is that the additional adapters can't be used successfully from Mac OS X, but can only be used from Windows running under Parallels. If this is the case, it wouldn't do any harm to ignore these adapters in the Mac OS X environment.

When I have Parallels/Windows installed and running, I should be able to confirm whether these adapters are usable from Mac OS X, and also (hopefully) debug the cause of the hang. I'm expecting that this will take me a few days (at least).
(23-07-2012 08:21 AM)simonc Wrote:  ohNet doesn't have any UI. Many users of the device stack (Songcast and Songbox for example) provide an adapter selection UI. This can be confusing for many users so it'd be nice to reduce the prominence of this user option.

It's my understanding that this only applies to the control point stack. Is there any way for a device to select which adapters are used? If so, I should be able to work around this problem in MinimServer by deselecting the Parallels adapters.
Find all posts by this user
23-07-2012, 08:02 PM
Post: #18
RE: Hang in DviDevice::Destroy
(23-07-2012 06:49 PM)simoncn Wrote:  
(23-07-2012 04:31 PM)simonc Wrote:  I've committed fixes for system time jumping backwards or subnet changes while byebyes are being sent. I'm sure they won't make any difference here but can you humour me and confirm this please?

I'll install a trial verison of Parallels and try to reproduce this hang myself.

At the moment, my impression is that the additional adapters can't be used successfully from Mac OS X, but can only be used from Windows running under Parallels. If this is the case, it wouldn't do any harm to ignore these adapters in the Mac OS X environment.

When I have Parallels/Windows installed and running, I should be able to confirm whether these adapters are usable from Mac OS X, and also (hopefully) debug the cause of the hang. I'm expecting that this will take me a few days (at least).

Ok, thanks. I think I've spotted the problem now; if I'm correct one of my earlier changes will have fixed it. It'd be great to have this confirmed.

(23-07-2012 06:49 PM)simoncn Wrote:  
(23-07-2012 08:21 AM)simonc Wrote:  ohNet doesn't have any UI. Many users of the device stack (Songcast and Songbox for example) provide an adapter selection UI. This can be confusing for many users so it'd be nice to reduce the prominence of this user option.

It's my understanding that this only applies to the control point stack. Is there any way for a device to select which adapters are used? If so, I should be able to work around this problem in MinimServer by deselecting the Parallels adapters.

The device stack defaults to running on all subnets but can be told to run on a single client-selected one. You can call Library.setCurrentSubnet to select a single subnet.
Find all posts by this user
23-07-2012, 10:14 PM
Post: #19
RE: Hang in DviDevice::Destroy
(23-07-2012 08:02 PM)simonc Wrote:  Ok, thanks. I think I've spotted the problem now; if I'm correct one of my earlier changes will have fixed it. It'd be great to have this confirmed.

I've reproduced the hang on my Mac.

I'm looking at Github, and the last two commits I see are a change for clock drift followed by another commit to revert the first one. I presume this isn't the earlier change you're referring to. Please confirm when the fix is on Github, and I'll try it.
Find all posts by this user
24-07-2012, 07:43 AM
Post: #20
RE: Hang in DviDevice::Destroy
(23-07-2012 10:14 PM)simoncn Wrote:  I'm looking at Github, and the last two commits I see are a change for clock drift followed by another commit to revert the first one. I presume this isn't the earlier change you're referring to. Please confirm when the fix is on Github, and I'll try it.

Looks like last night's release failed. I'm off today so won't be able to look at it immediately. If the failure was transient, the push might complete this evening; otherwise I'll do it tomorrow. I'll let you know when the code is there.
Find all posts by this user


Forum Jump: