ALL,
I have an application which loads multiple DLLs. One of those DLLs has a memory leak.
From what I understand the best tool to find memory leaks is VLD ;-)
So I downloaded the latest release and installed it in the default location.
Now the documentation says that I need to include the vld.h file somewhere once and link to the VLD libraries and then just run the application.
My question is - should I include it in the DLL code where the leak occurs or I do that in the main application? And the same with the linking...
Thank you.
Include vld.h to each source file (if you use precompiled headers, you can include vld.h once to the header) of each DLL, or some specific DLL. Then rebuild them / it.
vld.h redefines allocation functions, so when a source file is compiled, all allocation functions become special functions from VLD. Thus VLD can save information about allocations and deallocations.
You can use VLD in your main application. But in this case, you will get information about allocations made by your main application code only.
Related
Just leave alone the Apple policy, just talking about the Objective-C language only,
Assume that my programme calling a .a library. Is this possible to grep the .a from the
internet, and run a newer version of .a instead of old .a?
Thanks.
Not for statically linked libraries (.a), at least with any level of sanity. You can certainly do it with dynamically loaded libraries (.so); it's one of the normal use cases. Have a look at dlopen, dlclose and dlsym from the dynamic loader (https://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html).
This is not just iOS, but OS X apps (and probably other Unixes in general)
Static libraries (.a files) cannot be replaced while the program is running because they are part of the application binary. The application binary is mapped into the process's address space. If you try to change any part of it, you'll almost certainly end up crashing the app.
Dynamic libraries (.so files) are replaceable in theory. However, most applications load them up once at the beginning or when first needed and then they become part of the application's address space. I've heard that it is theoretically possible for an application to unload a dynamic library, but I've never seen it done in any real Cooca application.
I can't find answer on that question. I have a project with old school MRC, and prefer to use this memory management style, but now some new frameworks creates initially with ARC. Can I include these frameworks in my project with any converting ways or what can I do in this situation except remake the whole project?
You can use an ARC(MRC) (dynamic or static) library with a MRC(ARC) application. If you want to include the source of an ARC(MRC) framework into an MRC(ARC) you need to mess around with per file settings and IIRC reports suggest that though it works fine you may gets non-errors reported by Clang.
[Note: GC complicates the picture, e.g. you can't use a GC library from an MRC/ARC application.]
You could compile your ARC sources as static libraries... That's one way to do it, another would be enabling ARC per file basis
What is the meaning of building a dll as export library ? I just googled it.I found its a dynamic link library.Can anyone please explain what actually dll is ? and why do we need to add these statement in the .dll file
extern "c" _declspec(dllexport)
I studied the static and shared libraries but Im not sure why do we go for dll files.I learnt .dll is used for the run time. But can you help me and give me more information.Thank you in advance
I may have been a bit harsh in my comments. I am not an authority on dlls, but I have a bit of working knowledge of them, so I will try to give a short explanation.
The difference between static and shared libraries should be easy to find in a web search, but basically the code in a static library gets included into the final executable, so after the linking stage, the actual library file is not needed anymore to run the program; on the other hand, code in a shared library doesn't get included in the main program - the two parts remain separate, so the shared library (called dll on windows) will be needed every time the program is run.
"Building a dll as export library" is a bit of a confusing term. I had not heard of it before, and during a short search could only find it on a cygwin page, which you might have read, considering your initial tags. A dll can export some or all of its functions and data. Exporting means that they are available for other programs and dlls to use. Which names get exported can be controlled in various ways. One of those is inserting _declspec(dllexport) in the declaration of the function. Another way is by using a definition file with an exports section.
When creating a dll, an import library can be created. This is a file that can then be used when building an executable that uses the dll, during the linking stage, to let it know which names are exported from the dll, so the program knows how to resolve references to those functions; in other words: how to import them. (This is not always necessary. Many linkers allow you to directly link against the dll itself, thereby removing the need for an import library.)
I realize it can be confusing, but try to find a tutorial and some small examples to see how it works, and play with it a bit.
i have a doubt in dlls loading &processing in memory ,normally dlls are shared library so dll should loads once is enough.if a process loads a dll (ex.advapi32.dll )into memory means ,after that another process how refers advapi32.dll to that process ...how can share common location for each process...
I'm not entirely sure what your question is, but yes, if multiple processes import the same DLL, then the read-only sections of that DLL are typically mapped into all of those processes. On the other hand, section that can change, like the BSS (variable) segment, get a copy in each process so that the changes that one process makes are invisible to other processes. If you want certain changes to be shared between processes for your own DLL, you can mark a data section in the DLL as shared. Exactly how you do this depends on the development tools you're using.
I know very little about DLL's and LIB's other than that they contain vital code required for a program to run properly - libraries. But why do compilers generate them at all? Wouldn't it be easier to just include all the code in a single executable? And what's the difference between DLL's and LIB's?
There are static libraries (LIB) and dynamic libraries (DLL) - but note that .LIB files can be either static libraries (containing object files) or import libraries (containing symbols to allow the linker to link to a DLL).
Libraries are used because you may have code that you want to use in many programs. For example if you write a function that counts the number of characters in a string, that function will be useful in lots of programs. Once you get that function working correctly you don't want to have to recompile the code every time you use it, so you put the executable code for that function in a library, and the linker can extract and insert the compiled code into your program. Static libraries are sometimes called 'archives' for this reason.
Dynamic libraries take this one step further. It seems wasteful to have multiple copies of the library functions taking up space in each of the programs. Why can't they all share one copy of the function? This is what dynamic libraries are for. Rather than building the library code into your program when it is compiled, it can be run by mapping it into your program as it is loaded into memory. Multiple programs running at the same time that use the same functions can all share one copy, saving memory. In fact, you can load dynamic libraries only as needed, depending on the path through your code. No point in having the printer routines taking up memory if you aren't doing any printing. On the other hand, this means you have to have a copy of the dynamic library installed on every machine your program runs on. This creates its own set of problems.
As an example, almost every program written in 'C' will need functions from a library called the 'C runtime library, though few programs will need all of the functions. The C runtime comes in both static and dynamic versions, so you can determine which version your program uses depending on particular needs.
Another aspect is security (obfuscation). Once a piece of code is extracted from the main application and put in a "separated" Dynamic-Link Library, it is easier to attack, analyse (reverse-engineer) the code, since it has been isolated. When the same piece of code is kept in a LIB Library, it is part of the compiled (linked) target application, and this thus harder to isolate (differentiate) that piece of code from the rest of the target binaries.
One important reason for creating a DLL/LIB rather than just compiling the code into an executable is reuse and relocation. The average Java or .NET application (for example) will most likely use several 3rd party (or framework) libraries. It is much easier and faster to just compile against a pre-built library, rather than having to compile all of the 3rd party code into your application. Compiling your code into libraries also encourages good design practices, e.g. designing your classes to be used in different types of applications.
A DLL is a library of functions that are shared among other executable programs. Just look in your windows/system32 directory and you will find dozens of them. When your program creates a DLL it also normally creates a lib file so that the application *.exe program can resolve symbols that are declared in the DLL.
A .lib is a library of functions that are statically linked to a program -- they are NOT shared by other programs. Each program that links with a *.lib file has all the code in that file. If you have two programs A.exe and B.exe that link with C.lib then each A and B will both contain the code in C.lib.
How you create DLLs and libs depend on the compiler you use. Each compiler does it differently.
One other difference lies in the performance.
As the DLL is loaded at runtime by the .exe(s), the .exe(s) and the DLL work with shared memory concept and hence the performance is low relatively to static linking.
On the other hand, a .lib is code that is linked statically at compile time into every process that requests. Hence the .exe(s) will have single memory, thus increasing the performance of the process.