LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 06-01-2009, 07:15 PM   #1
shiprat
LQ Newbie
 
Registered: May 2009
Posts: 2

Rep: Reputation: 0
dynamic memory across shared libraries


hi all,

this is my first post here..

i wonder if anybody can direct me to (or present) a good tutorial on sharing dynamically allocated objects across shared libraries in the same process, and between shared libaries and main().

in particular, i need to know what creation and destruction sequences are valid when libraries are being loaded and unloaded. for example, is it valid to allocate an object from inside a shared library procedure, and then delete that pointer from a different module, especially in the case where the allocating module has already been unloaded.

i imagine there might be all kinds of problems with this. although my preliminary tests seem to work most of the time, i get crashes from time to time, but i'm not sure if they're caused by memory management or by threading issues.

i've been restructuring my code to use a global context object to manage object creation and destruction from main(), but i'd like to find a clear exposition of the specific issues i'm dealing with before i go too much further.

can anybody offer any advice on this?

cheers
Jono
 
Old 06-02-2009, 01:08 PM   #2
SciYro
Senior Member
 
Registered: Oct 2003
Location: hopefully not here
Distribution: Gentoo
Posts: 2,038

Rep: Reputation: 51
There should be no problem, depending upon the data types and their dependencies.

Any memory malloc'd by your program can be free'd by your program. It should not matter what thread is used, or what shared library, or what part of your program.

Of course, while its possible it might not be practicle. Various libraries provide for destruction functions for their data because a simple free() might not work, perhaps because it was never free'able memory, or because the data must first be cleaned to prevent other parts of the library from trying to use it, etc. (think of a linked list, if you free one of the links, other links will still refrence the old link and you can get a crash. The entire linked list must be cleaned up to remove all traces of a link before it can be free'd).
 
Old 06-02-2009, 01:24 PM   #3
paulsm4
LQ Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
You're not in Windows anymore, Dorothy ;-)

SciYro is correct, that there's no problem with shared memory, regardless of whether or not the shared memory segment(s) happen to be use by/in a shared library or not.

In particular, many of the considerations for Windows .dll's do *not* apply to Linux .so's.

Here are a couple of good links:
http://www.yolinux.com/TUTORIALS/Lib...ndDynamic.html
http://fscked.org/writings/SHM/shm.html
http://www.ibm.com/developerworks/li...w06LinuxMemory

'Hope that helps .. PSM
 
Old 06-02-2009, 02:06 PM   #4
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194
The first two answers pretty much covered it. This isn't Windows. There is only one heap in a correctly loaded combination of main executable and multiple .so's. At the malloc and free level, it all just works right. This isn't Windows.

Quote:
Originally Posted by shiprat View Post
i need to know what creation and destruction sequences are valid when libraries are being loaded and unloaded.
But that can be trickier.

The most obvious way to get into trouble is with virtual destructors:

In a .so construct an object that has a virtual destructor, then unload the .so, then destroy the object. Probably your program will crash.

There are other ways to get into similar trouble.

Quote:
for example, is it valid to allocate an object from inside a shared library procedure, and then delete that pointer from a different module, especially in the case where the allocating module has already been unloaded.
The only question there, is what code will be called by the destructors. The actual deallocation of the dynamic memory is no problem (did I mention this isn't Windows). But the destructors (and anything else the object does after the constructing .so is gone) can't use code that isn't there. This isn't magic.

Quote:
i get crashes from time to time, but i'm not sure if they're caused by memory management or by threading issues.
Lots of possibilities, including threading issues, but also including things like virtual destructors (if you have any).

Quote:
i've been restructuring my code to use a global context object to manage object creation and destruction from main()
Depends how the construction happens. You might be correctly pulling the vtables and everything they call into the main image, avoiding virtual destructor problems, or you might not be. If your focus is on the memory, you're missing the point.

Last edited by johnsfine; 06-02-2009 at 02:08 PM.
 
Old 06-02-2009, 08:36 PM   #5
shiprat
LQ Newbie
 
Registered: May 2009
Posts: 2

Original Poster
Rep: Reputation: 0
thanx everybody, thats very useful. how did you guess i had a background in windows, paulsm4? :P

johnsfine said:
The most obvious way to get into trouble is with virtual destructors:
In a .so construct an object that has a virtual destructor, then unload the .so, then destroy the object. Probably your program will crash.


yes, so what i'm doing now is constructing all dynamic objects thru a call to a singleton factory object, created by main and visible to the libraries. these objects are boost::shared_ptr's to boost::variants, so plenty of scope for trouble. what i'm assuming is that the destruction sequence is initialized on creation, and that since the constructor is called from main(), all should be well.

johnsfine also said:
There are other ways to get into similar trouble.

i'd be interested in hearing about those...

but yeah. Depends how the construction happens. You might be correctly pulling the vtables and everything they call into the main image, avoiding virtual destructor problems, or you might not be. If your focus is on the memory, you're missing the point.

that pretty much sums it up and is what i'm focusing on now. i'm pretty sure i've got it right. no more crashes yet, anyway. at the moment, main and the .so's are all linked to the same static lib which holds the definitions for these objects, but i plan to make that a shared (but not dynamic) library at some stage.

anyway, cheers! any more comments would be appreciated.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Dynamic shared memory user777 Linux - General 6 02-16-2009 07:36 AM
gxine: error while loading shared libraries: libmozjs.so: cannot open shared object.. khronosschoty Slackware 10 11-10-2008 07:33 PM
error while loading shared libraries: libgvc.so.3: cannot open shared object file coolrock Slackware 6 01-17-2007 05:10 PM
error while loading shared libraries: libdb-4.1.so: cannot open shared object file putquery8581 Linux - Software 1 10-01-2004 07:03 AM
Mixing Shared and Dynamic Libraries linuxeco Programming 1 02-02-2003 09:04 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 01:53 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration