Subject: [FEniCS-dev] Build time bugs in syfi and segfaults in dolfin

From: Balbir Thomas <[email-masked]>
Date: Wed, 11 Feb 2009 08:23:09 -0500

Hi,

In trying to build syfi I found the following bugs

1) There are multiple formal parameters named x1 in  the Triangle and
Tetrahedron constructors found in syfi/Polygon.h

Based on syfi/Polygon.cpp I presume this is a typo and instead they should
have been sequentially named x1, x2, ... etc.

2) The sort function was not declared in syfi/OrderedPtvSet.cpp

I presume the author intended to use the standard library sort function from
<algorithm>

Fixing these solves the build failure problem on Debian/Lenny.

Apart from the above all fenics packages built very easly on Debian/Lenny
with no changes. Thank you.
However the dolfin package has a build dependency on swig (>=1.3.37). Lenny
has
1.3.36. Downgrading the dependency to 1.3.36 seemed to cause no build
problems.
However I wonder if I have exposed any runtime bugs here. Is there an
absolute dependency
on version 1.3.37 of swig ? Could this be the reason that the demo at
http://www.fenics.org/wiki/Tutorial segfaults. Similar segmentation faults
also occur
with many of the demo python scripts in the dolfin-doc package. This
behavior is also seen
with the C++ examples for instance in demo/pde/poisson/cpp running :

scons
./demo

results in a segmentation fault. GDB shows :

(gdb) run
Starting program: /home/bt/demo/pde/poisson/cpp/demo
[Thread debugging using libthread_db enabled]
[New Thread 0xb5a936c0 (LWP 4791)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5a936c0 (LWP 4791)]
0xb7ece3c7 in MPID_P4_Init () from /usr/lib/libdolfin.so.0
(gdb) where
#0  0xb7ece3c7 in MPID_P4_Init () from /usr/lib/libdolfin.so.0
#1  0xb7ecd3ad in MPID_CH_InitMsgPass () from /usr/lib/libdolfin.so.0
#2  0xb7ec86ad in MPID_Init () from /usr/lib/libdolfin.so.0
#3  0xb7e9436c in MPIR_Init () from /usr/lib/libdolfin.so.0
#4  0xb7e941bc in PMPI_Init () from /usr/lib/libdolfin.so.0
#5  0xb7de30c8 in dolfin::SubSystemsManager::initMPI () from
/usr/lib/libdolfin.so.0
#6  0xb7de09a7 in dolfin::MPI::num_processes () from /usr/lib/libdolfin.so.0
#7  0xb7dd5072 in dolfin::Logger::Logger () from /usr/lib/libdolfin.so.0
#8  0xb7dd4865 in ?? () from /usr/lib/libdolfin.so.0
#9  0xb7edf2fd in ?? () from /usr/lib/libdolfin.so.0
#10 0xb7f63d70 in ?? () from /usr/lib/libdolfin.so.0
#11 0xb7fa5928 in ?? ()
#12 0xbfbc1f08 in ?? ()
#13 0xb7cbb948 in _init () from /usr/lib/libdolfin.so.0
Backtrace stopped: frame did not save the PC

What may I not being doing correctly ?

regards
B Thomas

---

From: Kent Andre <[email-masked]>
Date: Wed, 11 Feb 2009 14:39:56 +0100

On on., 2009-02-11 at 08:23 -0500, Balbir Thomas wrote:
> Based on syfi/Polygon.cpp I presume this is a typo and instead they
> should have been sequentially named x1, x2, ... etc.

Correct. 

Which version are you using ? This is not the case in my version ..

> I presume the author intended to use the standard library sort
> function from <algorithm>

Correct. 

> Apart from the above all fenics packages built very easly on
> Debian/Lenny with no changes. Thank you.
> However the dolfin package has a build dependency on swig (>=1.3.37).
> Lenny has
> on version 1.3.37 of swig ? 

I think 1.3.37 is required in the development version. Not sure for the
stable branch. 

>
> Could this be the reason that the demo at
> http://www.fenics.org/wiki/Tutorial segfaults. Similar segmentation
> faults also occur
> #5  0xb7de30c8 in dolfin::SubSystemsManager::initMPI ()
> from /usr/lib/libdolfin.so.0
> _______________________________________________
> FEniCS-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/fenics-dev

---

From: Balbir Thomas <[email-masked]>
Date: Wed, 11 Feb 2009 09:27:40 -0500

The syfi version i am using is 0.5.1 which was downloaded from

http://packages.simula.no/pool/main/s/syfi/

All other fenics packages were downloaded from the same repository

regards
bt

---

From: Johan Hake <[email-masked]>
Date: Wed, 11 Feb 2009 21:26:17 +0100

On Wednesday 11 February 2009 14:23:09 Balbir Thomas wrote:
> I presume the author intended to use the standard library sort function
> from <algorithm>
>

The development version of PyDOLFIN together with UFC and FFC has a swig 
version dependency of >=1.3.35. The precompiled ubuntu packages has a 
dependency of swig 1.3.37. This package can be apt-get installed from our 
repositories. 

Can you please hand the error message that says that you need swig >=1.3.37?

I am not sure how the compatablility is for lenny, but you should be able to 
build most fenics packages using dorsal,

  <http://www.fenics.org/wiki/Dorsal>

It should support Etch and "testing"

> absolute dependency on version 1.3.37 of swig ? 

See above.

> with the C++ examples for instance in demo/pde/poisson/cpp running :

When something happens in a C++ demo swig cannot be blamed.

> #6  0xb7de09a7 in dolfin::MPI::num_processes () from
> /usr/lib/libdolfin.so.0 #7  0xb7dd5072 in dolfin::Logger::Logger () from
> /usr/lib/libdolfin.so.0 #8  0xb7dd4865 in ?? () from
> /usr/lib/libdolfin.so.0

It looks like something happens in some MPI code. DOLFIN is confirmed to work 
with the OpenMPI that comes with the Ubuntu hardy/intrepid versions.

---

From: Harish Narayanan <[email-masked]>
Date: Wed, 11 Feb 2009 21:33:20 +0100

> It should support Etch and "testing"

It's known to work with lenny.

>> What may I not being doing correctly ?

Make sure you have openmpi installed, and if you have other mpi
libraries installed, make sure:

sudo update-alternatives --config mpi

is set to openmpi.

Harish

---

From: Balbir Thomas <[email-masked]>
Date: Wed, 11 Feb 2009 16:18:56 -0500

Hi,

On Wed, Feb 11, 2009 at 3:26 PM, Johan Hake <[email-masked]> wrote:

>
> > Can you please hand the error message that says that you need swig
> >=1.3.37?

Well the debian/control file (of dolfin) lists it as a hard dependency in
the Build-Depends line "swig (>=1.3.37)" . I am glad to know that the swig
dependency is >= 1.3.35. This would mean that the segmentation fault
problems is not because of swig but because of MPI. I do have both MPICH and
OPENMPI installed. They were installed automatically when I choose some of
the debian science and math "tasks" (packages), meaning expect others to
face the same situation. From what you (Johan) say I suspect that MPICH is
the culprit. Though I have not decided how i am going to confirm this short
of uninstalling mpich and all the packages that depend on it, potentially
breaking my fresh Debian/Lenny install. Any suggestions ? I plan to play
around with different configure options and see how i can isolate the dolfin
build process and subsequent use from seeing mpich. This may just be a bug
in the packaging but could also be a problem with the pkg-config setup
(--cflags etc).

Another potential problem with the Build-Depends line is the fact that it
has "python-all". However on all current deb based distributions
"python-all" includes python2.4 (even on lenny). But Fenics is not
compatible with python2.4 as far as I know since it uses additions to python
since python2.5 such as set functions "any", "all" and lexical elements such
as generators etc. I believe python-all must be replaced by python (>=2.5)
on the build depends line.

> > build most fenics packages using dorsal,

I could use dorsal but shouldn't the debian source package be enough and be
the recomended way to build fenics on a deb based distribution ? After all
if Fenics is going to make it into one of the official Debian (or Debian
based) distributions it will need to build cleanly from the source package.
I maintain a local repository of deb packages on my computer to make it easy
for me to do automated upgrades and rebuilds using Debian's built-in tools,
for packages that are not part of the Debian distributions as yet.

>
> The problem with Etch and the source packages were the build dependencies.
For instance libsuitesparse among many others. Despite this I spent a couple
of days installing all the build dependencies on Etch and trying to port
Fenics to python2.4 but finally decided I may find it easier to work with
Debian/Lenny. While in principle it is possible to rewrite the build
dependencies so that builds are successfull on Etch too, I think it would
not be worth the effort given lenny seems to be right around the corner and
the fact that in Etch the recomended python version is 2.4 (but is 2.5 in
lenny). However there are problems with lenny too (in particular the
segfaults). Once again while I appreciate the Fenics developers efforts in
writing dorsal (and I will probably check it out), I would like to still
request them to provide source packages that may cleanly be built by
themselves. Perhaps dorsal can be a wrapper over the Debian/Ubuntu and
RedHat source packages. Is it so ? I havent' checked it out but will do so.
I hope you do see why I urge this case.

Agreed. I thought so too and so I mentioned the fact.

> It looks like something happens in some MPI code. DOLFIN is confirmed to
work\
> with the OpenMPI that comes with the Ubuntu hardy/intrepid versions.

Agreed. And I believe this is the likely problem too. I will try and dig
deeper (as mentioned above) on this issue but am not sure how far I will
get. It will be great if one of your developers could also try to replicate
these issues on Debian/Lenny, as my familiarity with the Fenics source code
is limited. Kindly do post a patch to this thread if one of the Fenics
developers does find the problem. I will do so to should I ... .

Thanking you
B Thomas

---

From: Balbir Thomas <[email-masked]>
Date: Wed, 11 Feb 2009 16:28:45 -0500

> It's known to work with lenny.

Please see my previous post in reply to Johan (probably posted just as your
were posting too)

> is set to openmpi

I do have (and did have) openmpi installed (again please see previous post)
---

bt@cpp:$ dpkg -l openmpi-bin
ii  openmpi-bin                       1.2.7~rc2-2                       high
performance message passing library -- binaries
bt@cpp:$ dpkg -l libopenmpi-dev
ii  libopenmpi-dev                    1.2.7~rc2-2                       high
performance message passing library -- header files

I did just update alternatives and tried to rebuild a demo but it sefaulted
too. I am going to try rebuild dolfin again, and see if that works. If this
is indeed the problem then it must be checked form in the build scripts of
dolfin and/or an apropriate statement added to the controls file.

Thank you for your suggestion

regards
b thomas

---

From: Johan Hake <[email-masked]>
Date: Wed, 11 Feb 2009 22:43:01 +0100

On Wednesday 11 February 2009 22:18:56 Balbir Thomas wrote:
> the Build-Depends line "swig (>=1.3.37)" . 

Ok. I think the logic was that as we provide packages for swig 1.3.37 we just 
made it depend on 1.3.37. Could this hard dependency be loosened up Johannes?

> I am glad to know that the swig 
> problems is not because of swig but because of MPI. I do have both MPICH
> and OPENMPI installed. They were installed automatically when I choose some
> of the debian science and math "tasks" (packages), meaning expect others to
> around with different configure options and see how i can isolate the
> dolfin build process and subsequent use from seeing mpich. This may just be
> a bug in the packaging but could also be a problem with the pkg-config
> setup (--cflags etc).
>
> compatible with python2.4 as far as I know since it uses additions to
> python since python2.5 such as set functions "any", "all" and lexical
> elements such as generators etc. I believe python-all must be replaced by
> python (>=2.5) on the build depends line.

I just forward this to our debian packages maintainer, Johannes?

> > > I am not sure how the compatablility is for lenny, but you should be
> > > able
> >
> > to
> >
> I maintain a local repository of deb packages on my computer to make it
> easy for me to do automated upgrades and rebuilds using Debian's built-in
> tools, for packages that are not part of the Debian distributions as yet.

You are of course right!

> For instance libsuitesparse among many others. Despite this I spent a
> couple of days installing all the build dependencies on Etch and trying to
> port Fenics to python2.4 but finally decided I may find it easier to work
> with Debian/Lenny. While in principle it is possible to rewrite the build

Probably Johannes can come back with more fruitfull comments about the debian 
packages issues you have!

Johan

---

From: Matthew Knepley <[email-masked]>
Date: Wed, 11 Feb 2009 15:48:40 -0600

> > and OPENMPI installed.

I am not sure I understand why compatibility would depend on the
implementation of MPI?
Isn't that the point of having a standard? I don't see any problems
switching them in PETSc.
Is there a real bug in an MPI impl here, or just a preference for OpenMPI?

  Thanks,

    Matt

-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener

---

From: Balbir Thomas <[email-masked]>
Date: Wed, 11 Feb 2009 18:48:15 -0500

Couple of more points:

I am attempting to rebuild dolfin 0.9.0 after switching the defaults in
debian (as suggested by Harish, i.e. update-alternatives to openmpi),
however build fails with the following error (oddly enough build did not
fail before this change !! ).

mpic++ -o dolfin/swig/cpp_wrap.os -c -Wall -pipe -ansi -Werror -DDEBUG -g
-DNDEBUG -O2 -DHAS_MPI=1 -DMPICH_IGNORE_CXX_SEEK -DPACKAGE_VERSION=\"0.9.0\"
-DHAS_PETSC=1 -DHAS_SCOTCH=1 -DHAS_UMFPACK=1 -DHAS_GTS=1 -DHAS_CHOLMOD=1
-fno-strict-aliasing -fPIC -I. -I/usr/include -I/usr/include
-I/usr/include/libxml2 -I/usr/lib/petsc/bmake/linux-gnu-c-opt
-I/usr/lib/petsc/include -I/usr/lib/openmpi/include -I/usr/lib/openmpi/lib
-Idolfin -I/usr/include/scotch -I/usr/include/suitesparse -I/usr/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/suitesparse -I/usr/include/python2.5 -I/usr/include/python2.5
-I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/include
-I/usr/include -I/usr/include/libxml2 -I/usr/lib/petsc/bmake/linux-gnu-c-opt
-I/usr/lib/petsc/include -I/usr/lib/openmpi/include -I/usr/lib/openmpi/lib
-Idolfin -I/usr/include/scotch -I/usr/include/suitesparse -I/usr/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/suitesparse dolfin/swig/cpp_wrap.cc
cc1plus: warnings being treated as errors
dolfin/swig/cpp_wrap.cc: In function 'PyObject*
_wrap_new_LUSolver(PyObject*, PyObject*)':
dolfin/swig/cpp_wrap.cc:52898: error: 'argv[0]' may be used uninitialized in
this function
dolfin/swig/cpp_wrap.cc: In function 'PyObject* _wrap_summary(PyObject*,
PyObject*)':
dolfin/swig/cpp_wrap.cc:29895: error: 'argv[0]' may be used uninitialized in
this function
dolfin/swig/cpp_wrap.cc: In function 'PyObject*
_wrap_new_TimeDependent(PyObject*, PyObject*)':
dolfin/swig/cpp_wrap.cc:27852: error: 'argv[0]' may be used uninitialized in
this function
dolfin/swig/cpp_wrap.cc: In function 'PyObject* _wrap_new_Vector(PyObject*,
PyObject*)':
dolfin/swig/cpp_wrap.cc:48256: error: 'argv[0]' may be used uninitialized in
this function
dolfin/swig/cpp_wrap.cc: In function 'PyObject* _wrap_new_Table(PyObject*,
PyObject*)':
dolfin/swig/cpp_wrap.cc:30972: error: 'argv[0]' may be used uninitialized in
this function
dolfin/swig/cpp_wrap.cc: In function 'PyObject* _wrap_new_Mesh(PyObject*,
PyObject*)':
dolfin/swig/cpp_wrap.cc:79066: error: 'argv[0]' may be used uninitialized in
this function
dolfin/swig/cpp_wrap.cc: In function 'PyObject*
_wrap_new_DiscreteFunction(PyObject*, PyObject*)':
dolfin/swig/cpp_wrap.cc:63711: error: 'argv[0]' may be used uninitialized in
this function
scons: *** [dolfin/swig/cpp_wrap.os] Error 1
scons: building terminated because of errors.

Looks like either -Werror flag will need to be done away with or cpp_wrap.cc
may need to be fixed to elminate warnings. Unfortunately I am not familiar
with scons to fix this.

Also I noticed though building dolfin requires MPI there is no explicit
build dependency in the Build-Depends line of the debian/control file. It is
listed as :

Build-Depends: debhelper (>= 5), python (>=2.5), python-central (>= 0.5.6),
scons, swig (>= 1.3.36), python-dev, python-numpy, libgts-dev, libxml2-dev,
libboost-dev, libsuitesparse-dev, petsc2.3.3-dev, ufc (>= 1.1)

Note: (Only change made by me are replacing python-all by python (>=2.5) and
swig (>=1.3.37) by swig (>=1.3.36) for reasons discussed in this thread.

This line must also have "libopenmpi-dev" in it or better "libopenmpi-dev |
libmpich1.0-dev" if fenics is indeed compatible with both openmpi and mpich
and requires MPI (as suggested by enableMPI=1 in debian/rules)!.

A minor point - VERSION=0.8.1 (in debian/rules) it should be 0.9.0 but it
doesn't seem to be used.

ATTN Johannes :

Please do let me know if you need any information regarding the debian
packages installed on my system to replicate the problems in this thread. It
is a pretty standard Debian/Lenny install. You could email me directly if
you prefer.

regards
bt

cc: Johannes

---

From: "Garth N. Wells" <[email-masked]>
Date: Thu, 12 Feb 2009 10:38:33 +0000

Balbir Thomas wrote:
> mpic++ -o dolfin/swig/cpp_wrap.os -c -Wall -pipe -ansi -Werror -DDEBUG 
> -g -DNDEBUG -O2 -DHAS_MPI=1 -DMPICH_IGNORE_CXX_SEEK 
> -DPACKAGE_VERSION=\"0.9.0\" -DHAS_PETSC=1 -DHAS_SCOTCH=1 -DHAS_UMFPACK=1 
> -DHAS_GTS=1 -DHAS_CHOLMOD=1 -fno-strict-aliasing -fPIC -I. 
> -I/usr/include -I/usr/include -I/usr/include/libxml2 
> -I/usr/lib/petsc/bmake/linux-gnu-c-opt -I/usr/lib/petsc/include 
> -I/usr/lib/openmpi/include -I/usr/lib/openmpi/lib -Idolfin 
> -I/usr/include/scotch -I/usr/include/suitesparse -I/usr/include 
> -I/usr/include -I/usr/include/libxml2 
> -I/usr/lib/petsc/bmake/linux-gnu-c-opt -I/usr/lib/petsc/include 
> -I/usr/lib/openmpi/include -I/usr/lib/openmpi/lib -Idolfin 
> -I/usr/include/scotch -I/usr/include/suitesparse -I/usr/include 
> dolfin/swig/cpp_wrap.cc:52898: error: 'argv[0]' may be used 
> uninitialized in this function
> dolfin/swig/cpp_wrap.cc:29895: error: 'argv[0]' may be used 
> uninitialized in this function
> dolfin/swig/cpp_wrap.cc:27852: error: 'argv[0]' may be used 
> uninitialized in this function
> _wrap_new_Vector(PyObject*, PyObject*)':
> dolfin/swig/cpp_wrap.cc:48256: error: 'argv[0]' may be used 
> uninitialized in this function
> _wrap_new_Table(PyObject*, PyObject*)':
> dolfin/swig/cpp_wrap.cc:30972: error: 'argv[0]' may be used 
> uninitialized in this function
> _wrap_new_Mesh(PyObject*, PyObject*)':
> dolfin/swig/cpp_wrap.cc:79066: error: 'argv[0]' may be used 
> uninitialized in this function
> dolfin/swig/cpp_wrap.cc:63711: error: 'argv[0]' may be used 
> uninitialized in this function
> Looks like either -Werror flag will need to be done away with or 
> cpp_wrap.cc may need to be fixed to elminate warnings. Unfortunately I 
> am not familiar with scons to fix this.
> 
> build dependency in the Build-Depends line of the debian/control file. 
> It is listed as :
> 
> Build-Depends: debhelper (>= 5), python (>=2.5), python-central (>= 
> 0.5.6), scons, swig (>= 1.3.36), python-dev, python-numpy, libgts-dev, 
> libxml2-dev, libboost-dev, libsuitesparse-dev, petsc2.3.3-dev, ufc (>= 1.1)
> 
> Note: (Only change made by me are replacing python-all by python (>=2.5) 
> and swig (>=1.3.37) by swig (>=1.3.36) for reasons discussed in this thread.
> 
> This line must also have "libopenmpi-dev" in it or better 
> "libopenmpi-dev | libmpich1.0-dev" if fenics is indeed compatible with 
> both openmpi and mpich and requires MPI (as suggested by enableMPI=1 in 
> debian/rules)!.
> 

MPICH comes in two flavours - MPICH and MPICH2. Although I have not 
tested it for some some, DOLFIN should work seamlessly with MPICH2. It 
will not work with MPICH because there is some old code in MPICH which 
caused build problems with DOLFIN (MPICH hasn't been updated for more 
then 3 years)

Garth

> A minor point - VERSION=0.8.1 (in debian/rules) it should be 0.9.0 but 
> it doesn't seem to be used.
> 
> ATTN Johannes :
> 
> packages installed on my system to replicate the problems in this 
> thread. It is a pretty standard Debian/Lenny install. You could email me 
> directly if you prefer.
> 
> regards
> bt
> 
> cc: Johannes
> 
> 
> ------------------------------------------------------------------------
>