My app is like a tweet feed reader. But with use, the app's responsiveness slows down in the wp8 emulator. By being unresponsive, I mean the progress bar indicator speed slows down, no links respond, none of the app buttons respond and the app suddenly closes.
I think it is a memory issue with the emulator. Am I right? I can't test it as I don't have a device yet.
Even on increasing the memory using the Hyper-V settings I didn't observe much difference.
I have an in-app browser which works fine for the first 2-3 links but then makes the app hang!
This doesn't sound like a memory leak. What you're describing is a slow-down which is caused by putting too much work on the UI thread. Overall you should offload as much work as possible to a background thread or the compositor thread.
The app suddenly closes sounds like some unhandled exception, but it's hard to tell which one. You said the app works fine on WP7. Have you looked at known app compatability issues that occur once WP7 apps are upgraded to WP8? Check it out on MSDN # http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206947(v=vs.105).aspx
This really isn't enough to go on. Is there something printed out in the output window once the app crashes? Can you tell what's the last managed method to be invoked before the app crashes? Can you try profiling the app for CPU and see what's the method that's most invoked? And profile for memory usage and see how's memory consumption right before the crash?
Related
I've been dealing with a fault found during testing that I can't seem to get to the bottom of. I have a Windows 8.1 application running on a laptop on Windows 10. The user was using the application, left the laptop for a couple of hours, when they came back the application had disappeared and had lost the data that hadn't yet been saved. This has happened twice on the same machine.
Digging through the Event Viewer on the machine, it appears the following scenario happened:
Application was started
Device went into suspend
Device resumed
During the resume process, the following event appeared in the Event Log:
Package XXX+App was terminated because it took too long to suspend.
Running through the suspend mode using the Visual Studio tools it seems to take around 300ms to run the code that saves the current state.
I don't understand why the application would be suspending while the device itself was resuming. Could this be a case of the app suspend started before the device suspended, and when the device resumed it decided it'd had long enough? In which case what is the correct way to handle this?
Or is this something completely different? I'm not certain where to go with this and can't seem to find any documentation that covers the app suspend/resume in conjunction with a device suspend/resume.
Thanks
I've completely failed to understand the reason why i get this exception so it would be nice if someone would be so kind to look at my project and suggest any reasons for the issue. I understand it's quite difficult to look at unknown project so even any tips would also be nice.
Problem description: i've ported my own ZoomControl from WPF to StoreApp and use it to zoom in/out graph using ScaleTransform. When i work on default/far zooming level all seems fine and no memory spikes occur but as i zoom-in deeper unmanaged memory usage burst very high and fast resulting in OOM exception. I've profiled using dotMemory and tried to isolate different parts related to zooming including animation cut off and template simplifying to no avail.
Another strange thing i've noted: if you zoom in w/o crash and alt+tab to task Manager you'll see significant memory usage drop, then if you'll back to app and pan content with the mouse (don't touching zoom) you'll got lag and can see huge memory usage spike in Task Manager.
The weird thing is that it works fine on one zoom level and crash on the other, This is mind blowing. I just don't understand why there is so high memory usage in zoomed in state.
I'm working on open-source project you can get here. Run METRO.SimpleGraph project and use mousewheel to zoom in.
I'm working on an app using SharpDX to render DirectX content to a DrawingSurfaceBackgroundGrid in Windows Phone 8.
I've found that, if the app goes out to the photo picker or suspends/resumes through Fast Application Resume, memory utilization will increase by about ~2mb and prior resources will not be reclaimed. This means a DirectX-based app using DrawingSurfaceBackgroundGrid will eventually run out of memory on user-initiated actions.
The leak starts once DrawingSurfaceBackgroundGrid.SetBackgroundContentProvider is invoked with a SurfaceBackgroundContentProvider. I'm using a DrawingSurfaceBackgroundContentProviderNativeBase implementation that has empty method bodies for all abstract members.
An isolated repro can be found here. Repro steps are: build and run the app, click "choose photo", hit the hardware back button, observe memory spike.
Anyone else seeing similar?
This was a bug in SharpDX, which has been resolved in this commit.
I am developing a phonegap app using HTML, CSS, jquery in Blackberry and in this app, sometimes when I relaunch the app, I am getting memory alert and app gets quit. I have placed all images that I am using in a folder. How can I handle the memory issues?
Even I am facing a similar issue of device memory low in my HTML5+Phonegap BB app.
I face this problem often in BB 6.0 device but in BB 7.0(9900) I haven't ran into this problem yet.
On page 24 of the link posted by tennesha the BB memory architecture is briefly explained by tneil . I quote
"The amount of physically allocated memory varies between device models, but lets say on average it's approximately 40MB of RAM. This amount of memory is allocated for both running WebKit (loading the engine into memory, running JavaScript, displaying pages, computing layout, scaling images, etc.) and also loading your content in the view.
All apps on the device share the same WebKit instance so everyone shares the same 40MB space. Think of each app using a web view as creating a "virtual tab" in the same web kit instance."
Here's the link for your reference.hope this helps.
http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Device-memory-is-Low-issue-for-an-WebWork-app/td-p/1166441/page/24
Hope they solve this issue at the earliest.
Blackberry has a memory leak issue that is not resolved as yet. I use to develop apps for blackbery using html 5 but pretty much gave up. The platform has too many issues and is not ready for html5 app develpment. You can follow this link and see if there is any thing useful you can garner from it: http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Device-memory-is-Low-issue-for-an-WebWork-app/td-p/1166441 . Oh and by the way dont expect to get much real help from blackberry with this.
Any ideas on how to get memory usage, Javascript errors, etc. from Chrome running on Google TV?
I have a page that is getting the "Aw, snap!" error when viewed in the Chrome browser on Google TV (Logitech). The page is fairly simple, but it does load a bunch of photos, though only up to 7 at a time (the photos are loaded using JavaScript). The photos are 640x480 and ~500KB each. They are stacked and the top one fades out (using jQuery) until all are gone then a new batch is loaded.
It only crashes on Google TV (it runs fine on Windows 7) and it takes a while before it crashes (I can get it down to about 10-20 minutes before it crashes by turning on a "fast mode" on our page).
Unfortunately I can't figure out how to get any information that might help me debug it. It would be cool to be able to get Chrome's developer tools on the Google TV device.
Currently there is no way to pull debug information from Chrome on Google TV. The Logitech Review is rather limited in it's RAM and you may be encountering an issue there (I don't know how big these images are). It is also possible that you have a memory leak in your javascript code. This might be hidden on other systems running a browser as there would be more memory to buffer you from seeing the error.
My advice would be to create a virtual machine (VirtualBox is free and runs on Windows) - create a VM with limited memory (256Mb Ram for instance) and install Ubuntu or some other flavor of linux that can run Chrome. Then run your app in the VM and see what happens.
Failing that you could always try loading the imaged with static image tags and see if it is the images that are causing the crash. If it's not the images then I would say look at your JS code closely and perhaps run it through JSLint (http://www.jslint.com/)