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.
Related
Here is what I suppose: When the code causes a trap (system call or exceptions), xv6 will replace the registers with certain values to transfer the control to alltraps(), in which trap() is called.
But sometimes xv6 runs into trap() out of my expectation, and I want to know why it got into this trap. When debugging, after I set a break point in trap() and xv6 stopped here, I can only see this in the debugger (I'm using CLion). In the call stack, the bottom stack frame is alltraps() so I can't find out when and why the trap is caused.
I want to find out in which file, at which line the trap is caused for a certain call of trap(). Is this possible?
If you will examine trap() code more carefully, you will see that it also handles hardware interrupts (timer, ide and so on).
36 void
37 trap(struct trapframe *tf)
38 {
39 if(tf->trapno == T_SYSCALL){
...
47 }
48
49 switch(tf->trapno){
50 case T_IRQ0 + IRQ_TIMER:
51 if(cpuid() == 0){
52 acquire(&tickslock);
53 ticks++;
54 wakeup(&ticks);
55 release(&tickslock);
56 }
57 lapiceoi();
58 break;
59 case T_IRQ0 + IRQ_IDE:
...
So what are you seeing is hardware interrupt coming and processor transfers control to one of the IDT vectors then to alltraps then to trap(). Most likely you are facing timer interrupt, which is used for context switch.
I want to find out in which file, at which line the trap is caused for a certain call of trap(). Is this possible?
No it is not possible, because this is a hardware event and it has no relation to source code.
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.
i have the following stack trace:
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
1 MyApp 0x000836bd TFSignalHandler + 28
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
3 ??? 0x00000002 0x0 + 2
4 MyApp 0x000803f1 msgpack_unpack_next + 112
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
...
And i'm wondering how to read it:
I assume i go from the bottom up, eg line 7 called line 6 called line 5, etc.
What does the '+ 112' on line 4 mean? Is that a line number in the code file where it crashed?
What does the '???' on line 3 mean?
Thanks a lot
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
Crash was generated from +[TFCrashHandler backtrace] + 26; from whatever instruction fell at that symbol location + 26 bytes.
If that is really the bottom of your stack trace and it crashed there, then the TCrashHandler is obscuring the real crash. The real crash looks to be a couple of frames above.
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandler was what called +backtrace.
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Ewww... a signal trampoline. The app received a signal and the a trampoline was set to call TFSignalHandler().
There are situations where a signal handler might be called on a random thread. I.e. there is a minuscule chance that this particular crash had nothing to do with the parser and everything to do with a crash somewhere else. However, without knowing more about the parser, I'd question whether it is hardened against malicious input (which could certainly cause a crash like this).
3 ??? 0x00000002 0x0 + 2
Stack was undecodable. Ignore. Meaningless. Best case; fallout from compiler optimization. Worst case; somebody pooped on the stack and the backtrace mechanism can't figure out what is going on (highly unlikely -- usually, stack poop splatters to the point of preventing a full backtrace).
4 MyApp 0x000803f1 msgpack_unpack_next + 112
Ooooh... trickzy. Someone is using C to parse stuff. And it crashed. Whatever instruction was 112 bytes from the entry point to the function went boom. But, not really, because it called the signal handler and was handled by that; which is still a boom but the signal handler has effectively destroyed additional forensic evidence.
The "trickzy" comment references that an optimizing compiler against a big pile o' C can end up collapsing frames to the point that the crash could have happened in a function well below this one.
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
MessagePackParser was parsing when things went horribly wrong.
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
Ahh... yes.... somebody done grabbed some data from HTTP and it was malformed, causing the crash.
Bottom line; the parser got bogus input and crashed. There was a signal handler in place that tried to help by creating a backtrace, but -- apparently -- didn't really reveal any more info. A long shot alternative is that the signal was generated somewhere else and this thread was randomly selected to handle it -- if you can consistently recreate this crash, the random-thread-signal case is unlikely.
Unless you have a capture of the input data or can somehow guess how msgpack_unpack_next() might crash, you are out of luck without providing more info.
The '???' is something that can't be identified, probably code that was compiled without symbols, but could also be something else.
Those are the line numbers in the implementation file. And the hex is the pointer in memory to the line call.
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).