small patch

[Peter O'Gorman]

On Mon, May 04, 2009 at 04:04:03PM -0400, John W. Eaton wrote:
> On 24-Apr-2009, Peter O'Gorman wrote:
> | The order of the libraries in LD_PRELOAD was important on Solaris, and,
> | iirc, did not work with 'exec'.
 
> What about the following change?
> 
> | Index: run-octave.in
> | ===================================================================
> | --- run-octave.in.orig	2009-01-16 06:46:22.000000000 +0000
> | +++ run-octave.in	2009-04-22 18:31:03.883807961 +0000
> | @@ -67,7 +67,7 @@
> |  fi
> |  
> |  OCTAVE_SITE_INITFILE="$top_srcdir/scripts/startup/main-rcfile" \
> | -LD_PRELOAD="$liboctinterp $liboctave $libcruft" \
> | +LD_PRELOAD="$liboctave $liboctinterp $libcruft" \
> |  %library_path_var%="$builddir/src:$builddir/liboctave:$builddir/libcruft:$%library_path_var%" \
> | -  exec $driver "$builddir/src/octave" --no-initial-path --path="$LOADPATH" --image-path="$IMAGEPATH" --info-file="$INFOFILE" "$@"
> | +  $driver "$builddir/src/octave" --no-initial-path --path="$LOADPATH" --image-path="$IMAGEPATH" --info-file="$INFOFILE" "$@"
> |  
> 
I just checked again, and on sparc-sun-solaris2.10 with no octave
installed, with the original LD_PRELOAD and the exec, I get:
% gmake check
gmake -f octMakefile check
gmake[1]: Entering directory `/opt/build/octave-3.0.5'
gmake -C test check
gmake[2]: Entering directory `/opt/build/octave-3.0.5/test'
../run-octave --norc --silent --no-history ./fntests.m .
ld.so.1: octave: fatal: liboctave.so: open failed: No such file or
directory
gmake[2]: *** [check] Killed
gmake[2]: Leaving directory `/opt/build/octave-3.0.5/test'
gmake[1]: *** [check] Error 2
gmake[1]: Leaving directory `/opt/build/octave-3.0.5'
gmake: *** [check] Error 2


Remove the exec, and:
% gmake check   
gmake -f octMakefile check
gmake[1]: Entering directory `/opt/build/octave-3.0.5'
gmake -C test check
gmake[2]: Entering directory `/opt/build/octave-3.0.5/test'
../run-octave --norc --silent --no-history ./fntests.m .
Segmentation Fault - core dumped
gmake[2]: *** [check] Error 139
gmake[2]: Leaving directory `/opt/build/octave-3.0.5/test'
gmake[1]: *** [check] Error 2
gmake[1]: Leaving directory `/opt/build/octave-3.0.5'
gmake: *** [check] Error 2

The backtrace for the crash is:
(gdb) where
#0  std::string::find (this=<value optimized out>, __c=97 'a', __pos=0)
    at
/opt/build/gcc-4.2.4-objdir/sparc-sun-solaris2.10/libstdc++-v3/include/bits/basic_string.h:596
#1  0xfd961f2c in file_ops::is_dir_sep ()
   from /opt/build/octave-3.0.5/liboctave/liboctave.so
#2  0xfd964054 in file_ops::concat ()
   from /opt/build/octave-3.0.5/liboctave/liboctave.so
#3  0xfe799b0c in __static_initialization_and_destruction_0 ()
   from /opt/build/octave-3.0.5/src/liboctinterp.so
#4  0xfebbdc9c in __do_global_ctors_aux ()
   from /opt/build/octave-3.0.5/src/liboctinterp.so
#5  0xfe64ce88 in _init () from
/opt/build/octave-3.0.5/src/liboctinterp.so
#6  0xff3c55d8 in call_init () from /lib/ld.so.1
#7  0xff3d2708 in elf_bndr () from /lib/ld.so.1
#8  0xff3b8584 in elf_rtbndr () from /lib/ld.so.1
#9  0xff3b8584 in elf_rtbndr () from /lib/ld.so.1


This is not because liboctave requires anything from liboctinterp,
rather the loader does not seem to be able to find liboctave if the exec
remains. Then, with the exec removed, but the LD_PRELOAD order
unchanged, the loader appears to initialize the libraries in the wrong
order, calling the c++ initializers in liboctinterp before those in
liboctave, which results in the segfault.


We did not see issues on any of our platforms with the exec removed and
the order of LD_PRELOAD changed.

Note also, not changing anything works too, if the user does make
install before make check.


> I seem to recall some discussion about the need for "exec" on some
> systems, so I'm reluctant to remove it unconditionally.  Also, what
> doesn't work with the original order of the libraries?  liboctave
> should not depend on anything from liboctinterp, so I don't understand
> why it would need to be loaded before liboctinterp.

> 
> In the future, it would help if you sent separate patches/reports for
> each problem instead of lumping them all together in a single patch.
> 
Ok, thanks.

Peter
-- 
Peter O'Gorman
pogma at thewrittenword.com