Thread: Calling C function from dynamically loaded library

  1. #1
    Registered User
    Join Date
    Sep 2009
    Posts
    2

    Calling C function from dynamically loaded library

    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?

  2. #2
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    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.
    bit∙hub [bit-huhb] n. A source and destination for information.

  3. #3
    Registered User
    Join Date
    Sep 2009
    Posts
    2
    right, thanks - this was my prefered option but I was worried it would not be safe

  4. #4
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    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.

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    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
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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*).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Kung Fu Kitty Angus's Avatar
    Join Date
    Oct 2008
    Location
    Montreal, Canada
    Posts
    115
    Quote Originally Posted by Elysia View Post
    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.

  8. #8
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Quote Originally Posted by Angus View Post
    Physical memory? Meaning there could be virtual memory left? 'Makes sense to me.
    What he said isn't what he meant. He meant that memory allocation succeeds even when there is insufficient physical or virtual memory.
    bit∙hub [bit-huhb] n. A source and destination for information.

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Angus View Post
    Physical memory? Meaning there could be virtual memory left? 'Makes sense to me.
    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.
    It makes more sense to me that malloc should fail.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Elysia View Post
    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.
    Well, that's a relief. Now I can forget about properly checking my malloc calls.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  11. #11
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Quote Originally Posted by MK27 View Post
    Well, that's a relief. Now I can forget about properly checking my malloc calls.
    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.

    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:
    Code:
    echo 2 > /proc/sys/vm/overcommit_memory
    In which case malloc() will behave as it does on Windows.
    bit∙hub [bit-huhb] n. A source and destination for information.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by bithub View Post
    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.

    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.
    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.
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Elysia View Post
    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.

    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;
    }
    Guess what happens?

    [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.
    Last edited by MK27; 09-02-2009 at 08:20 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    This thread has gone quite off-topic.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #15
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Quote Originally Posted by CornedBee View Post
    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.
    bit∙hub [bit-huhb] n. A source and destination for information.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting an error with OpenGL: collect2: ld returned 1 exit status
    By Lorgon Jortle in forum C++ Programming
    Replies: 6
    Last Post: 05-08-2009, 08:18 PM
  2. dllimport function not allowed
    By steve1_rm in forum C++ Programming
    Replies: 5
    Last Post: 03-11-2008, 03:33 AM
  3. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 05:45 PM
  4. A Function Calling a Function
    By dac in forum C++ Programming
    Replies: 8
    Last Post: 12-17-2006, 04:10 PM
  5. Please Help - Problem with Compilers
    By toonlover in forum C++ Programming
    Replies: 5
    Last Post: 07-23-2005, 10:03 AM