Hi all,
i've to make an introduction of what i am doing before start making questions.
The goal of my work is to create an application quite like an IDE, for specific program development ( always in C++ ) and testing.
Since the need of execute these programs under the main IDE process for monitoring and logging purposes, my solution is to compile them as shared library and load them dynamically from the IDE. (Any suggestion about other strategies is welcome!)
The application is to be considered a 24h server, so can't be subject to problems like memory leaks or segmentation faults, neither be respawned by an external process.
As far as i know, segfaults may be handled intercepting the SIGSEGV signal, but this produces an undefined behavior.
So let's go with fun:
Question one: if the segfault is caused by a function in the shared library, loaded and executed in a separate thread, is possible to preserve the integrity of the running main process and handle the event without surprises?
Question two: since the thread share it's memory, how can i prevent memory leaks caused by the libraries after their unload?
The leaking depends on an operative system. Generally there is no leaks after the total unload. To prevent a leakage from the memory a cork is needed before pouring into it.
Insert a leakage counter immediately onto a request line of the source text then reduce
it by the number of reqeusts each time checking the number for the leakage lever above the ground.
I think you have not correctly understood what i am doing... otherwise it's my fault in understanding you reply.
I'll try be much clearer:
I have a process "A" wich have to load possible unstable code from a library to execute it in a safe way and then unload it.
Obviously, every possible mem leak is solved with the close of the whole process, since it's memory space is released at all by the OS.
So my question is: is possible to isolate threads for preventing mem leaks and segfaults propagating to the whole process?
if the segfault is caused by a function in the shared library, loaded and executed in a separate thread, is possible to preserve the integrity of the running main process and handle the event without surprises?
Not really. But you might get away with it if the shared library has it's own copy of the C/C++ runtime library (and heap). The memory won't be returned to the OS though.
since the thread share it's memory, how can i prevent memory leaks caused by the libraries after their unload?
No, it is not unless to look through all the code compiled in those libraries.
The OS does not care of such leaks. It tries to serve out all its resources
to anyone no matter what thread, process or else.
If your aggregate is using remote DLL via shared drives storage which is a server in a way then for sure the leakage streams pop up due to their malfunctioning communication lines.
That is a client being cut off its resourses request is not the client anymore. It
simply forgets its request having left occupied the server and itself.
In this case you may try for the leakage each library one by one.
If it happens on a similare to http one then it is quite another story.
Asynchronious.