Problems with the shared libraries - Linux

This is a discussion on Problems with the shared libraries - Linux ; Hi, Prasently am writing a shared library which is used by one application.For that application,am not having the code. I know when this library will be called after starting the application(by giving a call from the client to that server ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Problems with the shared libraries

  1. Problems with the shared libraries

    Hi,

    Prasently am writing a shared library which is used by one
    application.For that application,am not having the code. I know when
    this library will be called after starting the application(by giving a
    call from the client to that server my .so will be called).

    Now sometimes the application crashes after execuion of my shared
    library ( it is printing the last statement of my code before
    returning the value from the function). Am unable to understand why it
    is crashing and how it is crashing. How to identify these kind of
    failures ? Is anybody faced the same scenario, if yes please let me
    know.

    Regards
    Sunil


  2. Re: Problems with the shared libraries

    sunil wrote:
    > Prasently am writing a shared library which is used by one
    > application.For that application,am not having the code. I know when
    > this library will be called after starting the application(by giving a
    > call from the client to that server my .so will be called).


    This is typically called a plugin. It would be helpful if you told us which
    program you are trying to extend.

    > Now sometimes the application crashes after execuion of my shared
    > library ( it is printing the last statement of my code before
    > returning the value from the function). Am unable to understand why it
    > is crashing and how it is crashing. How to identify these kind of
    > failures ? Is anybody faced the same scenario, if yes please let me
    > know.


    There are many insecure things in it that the compiler can't check:
    1. Destructors of C++ objects (Note: I'm assuming you are using either C or
    C++, it would help if you told us which language!) are run after your last
    print statement.
    2. Plugin cleanup code. dlclose() invokes a function called _fini() if
    present.
    3. Interface mismatch. This is the hardest to diagnose, because there is no
    runtime checking for it. If for example the program expects a function with
    the signature 'int function( float)' and your plugin exports one with the
    signature 'float function()', i.e. a different signature, many things can
    happen due to the way that C transfers data between functions on the stack.
    4. Programming error. Those are simple things like e.g. not passing out
    pointers to local memory. Other pitfalls are returning 0 for failure while
    it means errorcode E_OK in that context. This list could be endless
    though...

    Uli


  3. Re: Problems with the shared libraries

    On Nov 13, 9:45 am, Ulrich Eckhardt wrote:
    > sunil wrote:
    > > Prasently am writing a shared library which is used by one
    > > application.For that application,am not having the code. I know when
    > > this library will be called after starting the application(by giving a
    > > call from the client to that server my .so will be called).

    >
    > This is typically called a plugin. It would be helpful if you told us which
    > program you are trying to extend.

    Am customizing the functionality of the product named
    webseal(TAM) from IBM

    >
    > > Now sometimes the application crashes after execuion of my shared
    > > library ( it is printing the last statement of my code before
    > > returning the value from the function). Am unable to understand why it
    > > is crashing and how it is crashing. How to identify these kind of
    > > failures ? Is anybody faced the same scenario, if yes please let me
    > > know.

    >
    > There are many insecure things in it that the compiler can't check:
    > 1. Destructors of C++ objects (Note: I'm assuming you are using either C or
    > C++, it would help if you told us which language!) are run after your last
    > print statement.

    What you said is correct,am using the C language for my coding.Am
    not using C++ thats why there are no issues with the destructors. My
    guess it might be related the heap memory issues.
    > 2. Plugin cleanup code. dlclose() invokes a function called _fini() if
    > present.

    I didn't get this dclose function.If possible could u
    elaborate on this.

    > 3. Interface mismatch. This is the hardest to diagnose, because there is no
    > runtime checking for it. If for example the program expects a function with
    > the signature 'int function( float)' and your plugin exports one with the
    > signature 'float function()', i.e. a different signature, many things can
    > happen due to the way that C transfers data between functions on the stack.
    > 4. Programming error. Those are simple things like e.g. not passing out
    > pointers to local memory. Other pitfalls are returning 0 for failure while
    > it means errorcode E_OK in that context. This list could be endless
    > though...
    >
    > Uli


    Thanks Uli for u'r kind reply.If u having any ideas on this please let
    me know.

    Regards
    Sunil.



  4. Re: Problems with the shared libraries

    sunil wrote:
    > On Nov 13, 9:45 am, Ulrich Eckhardt wrote:
    >> 2. Plugin cleanup code. dlclose() invokes a function called _fini() if
    >> present.

    > I didn't get this dclose function.If possible could u
    > elaborate on this.


    man dlopen

    Uli


+ Reply to Thread