Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Hang in DviDevice::Destroy
25-07-2012, 08:17 AM
Post: #21
RE: Hang in DviDevice::Destroy
(24-07-2012 07:43 AM)simonc Wrote:  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.

The latest code is on github now. (In case you're interested, the delay was caused an upgrade of our mac build slave to use mountain lion taking longer than expected.)
Find all posts by this user
26-07-2012, 02:59 PM
Post: #22
RE: Hang in DviDevice::Destroy
(25-07-2012 08:17 AM)simonc Wrote:  The latest code is on github now. (In case you're interested, the delay was caused an upgrade of our mac build slave to use mountain lion taking longer than expected.)

This seems to solve the problem on my Mac. I've asked a couple of MinimServer users to try it as well. Many thanks!
Find all posts by this user
27-09-2012, 08:21 AM
Post: #23
RE: Hang in DviDevice::Destroy
I saw a similar problem yesterday with a recent level of code. In this case, the hang lasted for about two minutes before the Destroy call returned. It happened just after my MacBook had been suspended and resumed. I don't have Parallels installed. I've tried to reproduce the hang by setting up similar conditions, but without success.

When this hang occurred, I ran a Java thread dump which confirmed that ohNet was hanging in a device Destroy call. I was trying to get a native thread dump when the hang cleared itself. Can you think of anything that could cause a hang during Destroy that would clear itself after a couple of minutes?
Find all posts by this user
27-09-2012, 10:34 AM
Post: #24
RE: Hang in DviDevice::Destroy
(27-09-2012 08:21 AM)simoncn Wrote:  Can you think of anything that could cause a hang during Destroy that would clear itself after a couple of minutes?

I think Destroy() will block until any in-progress actions complete. Could your device have been processing a particularly long-running action?

Another possibility is that a network card was being particularly slow to wake up after hibernation. NetworkAdapterList::RunCallbacks can block for ~90 seconds waiting for adapters to start behaving sensibly. This process shouldn't hold any locks which'd block device destruction but its possible an inappropriate lock has sneaked in.
Find all posts by this user
27-09-2012, 10:45 AM
Post: #25
RE: Hang in DviDevice::Destroy
Thanks for these pointers. I don't think any actions were in progress, as there wasn't anything in the Java thread dump to indicate this. A delay in running callbacks seems like a possibility. If it happens again, I'll know where to look!
Find all posts by this user


Forum Jump: