Unix Programming - a question about LD

Author

a question about LD_PRELOAD

ronghuazhang@gmail.com

2005-01-17, 3:59 pm

When I used LD_PRELOAD to preload some library, I noticed that when the
application spawns, the library's _init function is called once, but
its _fini function is called twice. Does it mean there are two copies
of the library in the memory? If _init function allocates some
resources, then how can the _fini function tell when it's safe to
release them? Also, how can I make sure only the first invocation of
_init function allocates the resources even if multiple applications
are using the library, can a shared memory help? Thanks

rz

Michael Fuhr

2005-01-18, 3:58 am

ronghuazhang@gmail.com writes:

> When I used LD_PRELOAD to preload some library, I noticed that when the
> application spawns, the library's _init function is called once, but
> its _fini function is called twice.

I think you mean that when the application forks, both the parent
and the child processes call _fini() when they exit. You should
see only one call to _fini() if the child calls _exit() instead of
exit() or returning from its copy of main().

> Does it mean there are two copies of the library in the memory?

There should be two copies of data, but there might be only one
copy of the code itself, depending on how your operating system
works.

> If _init function allocates some resources, then how can the _fini
> function tell when it's safe to release them?

What kind of resources is _init() allocating? Some resources like
malloc()'ed memory will be duplicated in the child and will
automatically be freed when the child exits. External resources
like temporary files might require special handling, though.

> Also, how can I make sure only the first invocation of _init function
> allocates the resources even if multiple applications are using the
> library, can a shared memory help? Thanks

Again, what kind of resources are you talking about? What would
you used shared memory for? If, for example, the library allocates
memory then each process might need to have its own copy of that
memory.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

grid

2005-01-19, 9:00 pm

Hi,
Is there a utility or a quick way to tell if an object file has been
compiled with/without debugging options.

For eg if I compile it with/without debugging option, it gives me the
following if I run the "file" command on my m/c:

$file test.o
test.o: ELF 64-bit MSB relocatable, SPARC V9, version 1, not stripped

How else can I determine weather there is debugging information in the
object file ?

TIA
grid

ronghuazhang@gmail.com

2005-01-19, 9:00 pm

Michael Fuhr wrote:
> ronghuazhang@gmail.com writes:
>
the[color=darkred]
but[color=darkred]
>
> I think you mean that when the application forks, both the parent
> and the child processes call _fini() when they exit. You should
> see only one call to _fini() if the child calls _exit() instead of
> exit() or returning from its copy of main().
>
>
> There should be two copies of data, but there might be only one
> copy of the code itself, depending on how your operating system
> works.
>
>
> What kind of resources is _init() allocating? Some resources like
> malloc()'ed memory will be duplicated in the child and will
> automatically be freed when the child exits. External resources
> like temporary files might require special handling, though.

Suppose I wanna control the memory malloc()'ed by a program and its
fork()'ed children. I am considering allocating a shared memory upon
the first invokation of _init(). Then how can I know when it's safe to
release the shared memory?

Thanks

Heny Townsend

2005-01-20, 8:57 am

ronghuazhang@gmail.com wrote:
> Suppose I wanna control the memory malloc()'ed by a program and its
> fork()'ed children. I am considering allocating a shared memory upon
> the first invokation of _init(). Then how can I know when it's safe to
> release the shared memory?

I can't answer your question but I can tell you two things to watch out for:

1. I've been given to understand that it's best not to use _init()
directly. Rather, declare your own initialization function and register
it to be invoked out of the default _init. The way to do this varies
between compilers. In gcc you mark it as follows:

static void my_init(void) __attribute__ ((constructor));

The Sun compiler uses a #pragma, etc.

2. In my reading and experience, you're not "allowed" to malloc (or use
any interface which might malloc) from the init routine of an
LD_PRELOADed object. This is because your init routine will run before
the libc init routine, and malloc depends on the libc init. YMMV, but
ran into many problems when I tried to do that. Best to treat init like
a signal handler; don't actually do anything in them, just set flags as
reminders to do those things later.

--
Henry Townsend

Sponsored Links