I have very weird situation where I have unit test (XUnit) that try to resolve webapi controllers through Autofac ( with web api contrib).
I have a situation where If I switch my configuration in Release mode, test in x86 mode, and run my test (if debug my test then it works) it throws an exception about the fact it can't resolve the controller.
Change whatever parameters in the above configuration it then works perfectly(I am using VS2012).
I know it is very little information and can not ask for a solution, but any clue about what could have been wrong will be appreciated!
Just for the record , I was trying to look at the stack frame to extract the caller class of method. In release mode, JIT may actually optimize the call stack (kind of Tail optimization) and basically remove what I expected to find (and was able to find in debug).
Related
I've found myself in an interesting position. I currently use the latest Unity container, I'm on asp.net core 2.2, and I use application insights. As such, I have configured DI in my web app to use unity instead of the out of the box DI provider in core. I also use Application Insights and use the IWebHostBuilder.UseApplicationInsights extension to spin up AI for my app.
With all this in mind, I have a piece of code whose constructor takes in IHttpContextAccessor so I can access the HttpContext. It was working great. Then, I had another small app that I was trying to reuse the functionality, and the HttpContext was null coming from IHttpContextAccessor. With a bunch of guess, test, revise, I found that IWebHostBuilder.UseApplicationInsights seems to initialize that Request property (HttpContext) on IHttpContextAccessor. If I commented out that AI extension, I would get null; uncomment it, it worked.
I've started to look through the AI code to figure out what exactly they're doing, but honestly, with all the dependencies and pipelines and all that, it's a pretty daunting task. I was hoping someone could point out where/how AI is doing this so my code doesn't NEED AI in order to work. All help would be incredibly awesome.
Use AddHttpContextAccessor extension to add it to DI. HttpContextAccessor is not added by default due to performance impact.
services.AddHttpContextAccessor();
After some struggle, and hoping this post would enlighten me on the AI ask, I found that I didn't need to replicate the AI mechanism, if there's even one at all.
Originally, I was accessing the IHttpContextAccessor via code in the view (Razor). I have an abstract factory pattern I was using to instantiate IHttpContextAccessor via Unity (this pattern came over from my .Net Frame work days). Once I moved that code back to the controller and used proper .net core DI to get the dependency via the constructor, everything started working.
There must be something there I'm missing, but I have the code working so I'm happy. If someone could shed light on why one way works vs the other, I'd be happy to hear it.
When you enable application insights by calling .UseApplicationInsights(), it adds HttpContextAccessor. There are many components in ApplicationInsights which require HttpContextAccessor injected to it. eg: ClientIpHeaderTelemetryInitializer.
This is the exact line where this is occuring:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/blob/develop/src/Microsoft.ApplicationInsights.AspNetCore/Extensions/ApplicationInsightsExtensions.cs#L137
This is a very strange error that took a while to find out what was going on. We have multiple jenkins linux slaves that were building a library. When the library was tested from one slave all was well. When it was tested with the other it got a runtime error with where it was trying to call a method signature that was non-existent. After lots of testing, I was able to determine that the order in which the class files were added to the jar determined if the tests would work or not. Does anyone know where to begin trying to remedy this? Is this a bug in groovy classloading? java classloading? Any ideas are appreciated.
I took the approach that the error state was in fact the correct state and started looking at the application config in detail (I'm on build team, so I was not familiar with this app) and found a bad spring configuration object. The issue dealt with order in which classes were processed by annotation scanner. If one class was processed first it would give a bad config which gave a bad app state which caused the error. The other build servers were building the jar with the bad class later in the config which caused a different state to be loaded which essentially ignored the bad file. This is why order in which classes were added to the jar mattered. I was able to correct the bad config and solve the error permanently.
I'm trying to test an ASP API controller which in turn calls out to a DLL which uses MathNet.Numerics.LinearAlgebra. I first call
MathNet.Numerics.Control.UseManaged();
However this call fails with the error
Exception thrown: 'System.NotSupportedException' in
MathNet.Numerics.dll
Additional information: Cuda Native Provider not found.
Why would Cuda be required when I'm explicitly telling MathNet to use managed not native?
It actually does not fail, the exception is handled internally. You can just continue debugging.
The exception is not actually thrown within the UseManaged call but internally at the static construction of the Control class, the first time it is being accessed and initializes the default providers (which includes probing whether any of the known native providers are available). Of course, Cuda is not required when using the managed providers.
This is indeed a small usability issue when debugging with "break on all exceptions" enabled. We may be able to avoid throwing the exception with a small refactoring. Maybe we should open a GitHub issue to track this?
I have a really awkward problem. I have build my app for iOS and tested it on all emulators and it works fine. I have installed it on a device (iPhone 6 plus) and that works fine as well. However, when I submit it to the app store, the feedback is that it crashes on launch on all devices. The crash log attached shows this error;
Unhandled Exception:
System.ExecutionEngineException: Attempting to JIT compile method 'GalaSoft.MvvmLight.Messaging.Messenger:get_Default ()' while running with --aot-only. See http://docs.xamarin.com/ios/about/limitations for more information.
The code that causes this error is in ViewWillAppear;
Messenger.Default.Register<LoggedInFailedMessage>(this, LoginFailed);
Messenger.Default.Register<LoggedInMessage>(this, LoggedIn);
The below stack overflow thread seems to indicate it might be caused by using value types, but I am using reference types.
System.ExecutionEngineException: Attempting to JIT compile method only in Debug Mode on device (MonoTouch)
Any ideas would be greatly appreciated! I don't know how I can test for these errors if they work when i debug on emulator and device but fail when apple test it.
Most of those issues where fixed a long time ago. Make sure your options for the AppStore builds (or the one you used to submit) match the one you're testing (e.g. Debug builds).
In particular make sure that the Enable generic value type sharing options is ON on the build you are submitting. This will include some extra code to ensure all value types code path variants are available at runtime.
Note that this setting should already be ON by default. Still it's a good practice to ensure your debugging/release settings are mostly (except debugging stuff) identical. Otherwise you risk testing different code, locally, than what you're submitting to the store.
I have developed a Java ME application for CLDC platform. It works fine when executed in an emulator. But when i deploy it to my N70 phone the application doesn't start at all in the phone. In my application there are some 14 classes and am creating an instance of each and putting them in the vector on application start. The classes just have one variable and 2 methods. Can this creating of lot of instances be the reason for its crashing?
Is there any way I can find out the reason why the application is not able to start in the phone?
Update:
Its running fine on emulator. And one more thing I would like to mention is that- The code stops executing only at the point where am creating those 14 instances and adding them to the vector. Till that point the code executes fine.
It might depend on where in the code you are creating those instances. If you are creating them in your MIDlet constructor or the startApp method try moving the initialization into the run method of your application.
One way of debugging J2ME applications that don't start on the phone is by adding "printf" style debug messages in your code to be written in the record store system and adding another MIDlet to your application to read from RMS and display those messages.
Or you could just comment bits of code and see if it works.
You can debug on device. If the emulator you are using is part of the Nokia SDK then there should be facilities elsewhere to carry out on-device testing and debugging. (I'd post more detail on this but I've only done this with Sony Ericsson phones recently.)
Another option is to use the Nokia tools that allow you to view the standard output and error for your application when it is running on your device (via Bluetooth for example).
The probability that your application is actually crashing the Java Virtual Machine bytecode interpreter thread and terminating the whole native process is very small.
It has happened before but you need to eliminate several other potential issues before being convinced of an actual crash.
It is more likely that either:
Your MIDlet is not created or not started because the MIDP runtime decides it is not correct.
or
Your MIDlet simply throws an exception that you don't catch, which can make it look like it was brutally terminated.
Since the MIDlet installer is supposed to prevent you from installing a bad MIDlet, the uncaught exception issue is more likely.
How to find an uncaught exception:
Start with the simplest HelloWorld MIDlet, using a Form so you can easily insert more StringItems at the top of the screen.
Create and start a new Thread in MIDlet.startApp()
In your override of Thread.run(), add a try{}catch(Throwable){} block.
Inside that block, do whatever your original MIDlet did.
Use the form as your standard output for debugging.
You can use Form logging to make sure you don't enter an infinite loop, to display exception classes and messages, to flag logical milestones, to display variable values...
That's the first step to figuring out what is going on.
I also faced a similar problem and when I recompiled my MIDLET as Midlet 1.0 then it worked fine. It seems like N70 is not able to run the new version of MIDLET. I think you downgrade and re-test your midlet.
Regards
Junaid