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.)
Related
I created an algorithm in nodejs using the cli terminal that receives an input of various values and makes the automated process of checking them in an api, so far so good, the problem is that he often stops this process and closes without any error or explanation. I have this problem with the VPS more than with my machine.
I forgot to mention that this process is done in parallel, the entries are separated into arrays and executed simultaneously x times at a time.
I thought it could be a possible memory leak since the process is a bit heavy but I have already done the test with less compliance and the result is the same and if it were he would warn me, the worst of all is that it only happens sometimes. Whoever had a similar problem could tell me how it was solved?
There is no code in the algorithm that closes the program, only after closing the loop, but it didn't have it before and even then it happened.
I have made this AutoHotKey script after reading the manual, searching and troubleshooting for endless hours in the last few weeks:
#Persistent
#SingleInstance force
if A_Args[1] > 0
{
Menu, Tray, Icon, C:\blablabla\new notifications.png
}
else
{
Menu, Tray, Icon, C:\blablabla\no new notifications.png
}
This, I have compiled into test.exe. Then I call it like this from a terminal: test.exe 1, test.exe 0, test.exe 2, test.exe 3, etc.
If I do it slowly/manually, it works: it only ever keeps one instance of the script, showing visually as a nice little icon in the Notification area (as intended), never launching multiple instances.
However, when I started actually using it for real, by calling the same terminal command from my scripts, it often opens two or more instances, which are kept open and just make the Notification area longer and longer, ignoring the rule that it only can run as one instance ever.
I was able to "solve" it by introducing a short "sleep" in my script after each such command call, so that the same script never calls it too quickly in succession. However, today, I realized that multiple different scripts of mine often call it at the same time, or nearly at the same time. This means that my "clever" solution of sleeping falls short.
I then thought that I can use the database to keep track of when the last time a script called this, and don't do it if it's too soon, but if I did that, the whole point would be lost since I can no longer trust the icon to accurately tell me whether or not there are new notifications in my system. I'd constantly be wondering if there had been such a "race condition" and manually go and check anyway, defeating the point of this visual indication which is supposed to let me always know "at a glance" whether or not there are new notifications in my system.
Maybe I could have a loop in my scripts and repeatedly re-try if it detects that a notification has been sent too recently, but that means my scripts will potentially stall for a long time as they all send notifications (especially in the morning, when I wake up and kickstart my system). It just seems like the wrong solution.
Is there really no way to properly handle this in the script itself? As is obvious from my description, the #Persistent and #SingleInstance force rules aren't respected.
(I've had similar problems in the past with programs being unable to "handle" running commands too quickly, and I never know what to do about it except to introduce sleep. But even then, it often glitches out. For example, Notepad++ requires me to first open a document and then open it again with a specified line number, sleeping in between, or else it doesn't go to the specified line.)
I created a discord bot using Node.js and the discord.js-commando framework.
One of the features is to create writing sprints, which essentially is a timer, so you could say: I want to write for 20 minutes, starting in 5 minutes. The bot would then wait 5 minutes and start the sprint, then after 20 minutes it notifies the users doing it that it's ended and waits for wordcounts to come in, then posts the results.
This was working fine when the bot was only on one server, but it's been added to several more recently (78 according to the !stats command, though I don't know how many are actively using it), and since then, it's been very erratic.
Sometimes the sprint never starts, sometimes it never ends, sometimes it ends and then after you post your wordcounts, it never posts the final results.
This is my first ever dabbling with Node.js, so I don't know if I'm doing something wrong. I am doing all of the timers with the setTimeout function.
Here is the command file: link to GitHub
As an example, this is the timeout that is set after a user submits their wordcount, if everyone has now submitted their wordcount, so we can display the results:
msg.say('The word counts are in. Results coming up shortly...');
this.finished = 1;
// Clear original timeout
this.clear();
// Set new one
this.messageTimeout = setTimeout(function() {
obj.finish(msg);
}, 10000);
Where clear is:
clear() {
clearTimeout(this.messageTimeout);
}
Is there something inherently wrong with doing it this way? I know very little about Node.js... Should I perhaps look at doing a cron every minute instead to process sprints? Or could this be a server issue? I am running it on a free EC2 AWS server, but the reports all look okay, no resources are being used at abnormally high levels.
Thanks.
Edit : If you're seeing this same problem (and you're accustomed to NOT seeing this under VS2010) please comment below so I know it's not just me - but be sure to check Han's answer to make sure none of those scenarios appear...
I've been updating my app to run with .NET 4.5 in VS2012 RTM and noticing something that I don't quite understand and that is unexpectedly green highlighted statements (instead of yellow).
Now I'm well aware of what this is supposed to mean, and the IDE is even showing me a little explanation tooltip.
This is the next statement to execute when this thread returns from
the current function
However there's absolutely nothing asynchronous or thread based about this code. In this simple example I'm sure you'll agree that string.ToUpper() won't be off in another thread. I can step through the code no issue.
There's nothing else going on and I am on the main thread as you can see here.
I am using async and await and MVVM-Light (the above method is the result of a RelayCommand) but I still get this behavior even when the code path is directly off an event handler such as PreviewKeyDown.
If I create a new app I cannot duplicate this - the coloring is yellow as expected - even when using await.
Anybody got any idea? It's starting to drive me crazy!!
It is green when the current instruction pointer is not exactly at the start of the statement. Some common causes:
Common in threaded code, setting a breakpoint in one thread and switching context to another. The other thread will have been interrupted by the debugger at an entirely random location. Often in code that you don't have source code or debugging info for, like String.ToUpper(), the debugger can only show the "closest" source code
Using Debugger + Break All to break into the debugger. Same idea as above, the instruction pointer will be at a random address
Getting an exception in code you don't have debugging info for. The editor shows the last entry in the Call Stack that it does have source code for. You need the call stack window to see where the actual exception was raised. Or the Exception Assistant, its reason for being
Debugging optimized code. The jitter optimizer scrambles the code pretty heavily, making it likely that the debugger can't show the current location accurately
Having out-dated debugging info or editing the code while debugging
Debugging code generated by the x64 jitter, happens when the project's Target Platform setting is AnyCPU. The x64 jitter has a number of chronic bugs that are not getting fixed, generating incorrect debugging info is one of them. Problems that were not addressed until it was completely rewritten, done by the RyuJIT project and first available in .NET version 4.6. Targeting x86 in your EXE project is the workaround.
I understand that this is old post yet I would like to answer the question with my experience.
I have encountered same issue recently in one of my WCF application. After debugging and closely looking service logs and I find out that my code was giving this error because service was hitting max allowed limit for code execution and once the service hit max allowed time limit it was trying to offload the current debugging session.
ERROR IN GREEN STATEMENT: this is the next statement to execute when thread return
So avoiding this issue you can try to look any potential code(Code/Service Timeout or any other code block) which is trying to offload your currently executing code context and try to fix it, furthermore original explanation given by #Hans is still very much relevant for trouble shooting this issue.
Actually, I am also facing this issue. This is because I missed some layout component in landscape mode, So check all the Id's and components and Run, you will not get this error.
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.