I am developing an application that needs to record a lot of data, which should be sent to the iPhone later. I am using CoreData and sometimes the quantity of memory used reaches 100 MBs, and also the CPU can reach 100%. I can see this during debug, but during debug the app doesn't crash because there are no memory/CPU limits. So the problem is that every time that I use the app without debugging, it may crash every 2-3 minutes but no crash log is generated, and I can't understand why and in what line of code it crashes. Is there a way to force WatchOS generating the crash logs?
Edit
If at least there is a way to debug the application with real memory/CPU limits (which are nonexistent in debug mode), so that I can understand why and where it crashes, or if there is any way to make some diagnostic to understand the unexplainable crashes, please let me know.
Related
We developed a Flutter windows desktop application for POS machines. One of the main feature is printing bills. We used https://pub.dev/packages/esc_pos_printer library which prints but, after printing 100+ bills the windows shows low memory alert and system hangs. While checking task manager it is found that committed memory use increases while printing and when it hits the maximum, system hangs. Please help to find a solution.
I've uploaded my mac build to the app store. I enabled break points for all exceptions. Will this by any chance effect the app on the app store? I don't think it will, but want to make sure. Don't want to reject my app and reupload.
Breakpoints only work when running in the debugger so, no, they will not have any effect on an app sent to the AppStore.
However if your app hits an exception when running on a device it will crash unless the exception gets caught, which is unlikely. Using the exception breakpoint during development is useful as it stops execution when the exception happens so you can get more info about what happened. Without the breakpoint the exception will almost always lead to a crash.
Keep an eye on crash reports in iTunes Connect to see if people are running into the same crash on a regular basis. If they are you have work to do.
When I run xcode instruments and I profile on the emulator, my UiViewControllers Dispose methods are being called instantly after the view is removed. But when I run the app on the device, the dispose methods of all the UiViewController are never being called!. Or are called very slowly and the memory gets too high.
I don't know why this is happening. The problem is that the only way to get the app, in the device, to call the dipose methods is when I manually perform a Gc.Collect() in the AppDelagate ReceiveMemoryWarning and DidEnterBackground(). When any of those methods executes, the memory drops from 140MB+ to 70MB.
This is the image of the memory when app is running on the emulator.
Emulator Memory Allocation
And when I run the app on the device.
Device Memory Allocations
As you can see on the emulator the dispose methods are being called every time a UIviewcontroller is remove. But in the device, the dispose methods are never called. The drop that you see in the image of the device is when the app goes to beckground and I manually call a GC.Collect().
Why isn't doing it automatically in the ios device, like it does in the emulator?
I am very new to xamarin, I have spent 4 days trying to figure this out. I really don't know what to do.
I hope someone can help me.
When running Xamarin.iOS in debug mode on the simulator, there is a thread that continuously calls GC.Collect() every few seconds so the garbage collections happens way more often than on real device.
This is mostly to help you finding bugs in your code faster (like accessing a managed reference that is already gone). So this is the reason you are not seeing the collection happen as often as it happens on simulator when deploying to device.
You should not worry too much about collections not happening as often, GC heuristics will determine when it should happen, the times you do need to "worry" are when you are working with big managed objects like images etc. but creating those objects inside a using statement should be enough.
Has anyone encountered a situation where DebugView application suddenly stops working, e.g. there is an application that calls DebugOutputString Win32 API but the output stops appearing in the DebugView application window? Can it be caused by high load of messages? any other pathological condition?
We don't know if DebugView crashes or just stops receiving messages. The application and debugview are installed on customer machine with no direct access. We just see that DebugView output stop exactly before the customer experiences the problem (not connected to debugview). And it is frighteningly consistent.
The problem was DebugView running out of memory. User Ctrl-H to limit the window size.
I think DebugView should be improved to put some indication that it cannot allocate memory any more and put it to log file.
I have to run this program millions of times. It's not the most stable beast, and it crashes around 5% of the time. When this happens, I don't want a popup, or WerFault to take 30 sec to take a dump, or anything - I just want it to silently and immediately disappear, and I'll figure out it crashed from the process exit code.
I already have Windows Error Reporting Service disabled, and my AEDebug key deleted. However, werfault is still trying to take a dump on crash. Help?
That can be annoying... especially if you're doing a lot of code-debug-compile-deploy-test iterations.
It looks like there are a couple of registry entries here that help control the behavior:
http://msdn.microsoft.com/en-us/library/bb513638(VS.85).aspx
Here's some information on how to exclude your particular application from error reporting, without completely disabling error reporting:
http://msdn.microsoft.com/en-us/library/bb513617(v=VS.85).aspx