I have a MonoTouch application that has an annoying bug and I don't know how to go about resolving it. The problem seems to occur when the application has been in the background for a considerable amount of time (a couple of hours, for example) and then you return to the application. Upon returning from the background, the application will work for a short period (about 10 seconds) and then it freezes up completely and none of the tabs, buttons, etc respond. After another 10 seconds or so, the application is killed by iOS. In the crash log, I see the following reported:
<appname> failed to resume in time
The annoying thing with this bug is that it never seems to occur when I am testing with the debugger; I run the application in debug mode and test it for ages without any problem. I also send it to the background and return without any problem. So, so far it only seems to occur when the application has been in the background for a long time... and it happens at different points in the application, never the same point. Does anyone have any idea what could be happening and how I would go about debugging a problem like this? Thanks.
Your app is probably doing something that takes longer than 10 seconds when you come back from background. iOS forces you to return within that predetermined period, or it'll kill your app for "misbehaving".
Your computer is thousands of times faster than the device. That's why you only see the issue in the simulator.
I would check your AppDelegate class to see what's happening in the WillEnterForeground method, that could be taking so long.
Related
I have a plugin for Homebridge that operates shades, i.e. WindowCovering Services. It basically imitates the remote for the shades. The remote has 16 channels and one of them, 0, operates all shades. Each shade/channel is an Accessory on a Dynamic Platform. As the shades move I am updating the CurrentPosition and PositionState Characteristics. This seems to work fine now. However, some updates never seem to reach Homekit.
When multiple shade/channels are moving at the same time, this shows in the Home app as "Opening" or "Closing". When the PositionState is updated to Stopped, the icons show the current %age open. However the updates on some shades will get lost.
I thought perhaps a delay between update calls is required, so I implemented a scheme that prevents calls being made close together with a configurable delay. That seemed to improve things, but updates are still lost and I don't really know if the delay is required.
All PositionState updates go through this code. I have been debugging this issue for quite a while and am convinced the code is executed, but I can't figure out why the Home app does not see the Stop.
updateStateCB() {
this.service.getCharacteristic(this.platform.Characteristic.PositionState).updateValue(this.positionState);
this.logTimeCh('Update state:' + this.positionState);
}
Where might I be going wrong here? Is the delay between calls required? Is there a bug in Homekit somewhere?
Thanks
I develop a SCADA in python3 with the help of PyQt. I expect my program to continuously indicate various parameters received through RS-485 interface, however, within several minutes from the start (it is always a different time), the GUI stops to update itself. At the same time, the GUI stays responsive and if I were to click on one of the animated QAbstractButtons it has, the GUI starts to work as intended again for a short period of time. The problem occurs on both Linux and Windows.
The program has several worker threads: one for RS-485 exchange, one for reading/writing various data to disk, one for decoding received package and refreshing data in memory, one for request queue management, etc. They all work in loops of while (True): time.sleep(...) - do the job. The GUI is implemented in the main thread.
The data is indicated with QLabels. The QLabel.setText is added to painterEvent() of QWidgets containing the QLabels.
When the GUI stops updating, the other threads are up and running: the exchange is functioning, the request queue is forming, etc. Despite not being updated, the GUI stays responsive and reacts to QAbstractButton clicks.
I tried adding gui.update() or app.processEvents() into one of the worker threads, tried force updating through QTimer in the main thread. The result is the same: it works for a short while and then stops.
I tried increasing the time.sleep of the refresh thread and force updating the main widget over longer intervals of time (0.5 to 5 seconds) and it seems to help the situation a lot, this way it can run for several minutes, but it still does not solve the problem.
I would love to show the code, but the whole thing is way too bulky to post here and if I could narrow it down to a at least a hundred lines, I would have already solved the issue by now. So if any of you could at least share some general considerations on what to look for, I would be very happy.
update:
This seems to work, I'll leave it running for a few hours tomorrow to confirm:
update_timer = QTimer()
update_timer.setSingleShot(False)
update_timer.timeout.connect(self.gui.repaint)
update_timer.setInterval(500)
update_timer.start()
I assume that self.gui.update() did not work because dataChanged() was probably not emitted and control passed instead of doing repaint(). As far as I understand, the solution above is not the right way to update widgets.
So, the question actually boils down to the following:
What is the right way to update the main QWidget and how do I let the program know it needs to be redrawn, probably using dataChanged() signal?
The answer is simple. Never do anything related to PyQt from outside the main thread. Even if it seems the only logical way to do something.
After I 'fixed' the issue with the gui not being updated, I stumbled into a more serious problem: the program crashed every now and then. As it turns out, the GUI not being updated was only the top of the iceberg. The uptime was usually 2 to 7 minutes, I received a few glibc errors ("corrupted double-linked list" and "double free or corrution"). As it turns out, the source of the problem was inside refresh thread that has several hundreds of lines updating gui:
self.gui.screen_name.device_name.setCrash()
where setCrash() changes widget color and palette, or even more direct things like
self.gui.screen_name.label_name.setText(str(value))
I tracked down everything even loosely related to gui from the main file (the place where all the threading took place) and restyled it. Now it only has one worker thread - the RS-485, the rest are wrapped into separate QTimers.
This is what it was:
class Main():
def __init__():
self.plots_thread = Thread(target = self.plots_refresh)
self.plots_thread.start()
def plots_refresh():
while True:
time.sleep(0.5)
#do stuff
And this is what it is now:
class Main():
def __init__():
self.plots_refresh_timer = QTimer()
self.plots_refresh_timer.setSingleShot(False)
self.plots_refresh_timer.timeout.connect(self.plots_refresh)
self.plots_refresh_timer.setInterval(499) #prime number
self.plots_refresh_timer.start()
def plots_refresh():
#do stuff
This time the program has been running for over an hour and never crashed. After coming to conclusion that this was THE fix, I refactored the really messy test file and resumed testing - again, no troubles for half an hour.
I have a large data acquisition and control program written in Python3.4.2 using GUI mostly developed on Glade 3.18.3, Gtk3.0 GObject running Debian 8 with XFCE.
There are timers that keep doing things, and these work fine. After startup, the program runs for some 3 - 7 days, then suddenly, all of the windows go blank and stay blank. Other applications are not affected. Memory and CPU usage is modest.
There are no indications of problems prior to the windows going blank. The windows show their title bars and respond normally to minimize, restore, move to another Workspace, etc. It looks like they are not getting repainted - no widgets are visible at all. The code is way too large to post here, and I am not able to isolate a specific problem area for lack of obvious symptoms other than the blank screens. There are no error messages or warnings.
The timers continue to run, acquire data and control things. This happens whether the program is run from the command line or under PyDev in Eclipse.
Things I have tried:
In the main timer loop, I put code to look for a file, and then exec the command in it, printing the results, so I have been able to mess with the program in real time:
Replace the usual Gtk.main() with a while loop whose variable, if not made false, will re-execute the Gtk.main(). Executing Gtk.main.quit() stops Gtk.main and starts it again. Windows still blank. Did this repeatedly to no avail.
Experimented with garbage collection with GC. Collecting garbage makes no different. Windows still blank.
Put in code to print percent of time consumed by the timer loops. Fairly steady around 18 - 20% of available CPU time, so nothing is hogging the CPU preventing re-paint.
I have a button that clears a label. I read the label, then executed a builder.get_object(...).activate command to the button. I re-read the label and it was now properly blank. So events and widgets appear to be working normally, at least to some extent.
Finally, if I click on the close X on the title bar, XFCE asks me if I want to wait or close now. So it seems as though there may be a disconnection or problem with signals and the OS, even though XXX.activate() works.
Web searching is in vain. Does anybody have ideas of what might be happening, useful diagnostics, or other suggestions? Many thanks!
April 27, 2017 Update:
I have taken two substantial steps to mostly work around problems. First, partly in response to a couple of Gtk crashes over the last few months, instead of ending the main program with:
Gtk.main()
I end with:
while wannalive:
try:
Gtk.main()
except:
pass
wannalive is True until user does a quit, so recovery is instant.
Second, I grouped all of the code for each window setup and initial population of static items into two functions. I also made another function for closing a window. These functions propagate to children, grandchildren windows. A function in the top window first, closes, then re-creates all windows, with one call. In operation, there are overlaps in what windows exist, but that is not a problem.
Above, I describe that I can inject code with an external program. The external program has a button that injects a call to that third function. In about five seconds or less, the result of a single button click is to replace all blank windows with functional windows. For my purposes in a controlled environment with a trained operator, this is acceptable.
Next, let me address the relationship between the timer loops and GUI events processing. I do use GObject.timeout_add(ms, somefunction). Experiment shows that a button that calls time.sleep(5) stalls the timer. Experiment shows that injecting time.sleep(5) in the timer loop stalls the GUI. This is consistent with my belief (correct me if I am wrong) that Python runs on a single thread. Therefore, bad code caught in an infinite loop should stall both the GUI and the timer loop. (The program has one timeout_add call.)
I realize almost the same question was asked, but it was over a year and a half ago and didn't really have an answer. I need a solution and soon, so I am asking again. Here is my story:
I use Google Apps Script to teach coding to middle school students. We write and run very basic code. This website shows the types of things we do. The instructions we follow are commented out within the code itself.
Everything had been working fine, then just last night I started getting
the error "IO error when deserializing continuation" when running code. It
appears to happen randomly, as I could run the exact same code multiple
times and sometimes have the error appear, and sometimes not. This will
happen even on an extremely basic piece of code. Here is an example of code that I can't run more than 2 or 3 times without getting the error (I included the code for the menu I use to initiate the script):
function onOpen() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var menuEntries = [ {name: "variables", functionName: "variables"} ];
ss.addMenu("Learn to Code with Google Apps Script", menuEntries);
}
function variables() {
var input;
var name=Browser.inputBox('What is your name?');
Browser.msgBox('Your name is...');
Browser.msgBox(name);
}
I am presenting the coding curriculum from the website above on Friday to a
group of educators, and if this error persists, it will ruin my
presentation.
Please help!!
It appears that this sort of thing can happen under circumstances where your script's execution is "paused" by modal UI interaction (in this case, your msgBox) as noted in this related post
Why is Browser.msgbox the common denominator? Why is "the problem disappeared on its own, as suddenly as it appeared" a common refrain? Could this issue have something to do with the time delay (latency) of the system (PC and Internet) at the time of script execution?
I experienced this problem last night for the first time with a well-proven script. As it happened, this was also the first time I was running FreeFileSync in the background, syncing my two NAS drives. On a hunch, I paused the sync process, and the script problem behavior improved enough to finish the task (though still not without occasional errors).
Time delay (latency) changes due to system load variations (with time of day, background processes, etc.), could explain such apparently random behavior. I have not seen this issue raised. If so, the problem might be fixable on Google's end, by increasing a "timeout" variable. (Other reported "solutions" may be red herrings, successful due to temporarily-reduced system latency.)
I'd like to write an extension that displays a desktop notification every day at a specified time. Having a quick look through the Chrome APIs, it seems like the only way to do this would be to:
create a background page for my extension,
use setInterval() with a sufficiently low resolution to not tax the CPU (even 5 min is fine),
when interval fires, check if the current time is after the desired time,
ensure that the user has not already been displayed the notification today.
(The details of the last step are irrelevant to my question, just put in to show I realize I need to prevent "flapping" of the notice).
This seems rather indirect and potentially expensive though; is there any way around this? Is the background page needed?
I suppose I could just call setTimeout() and only fire the event once (by calculating how long between now & desired time), then call it again after the notification is shown. For some reason that sounds more "brittle", though I'm not sure why...
I think you will want the background page to do this smoothly. You can't use a content script because you need to keep the "state"/timer.
So when background page first loads (browser start) you work out the current time and the offset to the next notification time and setInterval to that exact interval. That way you won't need to poll every five minutes and/or work out if you've shown the message. You simply show it at the exact time required. This has to be far more efficient, effective and cleaner than polling. At notification you just reset the interval again.
Some sample functions here:
setTimeout but for a given time
From reading the above post and from a quick search on the net it appears that you should have no problem calling setInterval for an interval such as once a day. Calvin suggests 25 days!
That is how I would approach it.
EDIT: Since posting one thing that has sprung to mind is what happens if a PC gets hibernated for n hours? I need to test this myself for a similar project so I will update once I've had a chance to test this out.