Stack Empty issue on concurrent use of MVC application - concurrency

We recently developed a new ASP.NET MVC 4 web application (C#/Visual Studio). After local testing and debugging we deployed it to production, and then started getting more and more health monitoring mails. These had different Exception messages:
Stack Empty.
Collection was modified; enumeration operation may not execute.
Item has already been added. Key in dictionary: 'ALL_HTTP' Key being added: 'ALL_HTTP' (other keys also mentioned).
Value does not fall within the expected range.
E.g. a whole series of error types we could not simply resolve or reproduce. The 'Stack Empty' is the one occurring most, several 100 times per day (e.g. for 1-10% of users) so we focus on this one, as the other errors seem related. Here is a partial stack trace:
Exception information:
Exception type: System.InvalidOperationException
Exception message: Stack empty.
...
Stack trace: at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
at System.Collections.Generic.Stack`1.Pop()
at System.Web.WebPages.TemplateStack.Pop(HttpContextBase httpContext)
As shown stack trace are mostly located completely in the MVC framwork (System.Web). The only place in our own code that regularly occured in some stack traces were in the views (.cshtml files) of the requested URL and then in a #Html.RenderAction() call. By now we have refactored a lot of these to RenderPartial() calls. This lead to no more views in the stack trace, though some RenderPartial now also gave some
Searching for this error indicated concurrency/parallel execution is the cause. This matches the fact that we initially could not reproduce the error locally, but it did happen on production. We have done no load testing, but by now have been able to reproduce the error on a local developer system by starting a lot of applications/requests simultaneously. However in our code NOTHING is done with explicit parallel instructions.
This seems to be related with MVC view's NOT being thread safe. However it is hard to imagine nobody else would have encountered this. We have a few thousand visitors a day, roughly 30+ active users at any moment. Sadly this number is now falling due to decreasing Google ranking (related to this problem).
Does anyone knows a solution/approach to this problem?

I am developing a ASP.NET MVC 4 application and I also came across the errors that you mention. Although they are different they seem to have the same source. After spending several hours trying to find the reason (and a lot of code changes) I have started my analysis from scratch.
Since I am using a Custom Route and there is a handler for that route that checks several things and also accesses the database I started by commenting database access. Opening several browser tabs very quickly (with IISExpress > Show All Application window or by Ctrl+Click in a link) I was happy to see that all the pages were shown properly, instead of several random error messages. Tried that a few times to be sure and concluded that something was wrong while accessing the DB.
public class MyNewRouteHandler : IRouteHandler {
IHttpHandler MvcHandler;
public IHttpHandler GetHttpHandler(RequestContext requestContext) {
MvcHandler = new MvcHandler(requestContext);
// some checkings and
// some database access code
// that was commented
return MvcHandler;
}
}
A colleague suggested that I added a small Thread sleep inside this method: GetHttpHandler. That line made the errors appear again, suggesting that the problem was not related to DB... When I did that I saw that MvcHandler object was being defined as a class property and that could be a source of what appeared to be a concurrency issue (only when multiple almost consecutive accesses were executed, the problem was shown). Moved the MvcHandler object to a local object inside the method.
public class MyNewRouteHandler : IRouteHandler {
public IHttpHandler GetHttpHandler(RequestContext requestContext) {
IHttpHandler MvcHandler = new MvcHandler(requestContext);
// some checkings and
// some database access code
// that was commented
return MvcHandler;
}
}
And after testing, no more errors. Uncommented all my code that accessed the DB (and did other checkings) and still no more errors found. Almost 3 days have gone by and everything still working properly.

This way of doing a Custom Route Handler did solve my most of my errors but I still have a few left and with new messages. One of them pointed to a code line in my Custom Route Handler and all of them had in common the fact that a Dictionary was being handled by the MVC framework, so... do I still have a concurrency problem?
I assumed so and all my method properties were moved inside the public IHttpHandler GetHttpHandler(RequestContext requestContext) method, not only the one mentioned before. One of them was the RouteData collection... Finally and after 2 days it seems that no more errors are showing.

Related

Recent MapView issue in Expo standalone Android

This is a new issue, seemingly something to do with google maps API - came out of nowhere for us. It seems impossible but our production app suddenly started throwing an occasional error on our startup screen. Our startup screen is mostly a google Map, which is MapView for expo.
Uncaught Error: Error using newLatLngBounds(LatLngBounds, int): Map size can't be 0. Most likely, layout has not yet occured for the map view. Either wait until layout has occurre or use newLatLngBounds(LatLngBounds, int, int, int) which allows you to specify the map's dimensions.
This only happens on our Android standalone app, through Expo it works fine.
We followed the docs for Android: https://docs.expo.io/versions/v34.0.0/workflow/configuration/#android - we’ve went through these steps. To the best of our knowledge we’ve done the process twice with different API keys, and we get the same result.
We’ve tried fixes suggested here, namely setting height and width based on dimensions, setting flex:1, and setting initialLocation. We use onReady to call the initial start method. Nothing seems to work.
The github link above does have someone running into this as of today. Any ideas how to even debug this?
We just removed everything except the map, including removing markers - and it works. We found the issue only happens when we add a marker with a coordinate, we reproduced this on a new brand new expo app by passing in coordinates to the map, and that caused it to crash on Android (most of the time, but not all) when we build and loaded the APK.
Adding markers through the onReady attribute of a map also didn't stop the crashes.
Turns out it's a non-documented method called onLayout, which is only referenced in the doc for fitToCoordinates. It mentions if this function is called to early then it causes a crash, and you may need to use onLayout. We never called fitToCoordinates but apparently something else inside the MapView does.
Someone put the issue here.
We moved our marker creation logic from onReady to onLayout and it worked.
<MapView
testID="map"
style={{flex: 1}}
onMapReady={this.onMapReady}>
{this.mapIsReady && <Marker
key={id}
coordinate={coordinate}/> }
</MapView>
To:
<MapView
...
onLayout={this.onMapReady}
No more crashes...

Ember.js Acceptance Testing not waiting for asynchronous data operations

When using the Emberfire (Firebase) adapter, I'm getting various errors that indicate the tests are not waiting for data operations to complete.
eg: Error: Assertion Failed: You can only unload a record which is not inFlight. when I try to create, check, and then delete a record
Also:
FIREBASE WARNING: Exception was thrown by user callback. Error: Called stop() outside of a test context at Object.extend.stop (http://localhost:4200/assets/test-support.js:3000:10) at exports.default._emberTestingAdaptersAdapter.default.extend.asyncStart
These errors do not occur while manually navigating through my app, nor when using the standard ember data adapter.
What is causing these errors and how do I avoid them?
Edit: although the symptoms are a bit different (no error thrown), it sounds like this problem may have the same root cause as the errors I've been seeing.
tl;dr
To work around the issue, I've been using a custom test waiter. You can install it with ember install ember-cli-test-model-waiter (works with Ember v2.0+)
Longer answer:
The root cause of these problems is that the ember testing system doesn't know how to handle Firebase's asynchronicity. With most adapters, this isn't a problem, because the testing system instruments AJAX calls and ensures they have completed before proceeding, but this doesn't work with Firebase's websockets communication.
So although these errors don't occur when interacting manually, I believe they technically could if it were possible to click fast enough.
These problems are known to occur with ember-pouch and will likely also occur with other non-AJAX adapters (eg. localstorage adapters (1, 2), or any other websockets-based adapter. It may occur with the fixture adapter, but that may return results immediately and so not trigger this problem). It also happens with other asynchronous processes, like liquid-fire animations (fixed in a similar way)
The custom test waiter I mentioned in the tl;dr works by waiting for all models to resolve before proceeding with the test, and so should work with all of these non-AJAX adapters.
For more background on how ember's testing deals with asynchronicity under the hood, Cory Forsyth has a helpful blog post, and this gist gives another more flexible solution approach but that requires more manual book-keeping.

How to avoid the "loaded.created.uncommitted" error when doing unloadAll with ember-data?

My application creates a lot of "configuration" models (ie- they only live in the app at runtime and they won't ever be persisted). I load these on demand so my app is constantly creating records and then throwing them away.
//create a record that will never be persisted
this.store.createRecord('foo', {name: 'wat'});
In the past I would just do a clear of the store but I realized this doesn't actually "remove" anything. I've decided to use the unloadAll instead
this.store.unloadAll('foo');
... but I run into this error as I have these "configuration" models
Error while loading route: Error: Attempted to handle event
unloadRecord on while in state
root.loaded.created.uncommitted.
at new Error (native)
How can I avoid this error (while still using the unloadAll as I need to truly remove these from the browser) ?
Actually this has now (should be) fixed with my PR which was merged 2 days ago:
see: https://github.com/emberjs/data/pull/1714
That PR loosens the constraint which disallowed unloading all dirty records, to disallowing only inFlight records. I believe with some time and proper thought, that constraint may also be lifted.
The rest of the PR, is specifically around proper cleanup when unloading a model, a record array, or destroying the store. I do believe this is a good first pass at proper cleanup.
I hope this (merged) PR solves your issue, if not please open a descriptive issue, and lets squash the bug.

Access Violation (Delphi) - except the first run

I have a POS application written in Delphi, which has been working fine until now.
I had to add a webservice client to have some documents validated by the goverment, and even though I had never worked with WebServices/Encryption before, I managed to do it (thanks to the internet really).
When I run the program and create one of those documents, it is perfectly validated (the webservice is accessed, a SOAP envelope with some data is sent, and the response from the server is received without any problems).
The problem is, if I create another document, when I try to validate it I get an "Access Violation at 0x07e7bcb5: read of address 0x00000012".
My validation routine is a function inside a DLL. Before it was inside the DLL, I had all the code inside the main project, but it crashed my program: if I would validate a document, the response would come, but I would get an Access Violation when I terminated the program or if I tried to validate another.
I also tried loading the DLL dinamically, so the validation process would "start from scratch" at each run, but it was useless.
I've been trying to debug this, but I just can't get it. Running step by step, it fails in some line, I comment it out, and the next run it fails in a completely different place.
I tried also EurekaLog, but I couldn't figure out what to do with the info it gave me (I had never worked with it).
Any direction I should be taking?
Thank you very much!
Nuno Picado
EDIT:
I should probably mention what I'm using to access the webservice:
- THTTPReqResp and WinINet for the communication
- IXMLDocument to create the SOAP Envelope
- LibEay32 to encript some data required by the webservice
- TZDB to get the universal time from a web based server
- Capicom 2.0 to load a certificate required for the communication
I use EurekaLog at work, to debug errors that happen at client installations. Here's what you do with the information EurekaLog gives you:
Fairly high up in the report should be one stack trace for every thread in the program. The one on top should be the one in which the error occurred. That's almost always the most important thing in the error log: it tells you exactly what was going on when the exception was raised.
Find the place in your code that corresponds to the top of the stack trace. An access violation means that somewhere, your code tried to access (read, in this case) memory that's not mapped to your program's address space. A bunch of leading 0s means that you're trying to read at an offset from a null pointer. This almost always means one of three things: You're trying to read the value of an object whose value is nil, you're trying to call a virtual method on an object whose value is nil, or you're trying to read an element of a string or dynamic array whose length is 0 (and this is currently represented by a null pointer).
Now that you know what you're looking for, have a look at the code and see if there's any way that that could be happening based on the information you have available.

Making logs on a web application

I am developing an application using Django that works similar to a project manager. For this reason, the system should be capable of storing information about everything. When I say everything I refer to the actions the users do, the errors that occurred while doing an action, etc.
I have a class Log and one of its attributes is called action_type, this attribute specifies what kind of action just happened. I am supposed to have 5 kinds of types:
INFO: this log stores the information related to user's actions such as creating a project, create other users, etc.
DEBUG: should store comments made by the developers that will allow them to detect errors.
ERROR: shows errors that occurred in the system but they don't affect the system's functionality.
WARNING: it's for potentially damaging actions.
FATAL: unexpected errors, exceptions and security breaches.
I can only come up with logical logs for INFO.
Could you tell me some reasonable logs that I should include in this and the other categories?
The answer will depend greatly on exactly what your application does, but my basic approach is this:
Each time you get ready to log an event, just think about the event and it will be clear where it belongs. Did it kill your application? It's fatal. Did it prevent something from working correctly? It's an error. Could it prevent something from working, and did we just get lucky this time? It's a warning. Does anyone care? Info. Otherwise, if you still need to log it, it must be for debugging purposes.
In your particular context, it sounds like you might only be trying to log user actions. If that is the case, the only actions that could be fatal would be ones for which you don't provide an undo option (or, I suppose, if the user is able to order a piano bench and a length of strong rope through your application). I also couldn't really imagine any debug-level logs coming from user actions. Because of this, I assume you will be logging code level events in addition to user actions.
FATAL: This should only appear in the logs when your application actually crashes, and possibly alongside 500 responses. You might generate these within your wsgi application in a catch-all, only when the process would otherwise have died.
ERROR: Likely tied to http error responses. This is typically for errors caused by something outside your application. Things that happen in your code are probably expected and <= warning level, or unexpected and fatal. Errors might be a 404 from the user making a typo in a url, validation errors on form submission, or authentication errors. From the other direction, errors might be returned from remote web services that you contact or IO errors from the os.
WARNING: For things that don't break anything, but that might bite you if you keep it up. Examples are using deprecated apis and anywhere something only worked because of the default (time zone, character encoding, etc). Maybe certain input values result in warnings, too, like setting a due date in the past.
INFO: General, healthy operation. Someone created a database row (a new project or a task?), created an account, logged in or out, a socket was successfully opened, etc.
DEBUG: Just what it says. Output that you will usually turn off once the code is working correctly. Method entry/exit, object instantiation, field values at various points in the code, counters. Whatever you need to figure out why your program is crashing right now, as you work on it.