SIGABRT when plotting

[Martin Sandve Alnæs]

Has anyone else seen this when plotting? Latest ubuntu, latest dolfin, vtk and qt from ubuntu apt, free ati drivers from ubuntu apt (proprietary ati drivers currently doesn't work with unity in ubuntu...)

Full stacktrace from gdb below, this is the last place in dolfin:

#40 dolfin::VTKWindowOutputStage::~VTKWindowOutputStage (this=0x2b2d7a0, __in_chrg=<optimized out>)
    at /home/martinal/dev/fenics/dolfin/work/dolfin/plot/VTKWindowOutputStage.cpp:225

VTKWindowOutputStage::~VTKWindowOutputStage()
{
  // Note: VTK (current 5.6.1) seems to very picky about the order of
  // destruction. This destructor tries to impose an order on the most
  // important stuff.

  //log(DBG, "VTK pipeline destroyed");

#ifdef HAS_QVTK
  widget.reset(NULL); // Line 225
#endif

  helptextActor = NULL;
  balloonRep = NULL;
  balloonwidget = NULL;

  _renderer = NULL;
  _renderWindow = NULL;
}

--- Stacktrace from gdb:

pure virtual method called
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0 0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff6f1db8b in __GI_abort () at abort.c:91
#2 0x00007ffff18bbe2d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff18b9f26 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff18b9f53 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff18baa6f in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffc0e7249e in llvm::BumpPtrAllocator::DeallocateSlabs(llvm::MemSlab*) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#7 0x00007fffc06922ea in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#8 0x00007fffc06924c9 in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#9 0x00007fffc09d37a6 in llvm::PMDataManager::~PMDataManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#10 0x00007fffc09d8fc5 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#11 0x00007fffc09d00ce in llvm::PMTopLevelManager::~PMTopLevelManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#12 0x00007fffc09d9096 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#13 0x00007fffc09cfe71 in llvm::FunctionPassManager::~FunctionPassManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#14 0x00007fffc09cfec9 in llvm::FunctionPassManager::~FunctionPassManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
#15 0x00007fffc1c21035 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#16 0x00007fffc1c213b9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#17 0x00007fffc1c0418f in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#18 0x00007fffc1c045ac in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#19 0x00007fffc1a97ef0 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#20 0x00007fffc1a98d7a in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#21 0x00007fffc1b5df05 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#22 0x00007fffc1a9f73e in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#23 0x00007fffc1aa09b1 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#24 0x00007fffc1aa0a5b in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#25 0x00007fffc1a9f8bb in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#26 0x00007fffc19f87da in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#27 0x00007fffc1a95e22 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#28 0x00007fffc19e19ea in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#29 0x00007fffc19af903 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#30 0x00007fffe0140dbc in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#31 0x00007fffe011a0fb in glXMakeCurrentReadSGI () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#32 0x00007fffe8734a22 in vtkXOpenGLRenderWindow::MakeCurrent() () from /usr/lib/libvtkRendering.so.5.8
#33 0x00007fffe8734ce6 in vtkXOpenGLRenderWindow::DestroyWindow() () from /usr/lib/libvtkRendering.so.5.8
#34 0x00007fffe78e9175 in QVTKWidget::SetRenderWindow(vtkRenderWindow*) () from /usr/lib/libQVTK.so.5.8
#35 0x00007fffe78e9228 in QVTKWidget::~QVTKWidget() () from /usr/lib/libQVTK.so.5.8
#36 0x00007fffe78e9289 in QVTKWidget::~QVTKWidget() () from /usr/lib/libQVTK.so.5.8
#37 0x00007ffff0d63660 in checked_delete<QVTKWidget> (x=<optimized out>) at /usr/include/boost/checked_delete.hpp:34
#38 ~scoped_ptr (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/scoped_ptr.hpp:80
#39 reset (p=0x0, this=0x2b2d800) at /usr/include/boost/smart_ptr/scoped_ptr.hpp:86
#40 dolfin::VTKWindowOutputStage::~VTKWindowOutputStage (this=0x2b2d7a0, __in_chrg=<optimized out>)
    at /home/martinal/dev/fenics/dolfin/work/dolfin/plot/VTKWindowOutputStage.cpp:225
#41 0x00007ffff0d6fc70 in checked_delete<dolfin::VTKWindowOutputStage> (x=0x2b2d7a0) at /usr/include/boost/checked_delete.hpp:34
#42 ~scoped_ptr (this=0x30e62c0, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/scoped_ptr.hpp:80
#43 dolfin::VTKPlotter::~VTKPlotter (this=0x30e6220, __in_chrg=<optimized out>)
    at /home/martinal/dev/fenics/dolfin/work/dolfin/plot/VTKPlotter.cpp:145
#44 0x00007ffff0d6fd69 in dolfin::VTKPlotter::~VTKPlotter (this=0x30e6220, __in_chrg=<optimized out>)
    at /home/martinal/dev/fenics/dolfin/work/dolfin/plot/VTKPlotter.cpp:148
#45 0x00007ffff0d5d353 in release (this=0x32dd660) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145
#46 ~shared_count (this=0x32dc1a8, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:305
#47 ~shared_ptr (this=0x32dc1a0, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:164
#48 destroy (__p=0x32dc1a0, this=<optimized out>) at /usr/include/c++/4.7/ext/new_allocator.h:123
#49 std::_List_base<boost::shared_ptr<dolfin::VTKPlotter>, std::allocator<boost::shared_ptr<dolfin::VTKPlotter> > >::_M_clear (
    this=0x7ffff13d1280 <stored_plotters>) at /usr/include/c++/4.7/bits/list.tcc:78
#50 0x00007ffff6f1f901 in __run_exit_handlers (status=0, listp=0x7ffff729c6a8 <__exit_funcs>, run_list_atexit=true) at exit.c:78
#51 0x00007ffff6f1f985 in __GI_exit (status=<optimized out>) at exit.c:100
#52 0x00007ffff6f05774 in __libc_start_main (main=0x44b77b <main>, argc=2, ubp_av=0x7fffffffdc88, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdc78) at libc-start.c:258
#53 0x00000000004ce0ad in _start ()

[Johan Hake (johan-hake)]

Looks like a graphics driver bug to me. Not that I have seen any recently.

Maybe time to ditch unity? ;)

Johan

On 12/04/2012 11:14 AM, Martin Sandve Alnæs wrote:
> Public bug reported:
>
> Has anyone else seen this when plotting? Latest ubuntu, latest dolfin,
> vtk and qt from ubuntu apt, free ati drivers from ubuntu apt
> (proprietary ati drivers currently doesn't work with unity in ubuntu...)
>
> Full stacktrace from gdb below, this is the last place in dolfin:
>
> #40 dolfin::VTKWindowOutputStage::~VTKWindowOutputStage (this=0x2b2d7a0, __in_chrg=<optimized out>)
> at /home/martinal/dev/fenics/dolfin/work/dolfin/plot/VTKWindowOutputStage.cpp:225
>
>
> VTKWindowOutputStage::~VTKWindowOutputStage()
> {
> // Note: VTK (current 5.6.1) seems to very picky about the order of
> // destruction. This destructor tries to impose an order on the most
> // important stuff.
>
> //log(DBG, "VTK pipeline destroyed");
>
> #ifdef HAS_QVTK
> widget.reset(NULL); // Line 225
> #endif
>
> helptextActor = NULL;
> balloonRep = NULL;
> balloonwidget = NULL;
>
> _renderer = NULL;
> _renderWindow = NULL;
> }
>
>
> --- Stacktrace from gdb:
>
> pure virtual method called
> terminate called without an active exception
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) where
> #0 0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x00007ffff6f1db8b in __GI_abort () at abort.c:91
> #2 0x00007ffff18bbe2d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #3 0x00007ffff18b9f26 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #4 0x00007ffff18b9f53 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #5 0x00007ffff18baa6f in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #6 0x00007fffc0e7249e in llvm::BumpPtrAllocator::DeallocateSlabs(llvm::MemSlab*) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #7 0x00007fffc06922ea in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #8 0x00007fffc06924c9 in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #9 0x00007fffc09d37a6 in llvm::PMDataManager::~PMDataManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #10 0x00007fffc09d8fc5 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #11 0x00007fffc09d00ce in llvm::PMTopLevelManager::~PMTopLevelManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #12 0x00007fffc09d9096 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #13 0x00007fffc09cfe71 in llvm::FunctionPassManager::~FunctionPassManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #14 0x00007fffc09cfec9 in llvm::FunctionPassManager::~FunctionPassManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #15 0x00007fffc1c21035 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri....

[Martin Sandve Alnæs (martinal)]

Just to be clear, the plot shows fine, but when closing it it crashes.

[Martin Sandve Alnæs (martinal)]

Actually, the crash seems to be at the end of the entire program, and it only happens if I have plotted twice:

from dolfin import *
mesh = UnitSquare(1,1)
V = FunctionSpace(mesh, "CG", 1)
f = Function(V)
g = Function(V)
plot(f, title='f')
plot(g, title='g')

[Anders Logg (logg)]

Does it help if you build VTK manually? The quantal-hpc.platform file
should work out of the box with the latest Ubuntu so it's just a
matter of running the script and waiting ca 2 hours.

--
Anders

On Tue, Dec 04, 2012 at 10:14:58AM -0000, Martin Sandve Alnæs wrote:
> Public bug reported:
>
> Has anyone else seen this when plotting? Latest ubuntu, latest dolfin,
> vtk and qt from ubuntu apt, free ati drivers from ubuntu apt
> (proprietary ati drivers currently doesn't work with unity in ubuntu...)
>
> Full stacktrace from gdb below, this is the last place in dolfin:
>
> #40 dolfin::VTKWindowOutputStage::~VTKWindowOutputStage (this=0x2b2d7a0, __in_chrg=<optimized out>)
> at /home/martinal/dev/fenics/dolfin/work/dolfin/plot/VTKWindowOutputStage.cpp:225
>
>
> VTKWindowOutputStage::~VTKWindowOutputStage()
> {
> // Note: VTK (current 5.6.1) seems to very picky about the order of
> // destruction. This destructor tries to impose an order on the most
> // important stuff.
>
> //log(DBG, "VTK pipeline destroyed");
>
> #ifdef HAS_QVTK
> widget.reset(NULL); // Line 225
> #endif
>
> helptextActor = NULL;
> balloonRep = NULL;
> balloonwidget = NULL;
>
> _renderer = NULL;
> _renderWindow = NULL;
> }
>
>
> --- Stacktrace from gdb:
>
> pure virtual method called
> terminate called without an active exception
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) where
> #0 0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x00007ffff6f1db8b in __GI_abort () at abort.c:91
> #2 0x00007ffff18bbe2d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #3 0x00007ffff18b9f26 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #4 0x00007ffff18b9f53 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #5 0x00007ffff18baa6f in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #6 0x00007fffc0e7249e in llvm::BumpPtrAllocator::DeallocateSlabs(llvm::MemSlab*) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #7 0x00007fffc06922ea in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #8 0x00007fffc06924c9 in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #9 0x00007fffc09d37a6 in llvm::PMDataManager::~PMDataManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #10 0x00007fffc09d8fc5 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #11 0x00007fffc09d00ce in llvm::PMTopLevelManager::~PMTopLevelManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #12 0x00007fffc09d9096 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #13 0x00007fffc09cfe71 in llvm::FunctionPassManager::~FunctionPassManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #14 0x00007fffc09cfec9 in llvm::FunctionPassManager::~FunctionPassManager() () from /usr/lib/x86_64-linux-gnu/lib...

[Joachim Haga (jobh)]

I don't see this error myself, but a workaround may be to just not delete the GL widgets. Could you try the attached patch, see if it helps any?

[Martin Sandve Alnæs (martinal)]

The patch works, thanks.

Haven't tried the hpc platform.

[Anders Logg (logg)]

On Tue, Dec 04, 2012 at 12:13:14PM -0000, Martin Sandve Alnæs wrote:
> The patch works, thanks.
>
> Haven't tried the hpc platform.

Do it! :-)

--
Anders

[Martin Sandve Alnæs (martinal)]

It doesn't seem "just a matter of..." to me :)

The following packages will be REMOVED:
  gimp ... libreoffice-base-core ... libreoffice-writer ... python-matplotlib ...
0 upgraded, 0 newly installed, 92 to remove and 4 not upgraded.

Why is it necessary to remove so much? I have separate stable and unstable installations, and source the .conf file for the one I wish to use, why can't the hpc installation live on the side as well?

[Johan Hake (johan-hake)]

If you do not remove all boost libraries I think your not that bad of.
python-matplotlib you need to install your self, but all the other nice
packages like gimp and libre-office I have from the apt repo.

Johan

On 12/05/2012 01:44 PM, Martin Sandve Alnæs wrote:
> It doesn't seem "just a matter of..." to me :)
>
> The following packages will be REMOVED:
> gimp ... libreoffice-base-core ... libreoffice-writer ... python-matplotlib ...
> 0 upgraded, 0 newly installed, 92 to remove and 4 not upgraded.
>
> Why is it necessary to remove so much? I have separate stable and
> unstable installations, and source the .conf file for the one I wish to
> use, why can't the hpc installation live on the side as well?
>

[Martin Sandve Alnæs (martinal)]

Still, the requirement to _not_ have libfoo installed also implies that anything that depends on libfoo cannot be installed. That's a rather harsh demand. I'm trying without removing, Johannes says that _should_ be fine :)

[Johan Hake (johan-hake)]

Sure, but I remembered I removed everything but libboost*. Isn't it
essential to remove openmpi and its dependencies, and atlas and
suitsparse to not screw later configurations?

Johan

On 12/05/2012 01:58 PM, Martin Sandve Alnæs wrote:
> Still, the requirement to _not_ have libfoo installed also implies that
> anything that depends on libfoo cannot be installed. That's a rather
> harsh demand. I'm trying without removing, Johannes says that _should_
> be fine :)
>

[Anders Logg (logg)]

It's not that bad. Just reinstall it after the build (of DOLFIN
dependencies). So next time you want to use openoffice, just grab it
with apt-get which is fast, especially if you installed it before and
it's already cached in /var/cache/apt/

The removal of some of those packages may be overkill but it's just to
be on the safe side so the build will not pick up some boost or lapack
package from the system when it should really use the manually
installed boost and atlas blas/lapack.

Note that the install of the DOLFIN dependencies is something you
don't need to do very often (maybe a few times per year). Then you can
keep rebuilding DOLFIN against that stack.

--
Anders

On Wed, Dec 05, 2012 at 12:44:44PM -0000, Martin Sandve Alnæs wrote:
> It doesn't seem "just a matter of..." to me :)
>
> The following packages will be REMOVED:
> gimp ... libreoffice-base-core ... libreoffice-writer ... python-matplotlib ...
> 0 upgraded, 0 newly installed, 92 to remove and 4 not upgraded.
>
> Why is it necessary to remove so much? I have separate stable and
> unstable installations, and source the .conf file for the one I wish to
> use, why can't the hpc installation live on the side as well?
>

[Martin Sandve Alnæs (martinal)]

The same crash happens on ubuntu 12.10 as a virtualbox guest on a windows 7 host os and nvidia gpu, so this is not about my laptop or ati drivers.

[Martin Sandve Alnæs (martinal)]

Is there a reason for not applying the patch above to trunk?

[Johan Hake (johan-hake)]

On 12/06/2012 02:00 PM, Martin Sandve Alnæs wrote:
> Is there a reason for not applying the patch above to trunk?

Just do it man!

J

[Joachim Haga (jobh)]

Sorry, I've been a bit absent(-minded). I think the patch is ok, it's
not like we have an ever growing number of plotting windows. With VTK
(already) we don't delete the actual windows because it tends to...
crash.

-j

On 6 December 2012 14:34, Johan Hake <email address hidden> wrote:
> On 12/06/2012 02:00 PM, Martin Sandve Alnæs wrote:
>> Is there a reason for not applying the patch above to trunk?
>
> Just do it man!
>
> J
>
> --
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1086310
>
> Title:
> SIGABRT when plotting
>
> Status in DOLFIN:
> New
>
> Bug description:
> Has anyone else seen this when plotting? Latest ubuntu, latest dolfin,
> vtk and qt from ubuntu apt, free ati drivers from ubuntu apt
> (proprietary ati drivers currently doesn't work with unity in
> ubuntu...)
>
> Full stacktrace from gdb below, this is the last place in dolfin:
>
> #40 dolfin::VTKWindowOutputStage::~VTKWindowOutputStage (this=0x2b2d7a0, __in_chrg=<optimized out>)
> at /home/martinal/dev/fenics/dolfin/work/dolfin/plot/VTKWindowOutputStage.cpp:225
>
>
> VTKWindowOutputStage::~VTKWindowOutputStage()
> {
> // Note: VTK (current 5.6.1) seems to very picky about the order of
> // destruction. This destructor tries to impose an order on the most
> // important stuff.
>
> //log(DBG, "VTK pipeline destroyed");
>
> #ifdef HAS_QVTK
> widget.reset(NULL); // Line 225
> #endif
>
> helptextActor = NULL;
> balloonRep = NULL;
> balloonwidget = NULL;
>
> _renderer = NULL;
> _renderWindow = NULL;
> }
>
>
> --- Stacktrace from gdb:
>
> pure virtual method called
> terminate called without an active exception
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) where
> #0 0x00007ffff6f1a425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x00007ffff6f1db8b in __GI_abort () at abort.c:91
> #2 0x00007ffff18bbe2d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #3 0x00007ffff18b9f26 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #4 0x00007ffff18b9f53 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #5 0x00007ffff18baa6f in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #6 0x00007fffc0e7249e in llvm::BumpPtrAllocator::DeallocateSlabs(llvm::MemSlab*) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #7 0x00007fffc06922ea in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #8 0x00007fffc06924c9 in llvm::MemoryDependenceAnalysis::~MemoryDependenceAnalysis() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #9 0x00007fffc09d37a6 in llvm::PMDataManager::~PMDataManager() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1
> #10 0x00007fffc09d8fc5 in ?? () from /usr/lib/x86_64-linu...

[Johannes Ring (johannr)]

This was fixed in revision 7198.