dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 02, 2009 at 01:20:44PM +0100, Johannes Ring wrote:
> On Wed, Dec 2, 2009 at 12:46 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Wed, Dec 02, 2009 at 12:10:22PM +0100, Johannes Ring wrote:
> >> On Wed, Dec 2, 2009 at 11:58 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> > 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?
> >>
> >> No, it didn't help.
> >
> > ok, can you some other things, like not calling clear() from the
> > previous location in the trace. And if that works, then comment out
> > the lines in clear() one by one.
>
> When I comment out line 62 in dolfin/function/GenericFunction.cpp, the
> stokes/stabilized demo seems to be running "forever" (I killed it
> after ten minutes).

Strange...

Is there some virtual machine or host I could get access to so I can
debug it?

I'll be offline for a few hours but I can look at it later.

--
Anders


> Johannes
>
> >
> >
> >> Johannes
> >>
> >> >
> >> > Garth, is there a reason for using x.resize(0) instead of x.clear()?
> >> >
> >> >
> >> >
> >> >
> >> >> /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)
> >> >
> >> > -----BEGIN PGP SIGNATURE-----
> >> > Version: GnuPG v1.4.9 (GNU/Linux)
> >> >
> >> > iEYEARECAAYFAksWSGQACgkQTuwUCDsYZdGHUQCeKA7jGA5feDDO6Y9Lt96a0mac
> >> > EaIAn3C4V98D13xh11JmYbeYSPoV37Kx
> >> > =vOzG
> >> > -----END PGP SIGNATURE-----
> >> >
> >> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAksWU48ACgkQTuwUCDsYZdFY7wCcCLm6wpm+p+fbx2Y+1YGOku6V
> > t/wAoJWYoAZB7vuBp35oQlZQInErLFUs
> > =HS7e
> > -----END PGP SIGNATURE-----
> >
> >

Attachment: signature.asc
Description: Digital signature