Here is the problem:
A program whose size is 460 bytes will access a series of addresses: 10,11,104,170,73,309,185,245,246,434 and 364.
The page size is 100 bytes and the program only uses 200 bytes in main memory.
If the OS use FIFO algorithm, how many page fault interrupts will occur? Why?
I think may be like this.
address | current Memory | status
10 0-100 page fault
11 0-100
104 0-100|100-200 page fault
170 0-100|100-200
73 0-100|100-200
309 100-200|300-400 page fault
185 100-200|300-400
245 300-400|200-300 page fault
246 300-400|200-300 page fault
434 200-300|400-500 page fault
364 400-500|300-400 page fault
Am I right? I notice this program is 460 byte. And page alignment is 100byte.
Related
For this question:
Trace the fetch-decode-execute cycle for the following program:
1 .org 100
2 Load One
3 JnS IncRoutine
4 Halt
5 IncRoutine , HEX 0
6 Add One
7 JumpI IncRoutine
8 One , DEC 1
For the load One instruction:
Step RTL PC IR MAR MBR AC M[103]
Load One (initial values) 100 - - - - -
Fetch MAR←PC 100 - 100 - - -
IR←M[MAR] 100 1106 100 - - -
PC←PC+1 101 1106 100 - - -
Decode MAR←IR[11-0] 101 1106 106 - - -
(Decode IR[15-12])
Get operand MBR←M[MAR] 101 1106 106 0001 -
Execute AC←MBR 101 1106 106 0001 0001 -
I do not understand where the 1106 came about for the instruction register as shown above. If someone could explain that would be great
1106 is the opcode for the Load One instruction. When it starts your trace, it hasn't even fetched the instruction yet. It loads the program counter into the memory register, then fetches the contents into IR. So, IR has "the instruction to be executed". The next step has to decode the instruction (1) and the address field (106).
By the way, it would have been somewhat easier if you had given us even the slightest clue where this came from. This is a fictional instruction set for some fictional computer, but without the details, we're just guessing.
I'm trying to decrypt a low memory crash log from my iPhone, and I see that the count number for my application is huge (35314). What does this indicate?
Processes
Name UUID Count resident pages
MobileMail <bd66c3ae9a91225e745044a8051e5458> 906 (jettisoned)
MY_APPLICATION <fe63329c069b3b7fb2796eec33669af6> 35314 (jettisoned) (active)
dataaccessd <cb2dfcefb43430f4550f0187890de64a> 365
apsd <5aa3f4fcfc53b00dde75378aed8e1af3> 216
lsd <f711e4c8e9e3fe740bea8de2b98c3f25> 358
notifyd <f36b987ef3d560324ff7384c1b9e448e> 91
BTServer <399771bd4f5090d5572ab3c753a01c7f> 136
CommCenter <86ed1b990c91d8d3ac6533f2400ab973> 219
SpringBoard <c014cf8d4559f5596a92131934f61166> 6017 (active)
accessoryd <0e514c4b9547bbb5f153435a91b7b831> 114
configd <dcdf074c5152eb97309ea55d200d32ad> 402
fairplayd.K48 <b6aee1a5594de9cadfee552a00f16978> 82
locationd <f496d6de4951e767807ed191addf19ec> 360
mDNSResponder <b14bb33d877732ed866786776833f72c> 178
mediaremoted <ca81c5e8d3b982bca9e1c0f05e203eca> 150
mediaserverd <b09e22f7c7495c8ee56691c74beac1bd> 1343
lockdownd <1bb238048747f8407c2ff1cf0d920c42> 222
syslogd <5532491b0def7a60037a52400c48e715> 102
launchd <bff2d05de78d5832b2c9604413668f3a> 102
**End**
Thank you!
You can see a description of what a resident page is here: http://en.wikipedia.org/wiki/Virtual_memory (specifically under the "Permanently resident pages" title). Basically it is the number of memory pages your process is holding and it really only means that you are using way too much memory (which you already knew ;) ).
My app crashed because of Low Memory. I'm not sure if its entirely my fault because it lists about 7 or 8 other applications that crashed alongside? How should I handle this?
Incident Identifier: 2CC74C33-179F-4CD2-8FAA-00CF0A344749
CrashReporter Key: 1657e021ecba3a19c5ed9f0cff62947a426a2bc2
Hardware Model: iPhone3,1
OS Version: iPhone OS 4.1 (8B117)
Date: 2010-10-24 12:20:38 +0100
Time since snapshot: 2044 ms
Free pages: 1329
Wired pages: 21508
Purgeable pages: 0
Largest process: Instagram
Processes
Name UUID Count resident pages
securityd <3dcc6e23849cb3ee197720700284156d> 309
sandboxd <4c01175d65fe7efb292e307389d3387b> 178
ReportCrash <2ad0d335f1b93cc74e0b5be79850229d> 255
mDNSResponderHel <a0d7f455b6f2069587ea7bc956d79655> 70
Stocks <55e537a6739e58dc068e1436930213ba> 1162
mediaremoted <507d59f44f735d6e2855b23a6275557a> 216
MobileMusicPlaye <02ed082c795446617957bbae8974a2c8> 1052
dataaccessd <40c418e18e9bbd950ef7e3fb593645de> 618
spd <6419715f9e6891201e16b722fca84793> 126
MobileMail <215c71d2434ce352d04786b93cda5340> 2483
calaccessd <90c4c48a02f0dbf0d1adaad27b8d5945> 427
MobileCal <db3e6efa621fc989420ccc43298d5b80> 1619 (jettisoned)
StockTwits <3786112667f535bff10bb6f7966bb852> 2067 (jettisoned)
Mint.com <0f38a50fd98c755ef34e0fe8b0c25adc> 4461 (jettisoned)
AppStore <99bf23a9224aa148ac3e009873f9c7b9> 998 (jettisoned)
Reeder <dcb69039fa5b4426b3db9f9920054f3e> 5835 (jettisoned)
Meebo <22f145af489fb92066006a5a3cac813a> 3684 (jettisoned)
MobileSafari <67a5ebc3754e0ce1e482760c7e56f9c5> 3512
Skype <d570c35d6d2f51713e874937dd8112f4> 4769
Facebook <ae1fa9da7f8951ffbf693bbd0ed36aaf> 2459 (jettisoned)
MobileTimer <98640aaee653fc9188652d6cdab13d67> 1294 (jettisoned)
Twitter <62edb7ce453c603ad1b8b3bdcbc4910b> 5843
MobileSlideShow <40eded841026ed418bebe49a342f2c8f> 3566
Instagram <25e2a98b5d3de6f2cf2f246df8a49a9d> 11523 (active)
misd <d9b8f85780f931007d309fc836185ab0> 119
MobileStorageMou <bd2184fe17b3c9ccbadd9120bd669c99> 102
Preferences <9123dcc666c97bb1d63a5921968c8b34> 1666
MobilePhone <b50b6283b8c52a51fb9e48ee5c909b80> 804
imagent <4ef86a68405738280f19e5fbc0af56db> 291
lsd <4fb2cf7b5475b39b2c56d9588821eb45> 157
SCHelper <30ca097cbb6306cf66157da7fd4de07c> 110
notifyd <ab40010781bef81228df18acf1acdbb2> 129
BTServer <ce7c062b4df09b835c77a6086b7ef0d8> 136
CommCenter <a8a6257faa2a5213f0a2f5c763f9acfe> 335
SpringBoard <983033e585706c1c6c99eed85cd8dbdb> 8315 (active)
accessoryd <b99ccd1b099c015edb93e8d1cbf03e36> 109
apsd <f031a0e787d8840097a4812fb1c89f5e> 240
awd_ice3 <b598d42ac4fdd950ac5c2c9a1835f70e> 124
configd <b2b3af98743381e759dd5b17115a0378> 548
fairplayd.N90 <3ae05b3bbcb034b0d4d4712e8fc19f99> 95
locationd <963c5d93cfaf1b1139045b1658ecfc26> 1031
mDNSResponder <68dc311f118d171ede7b91f43c323b7d> 235
mediaserverd <3ebe3a043c2dba96b70d8ede30bcb6ab> 1220
lockdownd <bfeda752b819f06f4828e112d3ca695c> 326
syslogd <60e8005a73e76d6ee81a8b45a9443a16> 94
launchd <b15ff1a8f2f37c3b0df0343899757b17> 103
**End**
This is expected behavior. Background apps continue to run only at the frontmost app's leisure. If the frontmost app decides it wants your resources, you have no choice but to give them up immediately.
Make sure you fixed all leaks in your app with instruments and with X-code's built-in slangs analyzer.
Run your app as much as time possible with instruments.release all instance variables in dealloc methode and make sure you are reacting to didRecieveMemoryWarning:.
put a breakpoint in didRecieveMemoryWarning: then you can confirm that it is your fault.
I doubt you can. Always check the return value of your allocations, free up memory when you're done, use as little memory as possible, and (I don't remember if this'll work on iPhones) run valgrind to find any memory leaks in your app
I had a similar problem with an app of mine crashing on a low memory warning. I was already freeing up memory in the didReceiveMemoryWarning delegate methods but it was still crashing.
Eventually I commented out the [super didReceiveMemoryWarning] in my RootViewController (I had created my app using the navigation app template). I think the crash was occurring because the RootViewController was being released in that call.
By the time iOS decides to terminate your app it's already too late.
Instead, if you application is active, you need to shed any memory you don't need when you receive the applicationDidReceiveMemoryWarning: message in the UIApplicationDelegate or the equivalent notification.
To minimise the chance of your app being expelled from memory when another app uses too much, all you can do is release any data you can recreate when it goes into the background (pretty much the same process you should be going through when memory is low).
However, you can't ever guarantee that you'll never be terminated.
Heres the problem. I have an app that is essentially an image gallery, it pulls images down from an xml feed, and archives them locally, then gradually loads 5 images at a time into the scroll view to be displayed.
I have had thousands of problems with using [UIImage imageNamed:...] and NSURLRequest/NSData as both cause the app to cache excessive amounts of data. Anyway, I now have the app running at an almost constant 25-30MB, with no sudden spikes, and with only a few kB of data being leaked from memory (due to NSKeyedArchiver and me retaining some values). However the app ALWAYS gets terminated by the OS for (what seems like) no apparent reason.
Sorry if I'm being a bit stupid and not spotting something, the crash report does appear to be telling me that tonnes of memory has been paged by the app, however the allocations and leaks instrument is telling a different story... and really I supposed my question is more along the lines of "why is instruments lying to me?"
Incident Identifier: D258E503-D024-4265-B079-E6C47DE5DA29
CrashReporter Key: c3904eb2c9cf4bf4f89f53fb9c836ad44586684f
OS Version: iPhone OS 3.2.1 (7B405)
Date: 2010-09-21 13:27:50 +0100
Free pages: 464
Wired pages: 12587
Purgeable pages: 0
Largest process: MediaLib
Processes
Name UUID Count resident pages
MediaLib <6db92ce87a5d7e287702f2cb87ba8c53> 30579 (jettisoned) (active)
debugserver <f885fe2348e72988381a73137cc90c7b> 127
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
afcd <ddda2413b8953e5c56721dfe05a82d78> 68
syslog_relay <1c73f841b191556b6911bc6b4736b50f> 63
DTMobileIS <b34df288cd9a07a995933bbd6b66717a> 1169
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
ptpd <e3f855cfd629600a4812e7e90c77667e> 191
syslogd <6990426209e51a8ee13c91cd1a050a2e> 78
mediaserverd <2eda3ce5e1c8a1a4d7b8271cef1f2d12> 314
debugserver <f885fe2348e72988381a73137cc90c7b> 74
debugserver <f885fe2348e72988381a73137cc90c7b> 74
debugserver <f885fe2348e72988381a73137cc90c7b> 74
lsd <eb108595d2a932a8d244d1ab7386cd0f> 121
apsd <0775f0d80d1cd1fb4b562d2f94caf051> 172
notifyd <74e4a487a89c31f68917b22605baf6c6> 68
BTServer <21dd98c0ab29b910cd51cb703a9cb9b9> 107
CommCenter <e4b9cc04f083f22232c92ee1363fe669> 170
SpringBoard <745085d9a24a8529f0ceb6c33d766873> 4821 (active)
accessoryd <59ca0ba146c28bf5c8ab6e3d2e81bbad> 97
configd <36001fe17103f8af6d3b525cb23ac8a0> 305
fairplayd.K48 <2d997ffca1a568f9c5400ac32d8f0782> 85
locationd <60fd4d90fec18a76ffc0b8a45351fe54> 600
mDNSResponder <a6f01dd493e3d2bfe318f5d44f8508e2> 107
lockdownd <378f09833cdc57b1b60e42d79c355938> 273
MobileStorageMou <7f2cd9f90fab302a42a63460b1c4d775> 67
launchd <880e75c2db9c0f670516c58935e89b58> 80
**End**
Many thanks in advance for someone who can give me a slap and point me in the right direction ;)
EDIT:
I have just run the app through the activity monitor instrument and this is giving me a "Real Memory" readout of 65-80MB, could this be due to allocation of memory on another thread, which isn't picked up by the allocations instrument?
You should know that NSImage#imageNamed: caches the image. In other words, you lose fine control over the life cycle of those images. Use NSImage#initWith... instead and the cache will not be used.
Also know that a .png image that is a 2KB download can easily be a 6MB image when loaded into an UIImage. Image data is decompressed when loaded into an UIImage so don't look too much to the original size. Look at the size of the bitmap. Usually simply width * height * 4.
You mention that NSURLConnection and NSData are causing memory issues. This is probably because of improper usage. Like failing to do proper memory management.
Post code or more details if you want better hints about resource management.
I read a few memory-leaking issues with UIImagePickerController, so I changed my code to using member variable and was able to take more than a few pictures with the camera. However, I find the photo-taking to take longer and longer time, and eventually it crashed at around 25 photos.
There are two things I do after the photo in the didFinishPickingMediaWithInfo,
1) scale the image down and display that (50x50)
2) save a 320x460 to CoreData
I didn't release any UIImage since it's on the autorelease pool.
What should I do to let the picture-taking go on forever?
Below is the crash log (Type of crash log is listed as Low Memory)
CrashReporter Key: 8e197e26271ae3c2c4d3e725807d023e3c2354cb
OS Version: iPhone OS 3.0 (7A341)
Free pages: 251
Wired pages: 10127
Purgeable pages: 0
Largest process: Journal
Processes
Name UUID Count resident pages
Journal 8960 (jettisoned) (active)
debugserver 130
MobilePhone 529 (jettisoned)
syslog_relay 53
notification_pro 54
DTMobileIS 2285
notification_pro 53
ptpd 276
mediaserverd 252
debugserver 77
debugserver 78
SpringBoard 2470 (active)
notifyd 80
BTServer 123
CommCenter 262
accessoryd 84
configd 70
configd 266
fairplayd 67
mDNSResponder 89
lockdownd 252
syslogd 82
launchd 70
Can you provide backtrace / more crash information?
Is it possible to manage the UIImages yourself, or wrap the call that gives you an autoreleased UIImage with your own NSAutoreleasePool so you can control its lifetime?
Have you tried using Instruments to detect for any possible memory leaks?
This question is pretty old, so hopefully already solved but consider 2 points:
CoreData is a terrible place to save BLOBS, it's really good at text but not so much for binary data.
Your image will live in memory until you give it some place else to go, the only way to get them out of memory is releasing all references to that data.
I would consider caching your images to the file system until they are required again. Basically follow this process:
Capture Image1
Want to take another? Capture Image2 and write Image1 out to disk.
Store the filename for Image1 in CoreData for later retreival.
Repeat as necessary.
It is still possible that you will run out of disk space eventually, but you will have a lot more available disk space than memory, and you can always purge unwanted images from disk or force your user to deal with them in some other convenient manner (upload to the cloud for example).