i have read it when i was learning linking. When the program is going to be executed it was first linked by linker. At that time it was put in work area. Now i want to now what is this work area?
Static linking is done as part of the compilation process today.
Compile->Assemble->Link = Executable.
Typically when a program is loaded today on the desktop, it is placed into virtual memory and any dynamic linking is performed then.
Related
I'm tasked with upgrading a lot of legacy models and scripts made in an older version of Matlab/Simulink and have it running smoothly in R2018b. Among other requirements I'm not allowed to have any warnings issued upon execution of .m scripts or Simulink models. This is generally tedious but straightforward to comply.
However, there is a specific warning that Matlab does not give me hints on possible sources:
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software OpenGL. For more information click here.
The link opens the Matlab Help page titled Resolving Low-Level Graphics Issues, which describes issues I'm not finding (or at least not noticing)
I do note that many scripts I run create and close figures, but this is done procedurally. I haven't been able to associate this warning with some specific function or feature. I'm working on a Windows Server machine.
Does anyone have an idea of how to narrow down which kind of function os Simulink block could cause this warning?
As datenwolf and Ander point out, the first thing to try is to update your drivers. If this doesn't work, and your only problem is that you're getting the warning but your graphics still render fine, then you have two other options to try.
First, you can simply modify your OpenGL rendering preferences using opengl. The following will set your preference to 'software' and save that setting for future sessions:
opengl('save', 'software');
Alternatively, you can just try to suppress that particular warning message. After you get the warning, issue this call to the warning function:
w = warning('query', 'last');
The w.identifier field will give you the ID for the warning message, which I believe will be 'MATLAB:hg:AutoSoftwareOpenGL' in this case. You can then add the following line to your startup.m file so that this warning is suppressed every time MATLAB is opened:
warning('off', 'MATLAB:hg:AutoSoftwareOpenGL');
Install the original vendor drivers for your GPU. The drivers that are installed by Windows by default lack full OpenGL support. Download the driver package directly from the website of Intel, AMD or NVidia, depending on what GPU you have.
If you don't have GPU, for example when running in a Virtual Machine, then you can not avoid that warning, because then Matlab has no other choice than falling back on the software OpenGL implementation that it ships with.
There's nothing you can do about that, other than making sure, that the system you're running Matlab on, does have proper OpenGL support!
It took me a long time to get it, so I'll put you here in case it helps how I managed to activate openGL in Linux:
If you haven't already (it's common for other problems), rename libstdc++ library from MATLAB:
mv _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6 _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6.bak
Create this link: sudo ln -s /usr/lib/x86_64-linux-gnu/dri/ /usr/lib/
Run export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER;matlab -desktop -nosoftwareopeng
Your DRI Driver will be a file from /usr/lib/dri, removing "_dri" (in my case was the "radeons" driver for an AMD Vega graphic card.
Run MATLAB from a terminal using: export MESA_LOADER_DRIVER_OVERRIDE=_YOUR_DRIVER_HERE_;matlab -desktop -nosoftwareopengl. YOUR_DRIVER_HERE should be your driver, radeonsi in my case.
Check openGL with info = rendererinfo
If something went wrong, you will be able to see in the terminal which library was responsible. Executing 4) and 5) I was discovering what I had to correct, you can do the same if you have another problem that has not appeared to me.
So that it always runs correctly I put export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER at the beginning of the script that runs matlab (_YOUR_MATLAB_FOLDER/bin/matlab), although I suppose it can also be set as an environment variable.
I hope this has been useful to you.
Short version: see topic
Detailed version:
I want to use a specific 3rd party theme for Windows. I'm already using an open source solution which I've compiled myself to disable Window's restriction on Themes.
In the past, when using 3rd party theme related mods that come with DLLs (for example authui.dll for the login ui, or imageres.dll for modding system icons), I avoid using unknown DLLs by simply copying the unknown DLL's theme related resources (such as Bitmaps, Icon groups or UI scripts) unto it's virgin MS Dll counterpart. I call this resource grafting, where resource are changed but the executable elements of DLLs or exes are left alone.
Going back to the theme I want to install, I used sha256 hashing to determine that only aero.msstyles which is also modifiable by resource hacker. So I did the same thing I usually do and transferred resources from the third party theme to Window's own aero.msstyles. Problem is that I ran into a type of resource that I am unable to read or know the contents of. It's called VARIANT. From some experiments done in a VM, it seems to be some kind of binary UI script that resource hacker is unable to decompile. I usually like to be able to read any UI scripts that I transfer but I am unable to do so with this one.
Would this constitute any real security risks? Can UI scripts be side-loaded with some kind of exploit? Seems unlikely to me since the function of a theme file (msstyle) is to coordinate the appearance of the system UI but I don't know enough about the inner working of the whole theming system to be sure. I thought I'd get some other point of views before I take the theme out of the Virtual Machine.
I used vBinDiff to compare the hex code the altered VARIANT/NORMAL binary to that of the original theme. You can also copy the binhexes and save them to two text files which you would compare with WinMerge.
vBinDiff and WinMerge will highlight what modifications and what additions/substractions were made to the binaries, displaying them side by side. I read through the differences, 90% of them were no larger than 4 octals (4bytes), typically what you would expect to see when modding colors using a hex editor. The biggest divergence was an added 32bytes of code.
There are two possible explanations for the such an addition: (1) the author added extra image resources and added the entries necessary to reference them, (2) there is some kind of unwanted code that has been slipped in.
To address the possibility of 2, I did a search to see how small trojan code can get. How likely is it that a trojan has been stuffed into 32bytes if compiled UI scripts? I found a few mentions of an old 17byte virus from the DOS era called trivial which I disegarded right away because it would become apparent very quickly given it's known behavior. As far as full fledged trojans with backdoor and downloading abilities, the smallest I found was 20kb (trojan tinba), discovered in 2012. There is also Catchy32 which is still considered a Trojan but with simpler and very specific functionalities and that one's about 580 bytes (reference). Based on this info, I established that it is highly unlikely (if not impossible) to slip any code in 32bytes of code and established that the resource in question is clean.
Mind you, this doesn't answer the question I asked (can binary UI script resources in a theme carry mal-code) but it does solve my dilemma. Thought I'd share it.
I am working through the tutorial files included with the ACT-R Standalone Windows distribution. This isn't part of any academics assignment; I'm working on this to learn cognitive modeling and writing production systems. I am using Lispbox, an EMACS-SLIME-LISP bundle to write my cognitive models. The distro and lispbox reside on my flash drive. Finally, the distro uses Clozure Common Lisp.
The problem is that whenever I try to reload a model after making changes, ACT-R gives me this error:
Error Reloading:
#|warning: no load file recorded |#
#|warning: cannot use reload |#
It only does this for my unit 2 assignment model. Not any other model, including the one I have written in unit 1.
Now this is a big issue for me - instead of simply pressing "reload" on ACT-R's GUI, I'm forced to close ACT-R entirely and open it again every time I want to reload the model.
I'm thinking this is a problem with EMACS. I have tried reinstalling ACT-R, and deleting any .lisp~ files or anything else that Emacs has saved in addition to the file I wrote. I still get this error.
Could you please help me understand what's going on and how I can fix this if it ever arises again in the future? I would like to get back to working on my assignment as soon as possible.
I have emailed the creator of ACT-R; He told me that I must include the statement
(clear all)
at the beginning of every file, so the software uses the most up-to-date file when reloading.
As a background, today, my GWT hosted mode runs just mysteriously slowed down to the extent that it is virtually not working. Whenever I pause the application the relevant threads (the main thread, the code server, etc.) are waiting on some file I/O native method. After scratching my head for a while I tried to clean up my hard disk a bit. Then I just discovered in my user's Temp folder a 4 gigabyte file named gwt7155307955598297091byte-cache. I wonder what this file may be good for, and what will happen if I delete it completely. Will I have a performance issue the next time I start the dev mode waiting for the "byte-cache" to be recreated?
Looking at the gwt source code, it says it's "A global shared Disk cache", used by a linker (com.google.gwt.core.ext.linker package) and compiler (com.google.gwt.dev.javac package).
Does Apple's Xcode development environment provide any tools for memory leak detection?
I am especially interested in tools that apply to the iPhone SDK. Currently my favourite platform for hobby programming projects
Documentations/tutorials for said tools would be very helpful.
There is one specifically called Leaks and like a previous poster said, the easiest way to run it is straight from Xcode:
run -> Start with Performance Tool -> Leaks
It seems very good at detecting memory leaks, and was easy for a Non-C Head like me to figure out.
Select Profile from the Product menu in Xcode 6 to launch Apple's Instruments tool. (The application is located inside the Xcode application's package contents: /Applications/Xcode.app/Contents/Applications/)
A commercial alternative is OmniObjectMeter. (Discontinued by The Omni Group)
The Clang Static Analyser is great for finding bugs in C, C++ and Objective-C code:
Here is the link for using instrument from xcode to detect memory leak/performance of you ios/mac application
Steps to run instrument from Xcode
You can run the tools within Xcode over menu -> run -> start with performance tool -> ...
Does Apple's Xcode development environment provide any tools for memory leak detection?
I am especially interested in tools that apply to the iPhone SDK.
Yes. Apple calls them "Instruments" (there's more than just memory tools).
See Apple's Introduction to Instruments User Guide. In particular, see Locating Memory Issues in Your App. It provides examples of how to use the memory-oriented trace templates.
ObjectAlloc and MallocDebug should both be of help to you. If you installed the entire SDK, they will be found in Developer->Applications->Performance Tools.
Their names give you a pretty good clue as to their functions, OA, tracks the objects create and MA is a general memory leak tool.
I haven't tried them with iPhone development yet, but I have to believe that they would work there as well.
Assuming you have registered for ADC iPhone developer site, here the link to follow:Instruments User Guide
When using rustyshelf's solution make sure you test on the iPhone and not on the simulator. Memory usage is dramatically different.
Made a sum up of the main memory leak tools: iphone-essential-performance-tools-list
Step 1. Pick the Allocations instrument
Choose the profiling template for Allocations:
On the main Instruments interface, click VM Tracker, if present, and press the Delete key since you won't be needing that particular instrument:
By clicking the plus button in the top right, you can add more instruments for different kinds of testing, but I won't be covering them in this tutorial.
Step 2. Set up your Instruments settings
Before running any analysis, there are a few things you need to do. First, you need to plug in an iOS device that has your app installed on it. It must be a physical device because the iOS Simulator is still a simulator and may not accurately represent memory use in your app or how an app might perform under memory pressure.
To pick your target, click My Computer near the top, hover over your device, and then pick your app from the sub-menu:
Next, there is a panel where you can alter the settings for the types of allocations you will be viewing. Besides making sure the Created & Persistent bubble is checked, there is not much you need to do beforehand.
Step 3. Press record to run the instrument
Once you press the Record button in the top left, your app will start up on your device, and Instruments will begin to chart your allocations. All you need to do here is run through your app, focusing on possible problem areas to see if more memory allocates than deallocates. This could mean doing a lot of repetitive tasks, but you'll thank yourself later.
You should see something like this:
I recommend running through your app once and getting to a stable point in memory so you have a good baseline that will make any increase noticeable. When you are satisfied you have enough data to test, press the stop button in the top left.
Step 4. Analyze
The first thing I do is set my inspection range to measure the total persistent bytes at my baseline. That persistent byte number is located right under the allocation summary.
To actually set the inspection range, use the keyboard shortcut Command < for the left inspection range and Command > for the right inspection range. In our app, we have a baseline of about 20MB.
Then, I move my right inspection range to a point where I had run through the app again and came back to our root. Here, you can see memory is about the same. So, by doing this a few more times and seeing your memory come back to our baseline, you can assume there are no major memory issues.
There are different ways to analyze this data that I won't cover here, but be aware that there's a whole drop-down menu of ways to view and analyze your data.
Step 5. Marking generations
If you prefer not to deal with the inspection ranges as much, there is a feature called Mark Generation. There is a button for it on the right panel of instruments.
This button will mark points on the timeline of instruments based on where the inspection line is. It does this in order to keep track of all the allocations since the previous mark, or from the beginning if there are no other marks. You can mark generations as you are running the allocations instrument or after you have stopped the run, as in this example:
Step 6. Check out the stack trace
The last thing to cover is looking at the stack trace. For this, you want to set your inspection range to highlight all the allocations, and then look at the statistics view, making sure the Created & Persistent bubble is selected on the right panel. In the statistics view, make sure Persistent Bytes is sorted from highest to lowest. There are a lot of allocations here, and it can be hard to understand what is going on, since a lot of them are system allocations.
Going deep
Look at the largest allocations and click on the right-facing arrow. A lot of times there will be allocations inside the ones you clicked on and many of them won't have meaning to you.
As you highlight different allocations after clicking an arrow, continue looking at the extended detail on the right panel. Eventually you will come across some bold text that leads to actual code in your project, telling you what the issue might be.
If you double-click one of the bold items in the stack trace, it will take you to the actual code (assuming you ran allocations on an app you own).
There are a lot of useful things about this view, one being the mostly yellow tags on the right showing you just how much memory each method call is taking up. Every app is different so you, the developer, have to decide if the highlighted method is a problem, something you can optimize, or just an unavoidable part of your app.
In my case, that UIColor variable is something that is persistent and used throughout our app and is therefore, acceptable throughout the life of our app.
found here
Try this one also, a simple tutorial to start with Xcode insturments
Memory leak tool: http://www.raywenderlich.com/2696/
Basic: http://www.raywenderlich.com/23037/how-to-use-instruments-in-xcode