On Wed, Dec 02, 2009 at 01:20:44PM +0100, Johannes Ring wrote: > On Wed, Dec 2, 2009 at 12:46 PM, Anders Logg <l...@simula.no> 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 <l...@simula.no> 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 <joha...@simula.no> > >> >> wrote: > >> >> > On Wed, Dec 2, 2009 at 10:58 AM, Anders Logg <l...@simula.no> 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: > >> >> > >> >> joha...@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, > >> >> eleme...@0x80f64a8, dolfin_ce...@0xbfccc8f8, ufc_ce...@0xbfccc88c, > >> >> local_facet=2) > >> >> at dolfin/function/GenericFunction.cpp:62 > >> >> #2 0xb7c8b780 in dolfin::Expression::restrict (this=0xbfccd268, > >> >> w=0x82ada80, eleme...@0x80f64a8, > >> >> dolfin_ce...@0xbfccc8f8, ufc_ce...@0xbfccc88c, local_facet=2) at > >> >> dolfin/function/Expression.cpp:77 > >> >> #3 0xb7c609b5 in dolfin::DirichletBC::compute_bc_topological > >> >> (this=0xbfccd55c, boundary_valu...@0xbfccc9a8, > >> >> da...@0xbfccc9c0) at dolfin/fem/DirichletBC.cpp:527 > >> >> #4 0xb7c60e4c in dolfin::DirichletBC::compute_bc (this=0xbfccd55c, > >> >> boundary_valu...@0xbfccc9a8, da...@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----- > > > >
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
