I have a new version of my model which has one extra attribute in one the entities and nothing else really.
I have setup automatic migration as there is nothing else to migrate,and what happens is that in ios4.3 it works as expected but in ios5 the call to [persistentStoreCoordinator_ addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:options error:&error] crashes the app saying bad access.
is there any bug documented regarding migration in ios 5 or has anything changed regarding automatic migration?
I cant get any more info on the specifics of the crash hence my question is quite general, but was just wondering if anyone else has experienced difficulties migrating with ios5?
Seems to be a bug in CoreData. Creating a MappingModel and using this options solved the problem for me:
NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption,nil];
I am not sure about what has changed, but in general EXC_BAD_ACCESS errors are usually caused when you try to send a message to a released object.
refer Break on EXC_BAD_ACCESS in XCode?
Related
I noticed that Custom Vision is now returning the message {"code":"NotFoundIteration","message":"Invalid iteration"} instead of the expected (and previously provided) results.
Something has recently changed on the API call?
Thanks
I have seen the same issue happened and the latest news I got from support team is: Problem was identified ; due to recently introduced defect some published models were removed ; after which prediction requests against these published models would fail. The original bug was fixed and a repair program was ran that put back the missing published models. So I think your issue should be fixed now as well. If not, please let us know. Thank you.
Regards,
Yutong
It seems that when I reference AutoMapper v3.1.0 in my Xamarin.iOS project, the build fails with this error message:
Error MT2002: Failed to resolve "System.Linq.Expressions.Expression System.Linq.Expressions.ExpressionVisitor::Visit(System.Linq.Expressions.Expression)" reference from "System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" (MT2002)
When I roll back to the revision before I added this, it all works fine.
Unfortunately, I've already done quite a bit of work with AutoMapper in my unit tests and it would be problematic to remove it now. I guess that's a lesson to learn: just because it works in a test doesn't mean it works in Xamarin.iOS.
I would be very grateful if anyone has any ideas.
Edit: I have now discovered a MonoTouch directory in the AutoMapper package, but referencing the AutoMapper.dll and AutoMapper.iOS.dlls found within does not solve the problem.
Edit #2: This issue only occurs when building for the device - I guess the MSIL to native converter doesn't like AutoMapper for some reason. I'm trying to find a way to "hint" to this compiler that we need these symbols, which is what I think the purpose of the LinkerPleaseInclude.cs file is.
This issue is temporarily resolved - I had to hack out the offending symbols in AutoMapper and recompile it. Please see automapper issue #429 for more information on what symbols I removed. Until AutoMapper is updated to fix this problem, that's how you have to solve it for now.
The reason for this is explained concisely in another StackOverflow question - basically there are subtle differences between the .NET and Mono frameworks that in this case are incompatible with AutoMapper.
This answer previously stated that you should turn off linking to work with AutoMapper. While you can do this for development, it's not suitable for production use as it will yield a massive binary and you will not be able to submit your app to the app store.
I had everything working fine with automatic migrations set up and working. I had just made a number of foreign key changes in my domain classes and when I started my app I got an illegal column "CreatedOn" exception. Browsing I found that this error is typically due to moving from ef 4 to ef 5 and back. I've always just used ef 5. I couldn't find any reason for the error so I decided to go back to basics. I turned off migrations and set my initializer to "DropAndCraeteAlways". It dropped the db but didn't create a new one. So I moved further back to basics and removed migrations altogether and set the initilizer to "CreateIfNoneExists". Still no db creation. I'm at a loss as to what else to try or how to debug. The only exception I'm getting is when I try to initialize the db I get a db not found which is obvious. Any help will be greatly appreciated.
Entity framework can get a bit grumpy if it cannot figure out how to resolve relationships - do you have any more details of the error? Bear in mind the final error you see may be the result of a failure earlier in the chain.
You might be able to see more by running the Update-Database command in the package manager console.
Might be worth looking at the Fluent Relationship API, it's written for 4.1 but I believe it is much the same.
Is there anything that would cause MonoTouch to not generate crash reports when the app crashes or should it always generate one without fail? ('cause mine is failing)
In my project I hard coded it to throw a NullRefException on a certain action. I would expect to see a crash report written to the Device Logs in XCode but I am not seeing any report generated.
The Console outputs a managed stack trace of where the exception is being thrown though.
You might be wondering why I would want a crash report if I can see it in the console? Well, I want to make sure that crash reports are being generated on test devices and on production builds.
Update: I noticed that upgrading MT from 3.2.6 to 4.0.1 will allow my app to generate crash reports. Unfortunately we're having instability issues with our app running on 4.0.1. Why would 3.2.6 be any different when it comes to crash reporting?
Do you happen to have a top-level exception handler in your "Main" method ?
Something like below? That would keep you from getting a crash report, since it is a clean exit as far as iOS is concerned.
static void Main (string[] args)
{
try {
UIApplication.Main (args);
} catch (Exception e){
Log.ErrorFormat ("Toplevel exception: {0}", e);
}
}
Some reason upgrading to MonoTouch 5 fixed this.
Is there a memory lead issue with the AVAudioPlayer object? I'm getting a memory leak when using AVAudioPlayer in the simulator. It doesn't matter how I created the AVAudioPlayer. I've used initWithContentsOfURL and InitWithData. Below is a snippet of the code. Full project # Github https://github.com/docchang/MemoryLeakAVAudioPlayer
NSError *error;
NSURL *playerURL = [NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:#"Bell" ofType:#"m4a"]];
self.playerWithURL = [[AVAudioPlayer alloc] initWithContentsOfURL:playerURL error:&error];
if (!playerWithURL) {
NSLog(#"no %#.%#: %#",#"Introduction2", #"m4a", [error localizedDescription]);
}
playerWithURL.volume = 0.9f;
playerWithURL.numberOfLoops = 0;
[playerWithURL play];
However there is no memory leak when testing it on the device. This issue is starting to leaning towards issue with the AudioToolBox library, but just want to confirm it with stackoverflow folks.
I am getting the same memory leak when using AVAudioPlayer. I have seen a few posts about similar occurrences of this leak with the AVAudioPlayer and VideoPlayer libraries around the web. It appears to be a problem with the library itself (blame Apple):
iPhone: OpenAL & AudioToolbox leak
https://appcelerator.lighthouseapp.com/projects/32238/tickets/1992-ios-strange-behavior-and-intermittant-mem-leak-on-embedded-video-test-case
Edit: Also seeing the leak disappear when the target is run on the device.
Just ran a test as I was experiencing the same issue. Instruments showed a leak at the start of an app when sound was played using AVAudioPlayer. It was only registered once at the start. The sounds generated afterwards have not had any further leaks.
When I ran the same app build on my iPhone using Instruments, there was no leak at all.
I'm running iOS 11.2.5 and Xcode Deployment Target is 11.0
Looks like it is just an Xcode bug but could be related to MacOS.