dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 02, 2009 at 11:24:56AM +0100, Johannes Ring wrote:
> On Wed, Dec 2, 2009 at 11:02 AM, Johannes Ring <johannr@xxxxxxxxx> wrote:
> > On Wed, Dec 2, 2009 at 10:58 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> On Wed, Dec 02, 2009 at 10:24:18AM +0100, Johannes Ring wrote:
> >>> Hi,
> >>>
> >>> Someone pushed the Force Build button on the winxp-mingw32 slave. I
> >>> don't see a good reason for this since the demo.log shows it quite
> >>> clearly why it fails:
> >>>
> >>> http://fenics.org:8080/builders/dolfin-winxp-mingw32/builds/11/steps/dolfin%20check/logs/demo.log
> >>>
> >>> The problem is the same as the hardy-i386 slave reports, that is, the
> >>> following two demos exits with a segmentation fault:
> >>>
> >>> demo\pde\stokes\stabilized\cpp
> >>> demo\pde\stokes\taylor-hood\cpp
> >>
> >> I can't figure out why these fail. Valgrind does not complain on my
> >> machine. Does anyone have a 32 bit system to test on?
> >
> > Yes, I have my laptop. I will try to do some debugging.
>
> I got a segfault too. Here is the output from running
> demo\pde\stokes\stabilized\cpp in gdb:
>
> johannr@simula-x61:cpp$ gdb ./demo
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486-linux-gnu"...
> (gdb) run
> Starting program:
> /home/johannr/src/bzr/dolfin/demo/pde/stokes/stabilized/cpp/demo
> [Thread debugging using libthread_db enabled]
> [New Thread 0xb536a6c0 (LWP 21306)]
> Solving linear variational problem
>   Matrix of size 8604 x 8604 has 174636 nonzero entries.
>   Applying boundary conditions to linear system.
>   Applying boundary conditions to linear system.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb536a6c0 (LWP 21306)]
> 0xb7c265c8 in dolfin::Data::clear () from
> /home/johannr/src/bzr/dolfin/local/lib/libdolfin.so.0
> Current language:  auto; currently asm
> (gdb) where
> #0  0xb7c265c8 in dolfin::Data::clear () from

The line

  x.resize(0);

in the function Data::clear() in dolfin/function/Data.cpp looks
suspicious. Could you try replacing that line with

  x.clear();

and see if that helps?

Garth, is there a reason for using x.resize(0) instead of x.clear()?

--
Anders



> /home/johannr/src/bzr/dolfin/local/lib/libdolfin.so.0
> #1  0xb7ca13aa in dolfin::GenericFunction::restrict_as_ufc_function
> (this=0xbfccd268, w=0x82ada80,
>     element=@0x80f64a8, dolfin_cell=@0xbfccc8f8, ufc_cell=@0xbfccc88c,
> local_facet=2)
>     at dolfin/function/GenericFunction.cpp:62
> #2  0xb7c8b780 in dolfin::Expression::restrict (this=0xbfccd268,
> w=0x82ada80, element=@0x80f64a8,
>     dolfin_cell=@0xbfccc8f8, ufc_cell=@0xbfccc88c, local_facet=2) at
> dolfin/function/Expression.cpp:77
> #3  0xb7c609b5 in dolfin::DirichletBC::compute_bc_topological
> (this=0xbfccd55c, boundary_values=@0xbfccc9a8,
>     data=@0xbfccc9c0) at dolfin/fem/DirichletBC.cpp:527
> #4  0xb7c60e4c in dolfin::DirichletBC::compute_bc (this=0xbfccd55c,
> boundary_values=@0xbfccc9a8, data=@0xbfccc9c0)
>     at dolfin/fem/DirichletBC.cpp:488
> #5  0xb7c64520 in dolfin::DirichletBC::apply (this=0xbfccd55c,
> A=0xbfcccb58, b=0xbfcccb10, x=0x0)
>     at dolfin/fem/DirichletBC.cpp:320
> #6  0xb7c64a03 in dolfin::DirichletBC::apply (this=0xbfccd55c,
> A=@0xbfcccb58, b=@0xbfcccb10)
>     at dolfin/fem/DirichletBC.cpp:173
> #7  0xb7c47d41 in dolfin::VariationalProblem::solve_linear
> (this=0xbfccd2e0, u=@0xbfcccf9c)
>     at dolfin/fem/VariationalProblem.cpp:204
> #8  0xb7c48bbc in dolfin::VariationalProblem::solve (this=0x3,
> u=@0x80f6648) at dolfin/fem/VariationalProblem.cpp:93
> #9  0x08074a06 in main () at main.cpp:89
> (gdb)

Attachment: signature.asc
Description: Digital signature