I am developing a shared memory suite of applications, in C, on Ubuntu 12.04 server.
This is my first attempt at dealing with shared memory, so I am not sure of all the pitfalls.
My suite starts with a daemon that creates a shared memory segment, and a few other apps that use it.
During development, of course, the segment can get created, then the program crash without removing it. I can see it listed using ipcs -m.
Normally, this isn't much of an issue, as the next time I start the "controlling" program, it simply reuses the existing segment.
However, from time to time, the size of the segment changes, so the program fails the shmget() function.
My question...
Before I create and attach the segment, I would like to first determine if it already exists, then if needed, unattach it, then I think, shmctl(..., ipc_rmd, ...).
Can I have some help to figure the proper sequence of events to do this?
I think I should use shmctl to see what's up, (number of attachments, if it exists, etc..) but I don't really know.
It may be there is another app still using the segment, of course that app will have to first be stopped, and any other possible exceptions handled.
I was thinking, in the shared memory segment, I could copy the system clock, and when the app detects the clock of the shared mem differs more then a few seconds, then detach or something.
Thanks, Mark.
Related
I understand that dlopen/dlclose/dlsym/dlerror APIs are used to interface to a
dynamic loading library but how does this work for a binary already compiled with
the -L flag referring the .so library (shared library, background/load time linking). Edit: I am referring to live updating of shared library without restarting the app.
Cong Ma provided some great pointers. Here is what I could conclude after some more research :
If an app is linked to an .so, and the shared library is replaced with a new copy of it, without stopping the app, the outcome would be 'non-deterministic' or 'unpredictable'.
During the 'linking/loading' phase of the app, the library gets mapped to the address space of the app/process.
Unix-like OS maintains COW, so for the reference, if copy is made on write, the app would have no impact though objective of being able to use new .so code would not be achieved
It all about the memory region that the app is accessing - if the access region does not have a change in address, the app won't experience any impact.
The new version of the lib may have an incremental nature, which might not impact the app - there can be compilation magic for the relocatable address generation too.
You may be lucky sometimes to fall in those above categories and have no issues while replacing the .so with a running app referring to it but practically you will encounter SIGSEGV/SIGBUS etc. most of the time, as the address/cross-reference gets jumbled up with a considerable change in the library.
dlopen() solves the problem as we reduce the window of access of the library. If you do dlopen() and keep it open for long enough you are exposing your app to the same problem. So the idea is to reduce the window of access to fail-proof the update scenario.
I'd say it's possible to reload a dynamic library while an application is running. But to do this you'd have to design such "live reloads" into the library from the start.
Conceptually it's not that difficult.
First, you have to provide a mechanism to signal the application to reload the library. This is actually the easy part - at least in the Unix world: rename or unlink the original library and put the new one in its place, then have the application call dlclose() on the old library, and dlopen() on the new. Windows is probably more difficult. On Unix or Unix-type systems, you can even do the unlink/rename while the application is still running. In fact, on Unix-type systems you do not want to overwrite the existing library at all as that will cause you serious problems. The existing on-disk library is the backing store for the pages mapped from that library into the process's address space - physically overwriting the shared library's file contents will again result in undefined behavior - the OS loads a page it expects to find the entry point of the function foo() in but that address is now halfway through the bar() function. The unlink or rename is safe because the file contents won't be deleted from disk while they're still mapped by the process.
Second, a library can't be unloaded while it's in use (it's probably possible to unload a library while it's being used on some OSes, but I can't see how that could result in anything other than undefined behavior, so "can't" is de facto correct if not de jure...).
So you have to control access to the library when it's being reloaded. This isn't really all that difficult - have a shim library that presents your API to any application, and use a read/write lock in that library. Each call into the library has to be done with a read lock held on the read/write lock, and the library can only be reloaded when a write lock is held on the read/write lock.
Those are the easy parts.
The hard part is designing and coding your library so that nothing is lost or corrupted whenever it's reloaded. How you do that depends on your code. But if you make any mistake, more undefined behavior awaits.
Since you have to halt access to the library to reload it anyway, and you can't carry state over through the reload process, it's going to be a LOT easier to just bounce the application.
Don't assume. Read about it... Inside stories on shared libraries and dynamic loading. tldr: Shared library is loaded (mostly) before the app is executed, rather than "in the background".
Do you mean "live updating of shared library without restarting the app"? I don't think this is possible without hacking your own loader. See answers to this question.
So here my problem. I have a Linux program running on a VM which uses OpenCL via dlopen to execute some commands. About half way through the program's execution it will sleep, and upon resume can make no assumptions about any state on the GPU (in fact, the drivers may have been reloaded and the physical GPU may have changed). Before sleeping dlclose is called and this does unload the OpenCL memory regions (which is a good thing), but the libraries OpenCL uses (cuda and nvidia libraries in this case) are NOT unloaded. Thus when the program resumes and tries to reinitalize everything again, things fail.
So what I'm looking for is a method to effectively unlink/unload the shared libraries that OpenCL was using so it can properly "restart" itself. As a note, the process itself can be paused (stopped) during this transition for as long as needed, but it may not be killed.
Also, assume I'm working with root access and have more or less no restrictions on what files I can modify/touch.
For a less short-term practical solution, you could probably try forcing re-initialization sequence on a loaded library, and/or force unloading.
libdl is just an ordinary library you can copy, modify, and link against instead of using the system one. One option is disabling RTLD_NODELETE handling. Another is running DT_FINI/DT_INIT sequence for a given library.
dl_iterate_phdr, if available, can probably be used to do the same without the need to modify libdl.
Poking around in libdl and/or using LD_DEBUG (if supported) may shed some light on why it is not being unloaded in the first place.
If they don't unload, this is either because something is keeping a reference to them, or they have the nodelete flag set, or because the implementation of dlclose does not support unloading them for some other reason. Note that there is no requirement that dlclose ever unload anything:
An application writer may use dlclose() to make a statement of intent on the part of the process, but this statement does not create any requirement upon the implementation. When the symbol table handle is closed, the implementation may unload the executable object files that were loaded by dlopen() when the symbol table handle was opened and those that were loaded by dlsym() when using the symbol table handle identified by handle.
Source: http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlclose.html
The problem you're experiencing is a symptom of why it's an utterly bad idea to have graphics drivers loaded in the userspace process, but fixing this is both a technical and political challenge (lots of people are opposed to fixing it).
The only short-term practical solution is probably either factoring out the code that uses these libraries as a separate process that you can kill and restart, and talking to it via some IPC mechanism, or simply having your whole program serialize its state and re-exec itself on resume.
I am working on VxWorks target board. I want to make sure that my application or driver does not have any memory leak.
Is there any specific way so that I can check memory leak at run time
or without running the application?
You need MemScope provided by Wind River which is compatible with vxworks also refer http://borkhuis.home.xs4all.nl/vxworks/vxw_pt6.html#6.2
Although it is inaccurate you can use the memShow command on the VxWorks shell.
To check for memory leaks do a "base line" after your application has started. Then run your tests or stimulate your application or simply let it run for a few hours. After that check the outputs of memShow again. If the values have changed "dramatically" you have a problem.
Notes:
This is very basic and just helps you to know that you actually have a memory leak. It does not show you which thread, or function...
Remeber that this function shows the total available memory (not only to your application). So some changes are normal due to VxWorks operating...
I have started to look at c programming and whilst I am not a complete beginner (I have knowledge of java and web development) there are a lot of things I do not understand.
My question is about when a program is first loaded into memory. I am having trouble understanding what actually happens here.
Is all of the program code loaded into memory when the program is launched or is only what is needed loaded in?
After this does this code\set of instructions get swapped in and out of the physical disk as the process gets CPU time or does loaded code stay in memory whilst the program is running?
If two processes can share the same set of instructions does this mean each process gets a separate code section in its virtual memory space?
I am sorry if my questions are basic or poorly worded but I only started looking at this last week and after a weekend of reading I have far more questions than answers!
Is all of the program code loaded into memory when the program is
launched or is only what is needed loaded in?
Most modern OS's will load "on demand", so the starting point of the application (main) will be loaded by the OS, then the OS just kicks off there. When the application jumps to a piece of code that isn't in memory yet, it loads that bit.
After this does this code\set of instructions get swapped in and out
of the physical disk as the process gets CPU time or does loaded code
stay in memory whilst the program is running?
If the OS decides that some memory is needed it may well throw out some of the code, and reload it when it needs it later [if it's ever needed again - if it was some part of the initialization, it may never get hit again].
If two processes can share the same set of instructions does this mean
each process gets a separate code section in its virtual memory space?
It is certainly possible to share the code between multiple copies of the same application. Again, whether a particular OS does this or not depends on the OS. Linux certainly shares code copies from the same application between two (unrelated) processes [obviously, a forked process shares code by definition]. I believe Windows also does.
Shared libraries (".so" and ".dll" files for Linux/Unix and Windows respectively) are also used to share code between processes - the same shared library is used for many different applications.
The Data space is of course separate for each application and shared libraries will also get their own data section per process sharing the library.
We have an embedded application, now it requires its state to be saved and reloaded. Just like in PC games, where you save it before you have to go out and breath some fresh air.The product is quiet evolutionary in nature, no proper design so identifying data to be saved is not an option.
The software is in C so all data has fixed addresses (.data segment), its also deterministic,a and no dynamic memory allocations. So theoretically I take a back up of this data segment in a file and on relaunch of application update it back from the file. This approach will probably save a lot more data than what is required, but I am ok with it.
How can I do this in short execution time ?
Also how can I identify the start and end of .data segment in run-time ?
You want application checkpointing, so perhaps the Berkley Lab Checkpoint Restart library might help you.
You could perhaps use the mmap(2) system call, if you are sure all the data has fixed addresses, etc...
To know about your current memory segments and mappings, read (from your application) the /proc/self/maps file. There is also /proc/self/smaps etc. Learn more about proc(5), ie /proc/