I have been tearing my hair out at this issue
The code in question is part of an Open Source project here: aiosmtpd (my fork of the actual FOSS project, here)
The file with the problem is this one: main.py
The piece of code in which the problem happens is on line 139 of main.py
Here's a snippet:
...
from aiosmtpd.smtp import DATA_SIZE_DEFAULT, SMTP, __version__
...
...
# args is the result of ArgumentParser.parse_args
factory = partial(
SMTP, args.handler,
data_size_limit=args.size, enable_SMTPUTF8=args.smtputf8)
...
server = loop.run_until_complete(
loop.create_server(factory, host=args.host, port=args.port))
...
Sometimes -- that is, not always -- the code failed at that point with RuntimeError: Event loop stopped before Future completed.
My questions:
What could be the cause of this intermittent failure?
It failed like 10% of the time during testing (using tox + nosetest2), but 90% of the time just went swimmingly well.
How should I instrument and/or check and/or assert to prevent this from happening?
What's the best strategy for "recovering" the error and redoing the action?
I will emphasize for the n-th time that the error happens INTERMITTENTLY. And infrequently, but often enough so I feel compelled to trace the root cause. And after an error, if I rerun the code again -- immediately or after a delay -- the same error nearly always did NOT happen.
Barring a bug in asyncio, the issue is likely caused by a call to loop.stop() hidden somewhere in the code base. You probably want to remove or disable those, as they are fundamentally incompatible with run_until_complete, as well as with the more modern asyncio.run.
Related
I have a random Runtime Error 216 that appears on application close.
I have debugged as far as I can and the error is thrown in SysUtils.FinalizeUnits.
I have gone over the code and ensure all created objects are freed.
The number on the runtime error, 0040054A, is not present in the mapfile. Do you know what this means?
Can anyone tell me how to find out what is throwing the error?
This is VERY OLD Delphi problem - wrong exception handling in unit initialization/finalization process.
The problem easy to reproduce - just make any program error/exception (division by zero for instance) in initialization block of any unit. The exception will be created correctly. But then, before the exception rise, the unit finalization process destroy the exception object. And thus, when the exception object accessed, the "runtime error 216" occured.
I'd suspect a memory leak (all Runtime Errors 216 I've encountered so far were) and use a profiler (visual inspection is never as good as a tool). Since you're using Delphi XE, you should give AQTime a try (it's included), see also
Delphi - Check if memory is being released "on time"
Kind regards, Frank
Since runtime error 216 is an access violation, this may indicate that you're attempting to use something that you've already freed.
Addresses in the map file are based at 0, but that's not where your EXE file gets loaded into memory. Your EXE gets loaded at its preferred base address, which is usually $400000. Subtract that from the address you have. The address you're looking for in the map file is $0000054a.
There was a similar question, Read:
How to debug a crash that only occurs on application shutdown? (Delphi)
Consider using Memory profiler, this may help identifying live objects after app was terminitated.
I suggest you try the FastMM Full Debug Mode, and either statically link that into your app, or use it as a package (if your app uses packages).
You can use the method I used to fix mine.
I commented out the main program, and added code back until it failed.
Turns out that it did not want me to call couninitialize at all. Did not throw an error at the time, but failed after program termination with a 216. Removing the offending statement fixed it.
Since this was maybe 6 statements before end. statement, I don't imagine it will matter.
This method is easy if you are consistent about using // for comments. I moved IO statements that needed curly brackets to a procedure.
On Microsoft's oficial web site it is mentioned that, this issue can occur if your computer is infected with a SubSeven Trojan virus.
Antivirus software and windows registry cleaner should help.
I'm using asyncio with websockets and aiohttp for a Twitch API bot. Everything was fine, but at some point asyncio starts to hide errors and makes the code a brick.
After a while dealing with that, i realize that only happens on functions (and nested ones) awaited on asyncio.gather().
If you see in the images, I try print an unresolved reference, at that point the thread is dead and no errors are throw.
https://cdn.discordapp.com/attachments/532653651689472024/570191503587147776/Screenshot_2.png
Also, is weird this part of the asyncio code (asyncio/events.py) depending of the type error, asyncio loops over that part a lot of times. I dont know if that matters.
https://cdn.discordapp.com/attachments/532653651689472024/570191514634944522/Screenshot_4.png
Furthermore, i tried to uninstall asyncio with pycharm and with pip. The code still accessing to asyncio i dont know where. i dont have virtual environments set. is there some way to uninstall manually and try to reinstall asyncio cleanly?
By the way, my app still working, is just the fact of no having clues when I miss something, making the progress freaking hard
If you see in the images, I try print an unresolved reference, at that
point the thread is dead and no errors are throw.
asyncio.gather runs several tasks simultaneously, and by default propagates first exception any of tasks raised. Even if this exception didn't finish your program, it at least changed position where your interpreter is. And while other gathered tasks continue to run in background their exceptions can't be raised from the new point where your interpreter is currently on.
Exceptions occurred in tasks but not raised anywhere are printed as warnings "Task exception was never retrieved" when event loop is closed (usually at the very end of your program).
It's hard to say if this is exactly what happens in your case since you didn't provide minimal reproducible example. Feel free to provide one to receive more precise answer.
Furthermore, i tried to uninstall asyncio with pycharm and with pip.
The code still accessing to asyncio i dont know where. i dont have
virtual environments set. is there some way to uninstall manually and
try to reinstall asyncio cleanly?
asyncio is a part of the Python's standard library. This module can't be (or at least shouldn't be) (re/un)installed without (re/un)installing Python interpreter itself.
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 hope you can help me or direct me to someone who can help me. I am programming in M(UMPS) and I am having a problem. In the program I am waiting for a response from the mainframe I do a read (R x:15) I understand that after 15 seconds if I did not get an answer I will stop waiting for an answer. I checked my $T and if it there is nothing there or if it is equal to zero I want to stop the program.
This works sometimes, but most often the program will abort prior to checking the $T, I don't even have a chance to see what is in x, how can I catch this before it aborts. I looked in the console log and everywhere but I do not see any error. The only error I see is when I look at the unsuccessful task it say err (getr+9 which is the line where I do my read.
R x:15 (IT STOPS HERE AND ABORTS if I run out of time)
I have tried
G:'$T END
OR
I '$T G END
OR
S TEST=$T
IF TEST=0 ..........
But none of these checks happen if I time out. If I do not time out everything works great.
By serendipity I ended up on this forum today.
So, maybe this question has been answered already. Anyway, here goes:
The answer to this question is that there can be multiple reasons why no response is received from a remote machine.
When it simply takes too long for the response to be transmitted, the following should work:
Read variable:15 If '$Test Goto ErrorHandler
However, when the communication channel between the two systems gets closed, this is treated as an error condition, so in that case, the following should work:
Set $ETrap="Goto ErrorHandler"
Read variable Set $ETrap="" ; Note that we don't need a time-out to handle this...
Hope this helps
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.