[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Pkg-octave-devel] Bug#695551: Bug#695551: panic: segfault at startup



On Mon, 2012-12-10 at 06:05 +0100, Rafael Laboissiere wrote:
> 
> I cannot reproduce this bug on my amd64 testing system.  We need more 
> information on your problem.  

I've got a positive result from a local rebuild.
The clean rebuild using pbuilder gave the same segfault.
A local build however (against the libraries I actually have installed
at the moment) does run successfully.  More specifically, my local build
of liboctave1 fixes the problem. 

Curiously this local liboctave1 seems to work against both my octave
binary builds, pbuilder and local. It fails against the current 3.6.2-5,
with a different error message (the same one I saw in gdb):
error: fclose: invalid stream number = -1
error: called from:
error:   /usr/share/octave/3.6.2/m/pkg/pkg.m at line 463, column 1
error:   /usr/share/octave/3.6.2/m/startup/octaverc at line 21, column 1

In making the local build, I had to ignore the libhdf5-dev
build-dependency (dpkg-buildpackage -d), because I had
libhdf5-openmpi-dev (1.8.8-9) installed.  This ought be fine since
libhdf5-openmpi-dev provides libhdf5-dev, and superficially is fine in
the sense that it builds and runs fine.  It's curious then that
dpkg-buildpackage refused to build without the -d flag.  Does it mean
libhdf5-openmpi-dev needs to provide a versioned libhdf5-dev?

I presume this libhdf5 dependency is the cause of the bug, which means
you should be able to reproduce it by replacing libhdf5-7 with
libhdf5-openmpi-7.  

The Depends of liboctave1 (3.6.2-5) are 
Depends: libamd2.2.0 (>= 1:3.4.0), libarpack2 (>= 2.1), libblas3 |
libblas.so.3 | libatlas3-base, libc6 (>= 2.11), libcamd2.2.0 (>=
1:3.4.0), libccolamd2.7.1 (>= 1:3.4.0), libcholmod1.7.1 (>= 1:3.4.0),
libcolamd2.7.1 (>= 1:3.4.0), libcxsparse2.2.3 (>= 1:3.4.0), libfftw3-3,
libfltk1.1 (>= 1.1.6), libfontconfig1 (>= 2.9.0), libfreetype6 (>=
2.2.1), libgcc1 (>= 1:4.1.1), libgfortran3 (>= 4.6), libgl1-mesa-glx |
libgl1, libgl2ps0, libglu1-mesa | libglu1, libgomp1 (>= 4.2.1),
libhdf5-7, liblapack3 | liblapack.so.3 | libatlas3-base, libncurses5 (>=
5.5-5~), libpcre3 (>= 8.10), libqrupdate1 (>= 1.1.1), libquadmath0 (>=
4.6), libreadline6 (>= 6.0), libstdc++6 (>= 4.6), libtinfo5,
libumfpack5.4.0 (>= 1:3.4.0), libx11-6, zlib1g (>= 1:1.2.0.2)

while my local (working) version has
Depends: libamd2.2.0 (>= 1:3.4.0), libarpack2 (>= 2.1), libblas3 |
libblas.so.3 | libatlas3-base, libc6 (>= 2.11), libcamd2.2.0 (>=
1:3.4.0), libccolamd2.7.1 (>= 1:3.4.0), libcholmod1.7.1 (>= 1:3.4.0),
libcolamd2.7.1 (>= 1:3.4.0), libcxsparse2.2.3 (>= 1:3.4.0), libfftw3-3,
libfltk1.1 (>= 1.1.6), libfontconfig1 (>= 2.9.0), libfreetype6 (>=
2.2.1), libgcc1 (>= 1:4.1.1), libgfortran3 (>= 4.6), libgl1-mesa-glx |
libgl1, libgl2ps0, libglu1-mesa | libglu1, libgomp1 (>= 4.2.1),
liblapack3 | liblapack.so.3 | libatlas3-base, libncurses5 (>= 5.5-5~),
libpcre3 (>= 8.10), libqrupdate1 (>= 1.1.1), libquadmath0 (>= 4.6),
libreadline6 (>= 6.0), libstdc++6 (>= 4.6), libtinfo5, libumfpack5.4.0
(>= 1:3.4.0), libx11-6, zlib1g (>= 1:1.2.0.2)

so the only difference I can see there is the absence of libhdf5-7.  

Apparently the octave build doesn't like the mpi version of libhdf5, and
skips over it.

libhdf5-openmpi-7 Provides: libhdf5-7, (and libhdf5-openmpi-dev
Provides: libhdf5-dev) so I think they're both supposed to "just work"
with liboctave1.   The root of the bug must be here somewhere.

Drew



Reply to: