Shared Library Issue

Shared Library Issue

Post by Raj Sistl » Sat, 23 Mar 2002 09:39:12



My executable links to a shared object (.so). When I run multiple copies of
the executable, the memory footprint of each instance reflects that an
instance of the shared object is getting loaded in to memory for each
executable instance.

Is this normal? I was expecting shared objects to behave like DLLs - code
segment if not replicated in RAM across multiple instances of the calling
executable.

Any suggestions?

Thanks much
Raj

 
 
 

Shared Library Issue

Post by Jimmy Zhan » Sat, 23 Mar 2002 17:55:46


You might be looking at the virtual memory, the real physical content could
be
mapped to different processes. So it might be appear to you that way.

>My executable links to a shared object (.so). When I run multiple copies of
>the executable, the memory footprint of each instance reflects that an
>instance of the shared object is getting loaded in to memory for each
>executable instance.

>Is this normal? I was expecting shared objects to behave like DLLs - code
>segment if not replicated in RAM across multiple instances of the calling
>executable.

>Any suggestions?

>Thanks much
>Raj


 
 
 

Shared Library Issue

Post by Raj Sistl » Sun, 24 Mar 2002 07:12:20


Well, I viewed the memory usage using "cat /proc/meminfo" and found that the
"MemFree" was decreasing by an equal amount with each successive instance of
the process.

Isn't MemFree the amount of free memory available?

Thanks
Raj


> You might be looking at the virtual memory, the real physical content
could
> be
> mapped to different processes. So it might be appear to you that way.


> >My executable links to a shared object (.so). When I run multiple copies
of
> >the executable, the memory footprint of each instance reflects that an
> >instance of the shared object is getting loaded in to memory for each
> >executable instance.

> >Is this normal? I was expecting shared objects to behave like DLLs - code
> >segment if not replicated in RAM across multiple instances of the calling
> >executable.

> >Any suggestions?

> >Thanks much
> >Raj

 
 
 

Shared Library Issue

Post by Jimmy Zhan » Mon, 25 Mar 2002 18:59:08


Hmm...

Someone corrects me if I am wrong here.
.so could be static shared lib, the linker does the address patching, in
this
case no mem sharing takes place.

Or, .so is dynamic shared lib, the *loader* does the address patching, you
can expect mem sharing in this case.

Check the compiling flags to figure out if the lib is staticly or dynamicly
shared.


>Well, I viewed the memory usage using "cat /proc/meminfo" and found that
the
>"MemFree" was decreasing by an equal amount with each successive instance
of
>the process.

>Isn't MemFree the amount of free memory available?

>Thanks
>Raj



>> You might be looking at the virtual memory, the real physical content
>could
>> be
>> mapped to different processes. So it might be appear to you that way.


>> >My executable links to a shared object (.so). When I run multiple copies
>of
>> >the executable, the memory footprint of each instance reflects that an
>> >instance of the shared object is getting loaded in to memory for each
>> >executable instance.

>> >Is this normal? I was expecting shared objects to behave like DLLs -
code
>> >segment if not replicated in RAM across multiple instances of the
calling
>> >executable.

>> >Any suggestions?

>> >Thanks much
>> >Raj

 
 
 

1. chroot shared library issues...

I've set up anonymous ftp and a chrooted httpd on solaris, for the
first time, in the last few days.

The ftpd man pages and the various solaris FAQs and solaris-manager
mailing list summaries I found on the web all mention which
dynamic libraries are needed. Many conflict, and anyway, I wish
I knew how to determine what was needed myself, without anyone
telling me.

I read the ldd man page, and figured that would do the trick.

For example:

anonymous ftp needs access to ls, and ldd sez that ls (I'm doing this
on a 2.6 ultra) needs  /usr/lib/libc.so.1 and  /usr/lib/libdl.so.1.

ldd sez that  /usr/lib/libc.so.1 needs /usr/lib/libdl.so.1.

ldd sez that /usr/lib/libdl.so.1 don't need nuthin.

So, sure enough, I put only libc.so.1 and libdl.so.1, and of course
ld.so and ld.so.1, into ftpd's chrooted usr/lib, and ls works
great.

Is this all there is to it, or was I just lucky?

-Mike

2. Ping time gets longer and longer

3. Infomagic Moo-Tiff shared library issue

4. ** curses and standard C I/O ?

5. Will strip(debug shared library) == nodebug shared library ?

6. creating toolbar in kde

7. Help with building shared libraries with dependencies on other shared libraries

8. 100Mb - Controller ?

9. Question: Inclusion of shared libraries during linking of shared libraries

10. Shared library loading shared library.

11. Need a Shared Library Guru: beyond simple shared library question

12. When is a shared library not a shared library?

13. Shared object libraries issue