Ticket #260 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

Telldus or telldusservice multiple hang/freeze

Reported by: p-a enarsson <pason67@…> Owned by:
Priority: major Milestone: 2.1.2
Component: telldus-core Version: 2.1.1
Keywords: Cc:
Blocked By: Blocking:
Platform: Mac OS X Sensitive: no
Verified by Telldus: no

Description

A lot of times telldus hangs. Sometimes when executing commands from nexahome, but also in "idle"
General feel, buggy and unstable.

Attachments

Arkiv.zip Download (172.9 KB) - added by p-a enarsson <pason67@…> 6 years ago.
5 chrashdumps

Change History

Changed 6 years ago by p-a enarsson <pason67@…>

5 chrashdumps

comment:1 Changed 6 years ago by p-a enarsson <pason67@…>

Yesterday added more devices. When executing, from telldus center or via td-tool, a all on or off of a group with 11 members, telldus hangs every time. (bechball). Restating telldus center not possible, hangs before started. Recovery: Force shut down tellduscenter. Restart telldusservice from activity monitor, then start tellduscenter again. But soon again it hangs, randomly, when executing commands.
Downgraded to 2.1.0 and no more hangs, all on/off works as expected. 2.1.1 unusable at my computer.

comment:2 Changed 6 years ago by micke prag <micke.prag@…>

Does this only happens on groups or also on single devices?
When it freezes are the TellStick trying to send the commands? If you have a TellStick Duo or a later batch of TellStick you can see if it blinks.
If you leave TelldusCenter for a couple of minutes, does it "unfreeze" again?

comment:3 Changed 6 years ago by micke prag <micke.prag@…>

  • Component changed from other to telldus-core
  • Milestone set to 2.1.2

comment:4 Changed 6 years ago by micke.prag@…

commit d0b1dbba0e8992e28c2f9bccf2540f9d95dea95d
Author: Micke Prag <micke.prag@…>
Date: Fri Nov 2 13:08:43 2012 +0100

Do not unlock the mutex manually since we are using a MutexLocker.


Unlocking a mutex twice seems to cause deadlocks on OS X if we stress the
library. Windows seems unaffected. See #260.

comment:5 Changed 6 years ago by micke.prag@…

  • Status changed from new to closed
  • Resolution set to fixed

commit c3bcd642465801d14a57adf3e44b5303e899353a
Author: Micke Prag <micke.prag@…>
Date: Fri Nov 2 19:42:12 2012 +0100

Queue all device commands and execute them from the main thread.


By queueing all commands the client library will return immediately and all
executed commands will not block any more. This is benificial for applications
that calls the api using the same thread as the ui thread. For instance groups
could before take several seconds to execute and the application would freeze in
the meantime. If the time to execute was longer than the timeout between
telldus-core and telldusd other nasty stuff like resending the same group up to
20 times could happen.


This change fixes all that with the drawback that we do not really know if the
command was succuessful when returning. We do the best to check all
prerequisites to determine it the call will be successful. Errors like
TELLSTICK_ERROR_COMMUNICATION and TELLSTICK_ERROR_BROKEN_PIPE will not be
reported back to the client. We can still log them though.


This fixes #260. Please reopen if the issue still exists.

Note: See TracTickets for help on using tickets.