Is it possible to determine exit code in library destructor? - Linux

This is a discussion on Is it possible to determine exit code in library destructor? - Linux ; Arch Stanton wrote: > William Pursell wrote: >> On 1 Oct, 16:02, Arch Stanton wrote: >>> I have an interesting problem. I'm writing a shared library which is >>> inserted into an alien process via LD_PRELOAD. I have almost everything ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: Is it possible to determine exit code in library destructor?

  1. Re: Is it possible to determine exit code in library destructor?

    Arch Stanton wrote:
    > William Pursell wrote:
    >> On 1 Oct, 16:02, Arch Stanton wrote:
    >>> I have an interesting problem. I'm writing a shared library which is
    >>> inserted into an alien process via LD_PRELOAD. I have almost everything
    >>> working beautifully but the library needs to get access to the exit code
    >>> before quitting. Its destructor function is definitely called after
    >>> exit() so the value must be around someplace but I do not know a way to
    >>> get it. Any ideas?
    >>>

    >>
    >> I haven't had a chance to try it yet, but what about calling main()
    >> directly from your constructor, storing the return
    >> value, and then calling exit()? (I suspect there are
    >> some issues with doing that, but it might be an
    >> interesting thing to experiment with.) Is there a better
    >> way to avoid main being called after the constructor?
    >> Will calling exit() accomplish that cleanly?

    >
    > You know, that's an very cute idea and it might be made to work, though
    > I think you'll agree Nate Eldredge's idea is less intrusive. But this is
    > another one I never thought of. Thanks.


    As I think further there are two, potentially solvable, problems with
    this one:

    1. The library constructor has no direct access to argv/argc. These can
    often be found via the traditional hack of going to the environ pointer
    and working back but it might not be too robust to depend on that.

    2. The runtime linker ensures that main() is not called until all shared
    libraries are loaded and initialized. If I call it myself I have to find
    some way to make sure all that setup work is done, i.e. to be sure my
    library is loaded last. And there may be other initializations between
    library loading and main(), I haven't looked.

    Arch

  2. Re: Is it possible to determine exit code in library destructor?

    On Oct 1, 2:40*pm, Nate Eldredge wrote:

    > It seems like any approach is likely to be a hack. *One idea might be
    > to have your destructor function fork(). *The child returns, and the
    > parent wait()s in order to see what the exit code is.


    This is a particularly dangerous hack, changing the program semantics
    so that it terminates twice instead of once. What happens if the next
    destructor is not idempotent?

    DS

  3. Re: Is it possible to determine exit code in library destructor?

    On Oct 1, 2:40*pm, Nate Eldredge wrote:

    > It seems like any approach is likely to be a hack. *One idea might be
    > to have your destructor function fork(). *The child returns, and the
    > parent wait()s in order to see what the exit code is.


    This is a particularly dangerous hack, changing the program semantics
    so that it terminates twice instead of once. What happens if the next
    destructor is not idempotent?

    DS

  4. Re: Is it possible to determine exit code in library destructor?

    On Oct 1, 3:58*pm, Arch Stanton wrote:

    > Wow! You might call that a hack. I'd call it the most twisted^Wbrilliant
    > idea I've seen in a month. I just tried it and it works perfectly. Best
    > of all, no kernel hackery, no assembly code to look in some hardwired
    > register, no elevated privileges, just standard, elegant, portable Unix
    > semantics. Thanks!


    Suppose the next destructor does the following:
    1) Delete foo.out
    2) Rename foo.out.tmp to foo.out

    Since you make the program end twice instead of once, step '2' above
    will fail the second time, and the program's output will be lost.

    This is an artificial example, of course, but the point is that you
    can't assume that all subsequent destructors will be idempotent.
    (Suppose the next destructor appends something to a file or makes a
    log entry.)

    DS

  5. Re: Is it possible to determine exit code in library destructor?

    On Oct 1, 3:58*pm, Arch Stanton wrote:

    > Wow! You might call that a hack. I'd call it the most twisted^Wbrilliant
    > idea I've seen in a month. I just tried it and it works perfectly. Best
    > of all, no kernel hackery, no assembly code to look in some hardwired
    > register, no elevated privileges, just standard, elegant, portable Unix
    > semantics. Thanks!


    Suppose the next destructor does the following:
    1) Delete foo.out
    2) Rename foo.out.tmp to foo.out

    Since you make the program end twice instead of once, step '2' above
    will fail the second time, and the program's output will be lost.

    This is an artificial example, of course, but the point is that you
    can't assume that all subsequent destructors will be idempotent.
    (Suppose the next destructor appends something to a file or makes a
    log entry.)

    DS

  6. Re: Is it possible to determine exit code in library destructor?

    On Oct 1, 6:58*pm, Huibert Bol wrote:
    > Arch Stanton wrote:
    > > I have an interesting problem. I'm writing a shared library which is
    > > inserted into an alien process via LD_PRELOAD. I have almost everything
    > > working beautifully but the library needs to get access to the exit code
    > > before quitting. Its destructor function is definitely called after
    > > exit() so the value must be around someplace but I do not know a way to
    > > get it. Any ideas?

    >
    > This works under Linux. *I had to capture stdout, because date(1) from
    > the coreutils closes stdout before returning from main.


    []

    > * on_exit(exit_handler, 0);


    []

    The man page says "The on_exit() function registers the given function
    to be called *at normal process termination*, whether via exit(3) or
    via return from the program's main()." Which means if the process
    terminates due to a signal this handler is not called.

    --
    Max

  7. Re: Is it possible to determine exit code in library destructor?

    On Oct 1, 6:58*pm, Huibert Bol wrote:
    > Arch Stanton wrote:
    > > I have an interesting problem. I'm writing a shared library which is
    > > inserted into an alien process via LD_PRELOAD. I have almost everything
    > > working beautifully but the library needs to get access to the exit code
    > > before quitting. Its destructor function is definitely called after
    > > exit() so the value must be around someplace but I do not know a way to
    > > get it. Any ideas?

    >
    > This works under Linux. *I had to capture stdout, because date(1) from
    > the coreutils closes stdout before returning from main.


    []

    > * on_exit(exit_handler, 0);


    []

    The man page says "The on_exit() function registers the given function
    to be called *at normal process termination*, whether via exit(3) or
    via return from the program's main()." Which means if the process
    terminates due to a signal this handler is not called.

    --
    Max

  8. Re: Is it possible to determine exit code in library destructor?

    David Schwartz writes:

    > On Oct 1, 2:40*pm, Nate Eldredge wrote:
    >
    >> It seems like any approach is likely to be a hack. *One idea might be
    >> to have your destructor function fork(). *The child returns, and the
    >> parent wait()s in order to see what the exit code is.

    >
    > This is a particularly dangerous hack, changing the program semantics
    > so that it terminates twice instead of once. What happens if the next
    > destructor is not idempotent?


    I envisioned that the parent would call _exit afterwards, so that
    further destructors would run only in the child. Obviously there are
    situations where this could go wrong as well.

    But I certainly don't claim that this hack is in any way reliable,
    only that it might have the desired effect sometimes.



  9. Re: Is it possible to determine exit code in library destructor?

    David Schwartz writes:

    > On Oct 1, 2:40*pm, Nate Eldredge wrote:
    >
    >> It seems like any approach is likely to be a hack. *One idea might be
    >> to have your destructor function fork(). *The child returns, and the
    >> parent wait()s in order to see what the exit code is.

    >
    > This is a particularly dangerous hack, changing the program semantics
    > so that it terminates twice instead of once. What happens if the next
    > destructor is not idempotent?


    I envisioned that the parent would call _exit afterwards, so that
    further destructors would run only in the child. Obviously there are
    situations where this could go wrong as well.

    But I certainly don't claim that this hack is in any way reliable,
    only that it might have the desired effect sometimes.



  10. Re: Is it possible to determine exit code in library destructor?

    On Oct 2, 10:32*am, Nate Eldredge wrote:

    > > This is a particularly dangerous hack, changing the program semantics
    > > so that it terminates twice instead of once. What happens if the next
    > > destructor is not idempotent?


    > I envisioned that the parent would call _exit afterwards, so that
    > further destructors would run only in the child. *Obviously there are
    > situations where this could go wrong as well.


    Then you have the problem of the pid changing, locks not being
    inherited, and god knows what else. It's too bad the child can't call
    '_exit', but then, of course, you'd have to tell it what code to
    return, defeating the entire purpose.

    > But I certainly don't claim that this hack is in any way reliable,
    > only that it might have the desired effect sometimes.


    Yeah. It's dangerous to use in a library that's intended to be a
    general-purpose preloaded library to affect the behavior (predictably)
    or arbitrary applications.

    I believe that 'on_exit' handlers *are* passed the argument to 'exit'.
    Sadly, they're not well-standardized, but they are available on at
    least Linux and some versions of Solaris.

    DS

  11. Re: Is it possible to determine exit code in library destructor?

    On Oct 2, 10:32*am, Nate Eldredge wrote:

    > > This is a particularly dangerous hack, changing the program semantics
    > > so that it terminates twice instead of once. What happens if the next
    > > destructor is not idempotent?


    > I envisioned that the parent would call _exit afterwards, so that
    > further destructors would run only in the child. *Obviously there are
    > situations where this could go wrong as well.


    Then you have the problem of the pid changing, locks not being
    inherited, and god knows what else. It's too bad the child can't call
    '_exit', but then, of course, you'd have to tell it what code to
    return, defeating the entire purpose.

    > But I certainly don't claim that this hack is in any way reliable,
    > only that it might have the desired effect sometimes.


    Yeah. It's dangerous to use in a library that's intended to be a
    general-purpose preloaded library to affect the behavior (predictably)
    or arbitrary applications.

    I believe that 'on_exit' handlers *are* passed the argument to 'exit'.
    Sadly, they're not well-standardized, but they are available on at
    least Linux and some versions of Solaris.

    DS

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2