[Discuss] Memory management issue when linking duplicate code

Alan W. Irwin irwin at beluga.phys.uvic.ca
Sat Mar 21 16:09:35 PDT 2015


After years of experimentally refining my knowledge of Linux linking I
have just run into a new issue I have never noticed before.

The situation is I compile the same code into two distinct shared
libraries to break a circular linking issue.  All routines that appear
in the small library also appear in the large one, but not vice versa.
By accident I linked an executable to both libraries.  That generated
a run-time segfault and valgrind showed plenty of invalid reads for
that situation.  And to my surprise the cure for these memory management problems
was to link the executable to just the large library and completely
ignore the small one.

Obviously, I should have done that in the first place.  Nevertheless,
I am quite puzzled by this result, and I wonder if anyone knows what
is really going on here.  You would think that when faced with
duplicate code in two libraries, the linker would resolve executable
symbols with symbols corresponding to one of the duplicate sets of
code in one of the libraries and ignore the duplicate code in the
other library without any run-time consequences at all.  But from my
recent experience this is not the case for modern Linux. I suspect
there are some behind-the-scenes Linux run-time shenanigans going on
to close both shared libraries when the executable exits, and those
are the cause of the memory management issues described above. But
that is only speculation, and I sure would like to know the definitive
cause of this curious memory management issue when linking shared
libraries that contain duplicate code.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the Discuss mailing list