I encounter quite bad problem with MvvmCross IoC resolving.
We have a big application that registers about 100 different services and 6 plugins.
Sometimes we are getting problems with resolving these services. Most time it works fine, but then at Xamarin.Insights I can see that at production, there are some problems that happens(NOT ALWAYS), for example this:
Cirrious.CrossCore.Exceptions.MvxIoCResolveExceptionFailed to resolve
type Cirrious.MvvmCross.Localization.IMvxTextProvider
Cirrious.CrossCore.IoC.MvxSimpleIoCContainer.Resolve(Type)
at Cirrious.CrossCore.IoC.MvxSimpleIoCContainer.Resolve<Cirrious.MvvmCross.Localization.IMvxTextProvider> () <0x00023>
at Cirrious.CrossCore.Mvx.Resolve<Cirrious.MvvmCross.Localization.IMvxTextProvider> () <0x0004b>
<project>.Droid.Code.Menu.MenuActivity<TextMessageDetailsViewModel>.OnCreate(Bundle)
Android.App.Activity.n_OnCreate_Landroid_os_Bundle_(intptr, intptr, intptr)
at (wrapper dynamic-method) object.715a16ed-a35e-4884-89f1-5e2568dbe846 (intptr,intptr,intptr) <0x00043>
What can cause the problem that only sometimes it doesn't work?
Related
I have built an app in iOS and now building the app in Android. I'm basically done with the app but I'm running into a pretty consistent problem in the app. I will be going through the app hitting various pages when the app crashes. It seems to be pretty random and appears to be a memory issue. Each "page" has maybe 0-2 images on the page, but nothing major (small png files). I'm using a combination of android ImageView and MvxImageView. I'm setting the MvxImageView through binding ImageUrl like this:
local:MvxBind="ImageUrl CurrencyImage"
Here is the exception I get:
[mono-rt] Stacktrace:
[mono-rt]
[mono-rt] at <unknown> <0xffffffff>
[mono-rt] at (wrapper managed-to-native) Java.Interop.NativeMethods.java_interop_jnienv_call_nonvirtual_void_method_a (intptr,intptr&,intptr,intptr,intptr,Java.Interop.JniArgumentValue*) <0x0005b>
[mono-rt] at Java.Interop.JniEnvironment/InstanceMethods.CallNonvirtualVoidMethod (Java.Interop.JniObjectReference,Java.Interop.JniObjectReference,Java.Interop.JniMethodInfo,Java.Interop.JniArgumentValue*) [0x0008f] in /Users/builder/data/lanes/3819/96c7ba6c/source/Java.Interop/src/Java.Interop/Java.Interop/JniEnvironment.g.cs:12079
[mono-rt] at Java.Interop.JniPeerMembers/JniInstanceMethods.InvokeVirtualVoidMethod (string,Java.Interop.IJavaPeerable,Java.Interop.JniArgumentValue*) [0x00068] in /Users/builder/data/lanes/3819/96c7ba6c/source/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods_Invoke.cs:31
[mono-rt] at Android.Widget.ImageView.SetImageBitmap (Android.Graphics.Bitmap) [0x0002c] in /Users/builder/data/lanes/3819/96c7ba6c/source/monodroid/src/Mono.Android/platforms/android-24/src/generated/Android.Widget.ImageView.cs:1026
[mono-rt] at MvvmCross.Binding.Droid.Views.MvxImageView.SetImageBitmap (Android.Graphics.Bitmap) <IL 0x00032, 0x0019b>
[mono-rt] at MvvmCross.Binding.Droid.Views.MvxImageView/<>c__DisplayClass19_0.<ImageHelperOnImageChanged>b__0 () <IL 0x00011, 0x000b7>
[mono-rt] at Java.Lang.Thread/RunnableImplementor.Run () [0x0000b] in /Users/builder/data/lanes/3819/96c7ba6c/source/xamarin-android/src/Mono.Android/Java.Lang/Thread.cs:36
[mono-rt] at Java.Lang.IRunnableInvoker.n_Run (intptr,intptr) [0x00009] in /Users/builder/data/lanes/3819/96c7ba6c/source/monodroid/src/Mono.Android/platforms/android-24/src/generated/Java.Lang.IRunnable.cs:81
[mono-rt] at (wrapper dynamic-method) object.037ff22d-dd39-45fa-8726-c673a7d6897c (intptr,intptr) <IL 0x00011, 0x0003b>
[mono-rt] at (wrapper native-to-managed) object.037ff22d-dd39-45fa-8726-c673a7d6897c (intptr,intptr) <IL 0x00021, 0x000ef>
And here is the audit I see in DDMS:
10-13 17:26:06.213: E/audit(2793): type=1701 msg=audit(1476393966.213:869): auid=4294967295 uid=10198 gid=10198 ses=4294967295 subj=u:r:untrusted_app:s0:c512,c768 pid=14236 comm="APPNAME.droid" reason="memory violation" sig=11
Any help would be greatly appreciated. When I say consistent above, basically within 30 seconds of "hammering" around in the app something happens.
Devices: Most of testing on Samsung Galaxy Tab A and that's from exception above. Also have tested on older LG phone and latest Nexus. LG phone gets same error. Latest Nexus I have gotten the error but not as consistent. I can be on the app for a while sometimes with no issues.
While this didn't fix my issue with MvxImageView, I tried Picasso. I created a PicassoImageView object and created a public "ImageURL" that allowed me to still use the MvvmCross binding. I haven't seen the error since.
Here is the stack
System.ExecutionEngineException: Attempting to JIT compile method '(wrapper managed-to-native) MonoTouch.CoreGraphics.CGContext:CGContextDrawPDFPage (intptr,intptr)' while running with --aot-only. See http://docs.xamarin.com/ios/about/limitations for more information.
at MonoTouch.CoreGraphics.CGContext.DrawPDFPage (MonoTouch.CoreGraphics.CGPDFPage page) [0x00000] in :0
at Neva.PdfViewer.PageContentView.Draw (MonoTouch.CoreGraphics.CGContext context) [0x00000] in :0
at Neva.PdfViewer.PageContentTile.DrawInContext (MonoTouch.CoreGraphics.CGContext ctx) [0x00000] in :0 [7.1.1]
While we were not able to recreate this problem in QA or unit testing, this exception randomly happens on AppStore distributed installations.
Looking at DrawPDFPage in CGContext
public void DrawPDFPage (CGPDFPage page)
{
CGContext.CGContextDrawPDFPage (this.handle, page.handle);
}
where CGContextDrawPDFPage is a P/Invoke function
[DllImport ("/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics")]
private static extern void CGContextDrawPDFPage (IntPtr c, IntPtr page);
doesn't give us any hint. The link above http://docs.xamarin.com/ios/about/limitations is not really helpful.
My question is, what could be causing such an exception? What are steps to debug and fix it?
This exception (System.ExecutionEngineException: Attempting to JIT compile method ...) should be 100% reproducible.
The fact that it isn't, points at something else (and probably worse): memory corruption of some sort.
However without some way to (at least randomly) reproduce it yourself, it's close to impossible to track down.
My initial suggestion would be to try to figure out if there's anything at all you can figure out in order to be able to create a test case yourself:
Does it only occur for a certain set of devices (only iPad 2 for instance)?
Does it only occur for a certain set of customers (only customers in Iceland for instance)?
Is the exception exactly the same every time, or does the P/Invoke / stack trace vary?
Is it a low-memory condition? Did the app get memory warnings prior to this occurring?
Are there any required steps in your app (i.e. if the user does X+Y it may crash, but if he does Y+X, then it never crashes)?
I am using Facebook C#sdk to upload photos to user profiles using a Windows Service as a background job. And I am logging exceptions in almost every place that I can think of and for the most part it works fine. But occasionally, and sometimes it is quite frequent, I get the following exception, which does not get caught by my handler, and gets logged by the Windows Event logger, and terminates my service:
Application: PhotoService.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Exception
Stack:
at System.Net.Security._SslStream.WriteCallback(System.IAsyncResult)
at System.Net.LazyAsyncResult.Complete(IntPtr)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Net.ContextAwareResult.Complete(IntPtr)
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
From the looks of it, this is happening at FacebookClient.PostTaskAsync() method call, but I have no idea how to troubleshoot with the limited stacktrace information. Below is my photo posting method block:
public void PostPhotoToTimeline(string filename, byte[] photo, EventHandler<FacebookApiEventArgs> callbackCompleted)
{
var _filename = filename;
var mediaObject = new FacebookMediaObject
{
ContentType = "image/jpeg",
FileName = _filename
}.SetValue(photo);
_fb.PostCompleted += callbackCompleted;
var parameters = new Dictionary<string, object>();
parameters["file"] = mediaObject;
_fb.PostTaskAsync("/me/photos", parameters);
}
My biggest problem at the moment is, when this exception occurs, it terminates the service and I don't have service monitoring set up yet, so no way for me to find out the service has stopped. If I understand it correctly, this exception occurs in a separate thread and is not handled, thus it brings down the whole service. Is this correct? Any idea why this might be happening and where, or anyone faced this exception before? I have read about 'legacyUnhandledExceptionPolicy' to catch these unexpected exceptions. Will this prevent my service from terminating and is it good idea to use it? Sorry if I am asking too many questions in one go but these are all related and google hasn't been my friend on this so far.
Thanks for any help you can provide.
2 months gone and not a single answer, so I will post what I did to prevent this issue which might be useful to others. Still don't know the main cause for the crash but it is occasional, so using the flag "legacyUnhandledExceptionPolicy" has worked so far, with no unexpected terminations. The flag needs to be enabled in the config file:
<runtime>
<legacyUnhandledExceptionPolicy enabled="1"/>
</runtime>
Better explanation here: MSDN Reference
I am currently developing an application that needs to communicate with a MQTT server via a socket connection. As the System.Net.Sockets API tends to misbehave when switching from a WiFi network to a 3G network (and this happens quite a lot actually) I've decided to give the CFStream API a try. In doing so I've encountered several issues, as follows.
Creating a pair of streams with CreatePairWithSocketToHost crashes the application as soon as I call Open() on either one of the streams.
CFStream.CreatePairWithSocketToHost(GetEndPoint(), out mReadStream, out mWriteStream);
mReadStream.EnableEvents(CFRunLoop.Current, CFRunLoop.CFDefaultRunLoopMode);
mWriteStream.EnableEvents(CFRunLoop.Current, CFRunLoop.CFDefaultRunLoopMode);
mReadStream.Open();
mWriteStream.Open();
The crash occurs regardless of whether I call EnableEvents() or not. The exception is:
[ERROR] FATAL UNHANDLED EXCEPTION: MonoTouch.CoreFoundation.CFException: The operation couldn’t be completed. Cannot allocate memory
at MonoTouch.CoreFoundation.CFStream.CheckError () [0x0000f] in /Developer/MonoTouch/Source/monotouch/src/shared/CoreFoundation/CFStream.cs:236
at MonoTouch.CoreFoundation.CFStream.Open () [0x00040] in /Developer/MonoTouch/Source/monotouch/src/shared/CoreFoundation/CFStream.cs:248
at TestCfNework.RootViewController.TestCreatePairToHost () [0x00041] in /Users/adrian/Projects/TestCfNework/TestCfNework/RootViewController.cs:79
at TestCfNework.RootViewController.ViewDidLoad () [0x00000] in /Users/adrian/Projects/TestCfNework/TestCfNework/RootViewController.cs:24
at MonoTouch.UIKit.UIWindow.MakeKeyAndVisible () [0x00008] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIWindow.g.cs:124
at TestCfNework.AppDelegate.FinishedLaunching (MonoTouch.UIKit.UIApplication app, MonoTouch.Foundation.NSDictionary options) [0x0002e] in /Users/adrian/Projects/TestCfNework/TestCfNework/AppDelegate.cs:32
at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x0004c] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38
at TestCfNework.Application.Main (System.String[] args) [0x00000] in /Users/adrian/Projects/TestCfNework/TestCfNework/Main.cs:17
Creating a pair of streams with CreatePairWithSocket by first creating and connecting a CFSocket allows for Open() to proceed without crashing, but CanAcceptBytesEvent is never fired, CanAcceptBytes() is always false and any write attempt fails with a timeout.
mSocket = new CFSocket(AddressFamily.InterNetwork,
SocketType.Stream,
ProtocolType.Tcp,
CFRunLoop.Current);
mSocket.ConnectEvent += delegate {
Console.WriteLine("Socket connected");
CFStream.CreatePairWithSocket(mSocket, out mReadStream, out mWriteStream);
mReadStream.EnableEvents(CFRunLoop.Current, CFRunLoop.CFDefaultRunLoopMode);
mWriteStream.EnableEvents(CFRunLoop.Current, CFRunLoop.CFDefaultRunLoopMode);
mReadStream.Open();
mWriteStream.Open();
mWriteStream.CanAcceptBytesEvent += delegate {
Console.WriteLine("Write stream can now accept data");
};
mWriteStream.ErrorEvent += delegate {
Console.WriteLine(mWriteStream.GetError());
};
};
mSocket.Connect(GetEndPoint(), 0);
Creating a pair of streams using CreatePairWithPeerSocketSignature is the only one that actually produces a pair of streams that I can work with: opening does not crash and I am allowed to write to and read from respectively.
The API behaves this way both on the simulator and on the actual device. So, is this something I am doing wrong? Is it a MonoTouch issue? Is it a bug in the CFStream API itself?
MonoTouch version: 6.0.1.
XCode version: 4.5.
I wrote most the CFNetwork code in MonoMac / MonoTouch, so I should hopefully be able to help you with this :-)
Your code looks ok to me. It works fine with MonoMac (stand-alone Cocoa application on the Mac), but I see the same problem with MonoTouch. Opening the read stream sometimes works, sometimes not, opening the write stream always fails.
CFStream.CreatePairWithSocketToHost() calls CFStreamCreatePairWithSocketToCFHost().
After adding a new overloaded version:
public static void CreatePairWithSocketToHost (string host, int port,
out CFReadStream readStream,
out CFWriteStream writeStream)
which calls CFStreamCreatePairWithSocketToHost(), this is now working fine.
I just had a look at this and found the problem, will have a fix for it shortly.
About your second problem, the CFSocket API is hitting the same code path internally, so it's also affected by this bug.
To wake up the 3G network, you want to use:
http://iosapi.xamarin.com/?link=T%3aMonoTouch.ObjCRuntime.Runtime%2fM%2fStartWWAN
This is driving me nuts...
Two assemblies/projects in play:
An Infrastructure project, which has an interface in it:
IDtoMapping<in TDto, out TDomain>
And an app project, referencing Infx, with an implementation:
PatientMapping : IPatientMapping
...and a marker interface, just to be clear:
public interface IPatientMapping : IDtoMapping<PatientDTO, Patient> {}
When the app boots, this gets run:
_container.RegisterType<IPatientMapping, PatientMapping> ( new ContainerControlledLifetimeManager () );
This happens in the app project, through a system-wide bootstrapping process.
(Immediately after this line runs, (through a watch), I can successfully resolve it.)
Finally, we try to resolve it (in a WCF service, in the app projec)
public PatientService (
IPatientRepository patientRepository,
ISessionSource session,
IPatientMapping patientDtoToDomainMapper )
{
.. and it fails. With the ResolutionFailedException "Cannot instantiate an interface, etc.." I've put break points at the .Resolve call, the registration, etc.. everything is getting hit as expected. But when the app tries to Resolve/BuildUp the WCF Service, Unity can't resolve the IPatientMapping parameter... it's like it forgot.
I'm at a loss.. I upgraded to Unity 2.0, added that intermediate marker interface, removed the generic interface and just used the vanilla one.. all to no avail.
Other dependencies in the system resolve just fine, including the other parameters on that same WCF constructor.
The only thing my gut is telling me is could it have something to do with the assemblies? That the .Resolve call is happening in the Infx project, but the implementation actually lives in the app-project? At runtime, all assemblies are loaded, so it shouldn't really matter, right?
Thanks for any ideas!