Printable View
Hi all - I have a dynamically loaded library and I wish some function in it to it to call a function in the parent (DL loading) code. I am tempted to pass the pointer to the required function to the DL and use this, but seeing they are using different address spaces is this safe? My other idea was to use some form of IPC (probably pipes) to do it, but this requires some layer of abstraction plumbed in.
Has anyone got any advice on how to achieve this?
I would pass in a function pointer. Dynamically loaded libraries share the same address space as the code that loaded the library, so this is safe to do.
right, thanks - this was my prefered option but I was worried it would not be safe
If by pass in a function you mean to define your function in your shared lib with a pointer to a function that you will pre-define as something, the yes, you can do that. qsort does it as to a few others.
edit: Bummer, too slow.
Shared objects do NOT use separate address spaces. They all exist in the same address space, have the same heap, etc. This isn't Windows, this is a place where things make sense
Eh? "Shared" objects are loaded into the process space of the process that loads it in Windows. And Windows makes a lot of sense where Linux doesn't (*cough* memory allocation succeeds when there might be no physical memory left *cough*).
Physical memory? Meaning there could be virtual memory left? 'Makes sense to me.Quote:
Originally Posted by Elysia
What he said isn't what he meant. He meant that memory allocation succeeds even when there is insufficient physical or virtual memory.Quote:
Originally Posted by Angus
Does it make sense to allocate some virtual memory to some physical memory when there is none left? That means the malloc call will succeed and the app will crash when trying to use the virtual memory.Quote:
Originally Posted by Angus
It makes more sense to me that malloc should fail.
Well, that's a relief. Now I can forget about properly checking my malloc calls. :pQuote:
Originally Posted by Elysia
I'm not sure what Elysia is talking about in regards to virtual memory crashing the system (that's obviously bogus), but there is a valid point in there somewhere.Quote:
Originally Posted by MK27
A malloc() call on Linux will always succeed if there is address space available. On a 32 bit system, there is about 3.2GB of user space address space available per process, so that is what you can allocate. If you have 512MB of physical memory and 512MB of swap space, your app can still allocate 3.2GB before malloc() returns NULL.
This is known as an optimistic memory allocation strategy, and it has its pros and cons. This behavior can be turned off by running:
In which case malloc() will behave as it does on Windows.Code:echo 2 > /proc/sys/vm/overcommit_memory
What you say is what I mean. If you have 1 GB of available memory (like 512 MB physical + 512 MB swap) and you get another piece of virtual memory, then when you would try to access that, your app would crash.Quote:
Originally Posted by bithub
If you want your app to crash, just ignore the return of malloc. But if you want to be able to recover, then check the return of malloc, so this behavior of "silently" succeeding makes no sense to me.
In fact the app does not "silently crash", the process is explicitly killed by the system.Quote:
Originally Posted by Elysia
Guess what happens?Code:#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
char *x=NULL;
while (1) {
x=malloc(1000000);
if (!x) break;
}
printf("OUT OF MEMORY!\n"); fflush(stdout);
return 0;
}
[root~/C] ./a.out
Killed
It takes a few seconds to eat through the memory first, but if you watch a meter all of it is immediately returned to the system.
One advantage to this approach would be that if the system has run out of memory, it should immediately begin killing processes starting with the one that made the last request; altho returning control to the program might be okay, this sets up the possibility that it will just immediately begin asking for more. After all, you could do whatever you like with after a failed malloc() in your code; the OS has no way of knowing.
Notice in /var/log:
Sep 2 09:18:15 lhost kernel: Out of memory: kill process 1973 (a.out) score 3371233 or a child
Sep 2 09:18:15 lhost kernel: Killed process 1973 (a.out)
So it is not as if this needs to be a mysterious event for the user. Chances are, it was the process killed that created the problem, and this is easy enough to trace even if you are not a programmer. Chances are, the process that ate all the memory has some kind of significant bug or design flaw, so it should be shut down and not allowed to continue. I would put my trust in the kernel before anything else (you can of have to anyway).
Or at least that is the default, as bithub indicated. If you don't like the policy, you have choices.
This thread has gone quite off-topic.
By my count, the original question was answered 3 times, so I don't think it matters much.Quote:
Originally Posted by CornedBee
They have separate heaps. What sort of nonsense is that?Quote:
Originally Posted by Elysia
Quote:
And Windows makes a lot of sense where Linux doesn't (*cough* memory allocation succeeds when there might be no physical memory left *cough*).
Fixed.Code:echo 0 > /proc/sys/vm/overcommit_memory
Elysia is correct. In Windows the DLL is loaded into the executable's process (they share the same address space). The DLL and executable will only have separate heaps if they statically link to the RTL. If they both dynamically link to the RTL, then they will share the same heap.Quote:
They have separate heaps. What sort of nonsense is that?
0 is the default. 2 turns off overcommit (as I posted earlier in this thread already).Quote:
Fixed.
If it moves off-topic, I would generally just recommend splitting the thread. That doesn't hurt the discussion as locking the topic or pointing it out does.Quote:
Originally Posted by bithub