Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-10-22 Thread Emmanuel Promayon 

Dear all,


I have read that upstream is joining Debian Science to package recent
upstream version VTK8.  I expect that VTK6 will be removed from Debian
soon.  So yes, I'd strongly recommend to follow the stable release cycle
of VTK upstream, which means that porting camitk to VTK7 is necessary
for including camitk into Debian and it is sensible to do some checks
with VTK8 since at some point in time this will be used in Debian.  We
will not be able to support more than two VTK versions in Debian (most
probably only one).
  
Just to let you know about my progress: I finally find some time to try 
to get the current camitk to work with vtk7 and suppress all the 
dependencies to vtk6.

The main problem is due to the necessary change to OpenGL2 backend.
This effort is on a good way thanks to some tweak I found in a post on 
vtk user back in 2016 [1].


To avoid any other potential problem is some other package, should gdcm 
not be set as to conflict with vtk6?



So far for a short note - more details from VTK maintainers ...
I would still love to know more about the progress towards an official 
debian package for vtk8 (or 9 as it seems on its way!).
I found some discussion about vtk7 and vtk8 packages on debian science 
mailing list and kitware blog, but I am not sure I well understood the 
meaning or consequences.


So any idea about the (near) future would be a great help!

Kind regards,
Emmanuel

[1] 
http://vtk.1045678.n5.nabble.com/Find-reason-for-exclusion-of-vtkGUISupportQtOpenGL-in-build-output-td5738976.html

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-09-24 Thread Andreas Tille 
On Mon, Sep 24, 2018 at 02:49:37PM +0200, Emmanuel Promayon wrote:
> - if there is no (easy) way to go back to vtk6 in gdcm (or to support both
> vtk6 and vtk7), does this means that we (upstream) need to update CamiTK to
> be based on VTK7 in order to fix this bug?

Disclaimer: I have no idea about VTK and all its dependencies.

I have read that upstream is joining Debian Science to package recent
upstream version VTK8.  I expect that VTK6 will be removed from Debian
soon.  So yes, I'd strongly recommend to follow the stable release cycle
of VTK upstream, which means that porting camitk to VTK7 is necessary
for including camitk into Debian and it is sensible to do some checks
with VTK8 since at some point in time this will be used in Debian.  We
will not be able to support more than two VTK versions in Debian (most
probably only one).
 
So far for a short note - more details from VTK maintainers ...

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-09-24 Thread Emmanuel Promayon 

Hello all

Thanks again to Andreas and Bernhard. You are right: the problem comes 
from gdcm 2.8.7-2.


I tried to build the package with the previous version of vtkgdcm. With 
version 2.8.7-1 all the tests pass and the packages are built normally 
(and autopkgtest does not fail either).


If I understood well (let me know otherwise), the history of this bug 
goes like this:

- the gdcm package was updated to support python3
- in the process, the dependency of gdcm was updated from vtk6 to vtk7 
(see this commit [1], which took effect in gdcm 2.8.7-2)
- one extension (i.e., plugin) of CamiTK requires gdcm to read DICOM 
images. During the first build after gdcm 2.8.7-2 was available on sid, 
vtk6 was used to build CamiTK core library and gdcm 2.8.7-2 (using vtk7) 
was used to build the dicom extension of CamiTK.
- In the test where the dicom extension is loaded (this is not all the 
CamiTK test, hence the specific test failures), the class RendererWidget 
of CamiTK was confused with both vtk share library loaded in memory (as 
Berhnard message pointed out).

- This bug was born
- Berhnard (bravely!) decided to update the dependency of CamiTK from 
vtk6 to vtk7, which resulted in other problem (probably due to the use 
of VTK class QVTKWidget2 in the CamiTK class RendererWidget)


My questions to all:
- is there any other package using vtk6 and gdcm 2.8.7-2 that are 
affected by this?
- should the gdcm package not add (some kind of) conflict flag with vtk6 
(so that this problem can be more easily detected in the future)?
- if there is no (easy) way to go back to vtk6 in gdcm (or to support 
both vtk6 and vtk7), does this means that we (upstream) need to update 
CamiTK to be based on VTK7 in order to fix this bug?


And two bonus subsidiary questions to Gert , Steve and Sébastien :
- About VTK8 : is there any plan to add a vtk8 package in debian? I 
don't really know what is the release policy of VTK, but it seems they 
went from 7.0 to 7.1 to directly 8.0 and then 8.1, and I saw VTK 9 
mentioned (if you have more information or pointer about the release 
policy or the roadmap, I will be very thankful!). I found an article on 
the Kitware blog saying that they have their own apt repository for sid 
providing nightly builds of VTK [2]. Do you know any more about that? 
What is your "vision" about vtk8 in debian?
- (more technical and may be not in the proper context) about VTK Qt and 
OpenGL: VTK8 seems to have introduced a different class to manage VTK 
renderer inside Qt widget (QVTKOpenGLWidget instead of QVTKWidget). This 
is an area where we add a lot of problem with Qt5+VTK6 (especially on 
linux+intel integrated video cards and windows virtual machines). So it 
seems that transition to VTK8 brings more hope. Do you have any 
experience of migrating QVTKWidget from VTK6 to VTK7 or VTK8?


Thanks again to Andreas and Bernhard and in advance to Gert, Steve and 
Sébastien!

Hopefully this bug can be solved soon...

Best regards,
Emmanuel

PS : and of course the double delete discovered by Bernhard [3] should 
be solved upstream as well!


[1] 
https://salsa.debian.org/med-team/gdcm/commit/dd4f5d00b99730388512f512743e0be48ce56ae2
[2] 
https://blog.kitware.com/rethinking-debian-packaging-for-vtk-and-other-cmake-projects-part-1/

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909120#10

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-09-21 Thread Bernhard Übelacker 
Hello Emmanuel,
I made a mistake and did my first investigations on testing instead of unstable.
So my findings of my first mail are unrelated (but hope they still help).

So I did another try and got all tests fail like in the reproducible build log.


Something bad happens in these lines:
(gdb) list RendererWidget.cpp:589
588 
orientationDecorationsTextMapper[i]->SetInput(orientationDecorationLetters[i].toStdString().c_str());
589 
orientationDecorationsTextMapper[i]->GetTextProperty()->ShallowCopy(orientationDecorationsProp);


Valgrind also points to that location.

For some reason I could not step into the SetInput method and tried
therefore to get further on instruction level and found my self to
my surprise in libvtkRenderingOpenGL2-7.1.so.7.1.

Therefore I assume Andreas is right that libvtkgdcm2.8 started this issue,
as that pulls in libvtk7.1, so we have some vtk6 and some vtk7 libraries in
the same process.

I tried changing debian/control to build agains libvtk7-dev and libvtk7-qt-dev.
With that even more tests crash in the same QGLContext::makeCurrent call,
but thats maybe a different issue.

Kind regards,
Bernhard



With all required dbgsym packages installed the stack looks like this:
(gdb) bt
#0  vtkTextProperty::ShallowCopy (this=0xbae9c9b0, tprop=0x55cdbae92d70) at 
./Rendering/Core/vtkTextProperty.cxx:70
#1  0x7fdb0af837d7 in camitk::RendererWidget::RendererWidget(QWidget*, 
camitk::RendererWidget::ControlMode) () at 
/usr/include/vtk-6.3/vtkSmartPointer.h:77
#2  0x7fdb0af6fd42 in 
camitk::InteractiveViewer::InteractiveViewer(QString&, 
camitk::InteractiveViewer::ViewerType) () at 
./sdk/libraries/core/viewer/InteractiveViewer.cpp:192
#3  0x7fdb0af71533 in camitk::InteractiveViewer::getNewViewer(QString, 
camitk::InteractiveViewer::ViewerType) () at 
./sdk/libraries/core/viewer/InteractiveViewer.cpp:90
#4  0x7fdb0af717c5 in camitk::InteractiveViewer::getViewer(QString) () at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:953
#5  0x7fdb0af71b25 in camitk::InteractiveViewer::getAxialViewer() () at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:953
#6  0x7fdb0af3ca2f in camitk::SingleImageComponent::initRepresentation() () 
at ./sdk/libraries/core/component/image/SingleImageComponent.cpp:94
#7  0x7fdb0af3cb67 in 
camitk::SingleImageComponent::SingleImageComponent(camitk::Component*, 
camitk::Slice::SliceOrientation, QString const&, 
vtkSmartPointer) () at 
./sdk/libraries/core/component/image/SingleImageComponent.cpp:58
#8  0x7fdb0af33fbf in camitk::ImageComponent::buildImageComponents() () at 
/usr/include/vtk-6.3/vtkSmartPointer.h:26
#9  0x7fdb0af36b4d in 
camitk::ImageComponent::setImageData(vtkSmartPointer, bool, 
camitk::ImageOrientationHelper::PossibleImageOrientations, 
vtkSmartPointer) () at 
./sdk/libraries/core/component/image/ImageComponent.cpp:313
#10 0x7fdaf567adf9 in VtkImageComponent::createComponent(QString const&) () 
at /usr/include/vtk-6.3/vtkSmartPointer.h:26
#11 0x7fdaf567b905 in VtkImageComponent::VtkImageComponent(QString const&) 
() at ./sdk/components/vtkimage/VtkImageComponent.cpp:53
#12 0x7fdaf567bf3a in VtkImageComponentExtension::open(QString const&) () 
at ./sdk/components/vtkimage/VtkImageComponentExtension.cpp:76
#13 0x7fdb0af04c24 in camitk::Application::open(QString const&) () at 
./sdk/libraries/core/application/Application.cpp:470
#14 0x55cdb93043df in main () at /usr/include/c++/8/bits/basic_string.h:2293
#15 0x7fdb09eccb17 in __libc_start_main (main=0x55cdb9303e80 , 
argc=5, argv=0x7ffd21845c18, init=, fini=, 
rtld_fini=, stack_end=0x7ffd21845c08) at ../csu/libc-start.c:310
#16 0x55cdb93051aa in _start () at 
./sdk/applications/testactions/main.cpp:189


LANG=C dpkg --purge libvtk7.1
dpkg: dependency problems prevent removal of libvtk7.1:
 libvtkgdcm2.8:amd64 depends on libvtk7.1.


(gdb) info share
>FromTo  Syms Read   Shared Object Library
...
0x77265580  0x77458d2d  Yes 
/usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.3.so.6.3
...
0x7fffe934cee0  0x7fffe9515aed  Yes (*) 
/usr/lib/x86_64-linux-gnu/libvtkCommonCore-7.1.so.7.1


# Unstable:


- change sources.list from buster to unstable
apt update
apt dist-upgrade
reboot
apt autoremove
apt install apt-show-versions
apt-show-versions | grep No
dpkg --purge libdns-export1100

apt build-dep camitk
apt install mc htop systemd-coredump fakeroot gdb valgrind git libvtk6.3-dbgsym 
libqt5core5a-dbgsym


mkdir vtk6/orig -p
cdvtk6/orig
apt source vtk6
cd ../..


mkdir qtbase-opensource-src/orig -p
cdqtbase-opensource-src/orig
apt source qtbase-opensource-src
cd ../..


mkdir camitk/orig -p
cdcamitk/orig
apt source camitk
cd ../..


cd camitk
cp -a orig try1
cd try1/camitk-4.1.2
dpkg-buildpackage



[Sa Sep 22 00:00:04 2018] camitk-testacti[24045]: segfault at bae9c9b0 ip 
7fdb08754f15 sp 7ffd21844f50 error 4 in

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-09-21 Thread Andreas Tille 
On Fri, Sep 21, 2018 at 07:05:40PM +0200, Emmanuel Promayon wrote:
> Andreas, do you have any smart way to check the list of packages that have
> changed/been uploaded in sid in the dependencies of a package during a
> period of time (here from 9 Sep to 15 Sep)? This might help me finding how
> to solve this.

Since you mentioned vtk in your long text I simply checked

https://tracker.debian.org/libvtkgdcm2-dev

I think we have found a probably candidate (see "news" section).
(gdcm Uploaders in CC - please check the full bug log of this bug)

Hope this helps

Andreas.

-- 
http://fam-tille.de

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-09-21 Thread Emmanuel Promayon 

Dear Bernhard,

Thank you for your investigation and your time. You are right about 
these double delete and this will have to be fixed.


But I am still puzzled:
1) your patch is absolutely required for handling delete properly (btw 
thanks for the corresponding references!) but unfortunately it can fix 
only some of the tests
2) this bug only appeared recently, no segfault were detected before on 
sid (first trace I found of a failure is in our weekly packaging test 
last Sunday 15 September, everything was fine on Sunday 9 September)

3) the segfaults are generated during testing

This probably means that the problem comes from a deeper (darker, harder 
to find) side of the build.


So I started with the first test on the list that generates a segfaults 
(test #27 named action-editframes-level1-1) and run it through the 
debugger (I run it through the same xvfb-run command line as in the 
debian/control file).


Here is the first outcome:

xvfb-run --auto-servernum --server-args="-screen 0 1024x768x24" 
/usr/bin/gdb 
/root/packaging/camitk-debian-ci/camitk-build/bin/camitk-testactions

GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/root/packaging/camitk-debian-ci/camitk-build/bin/camitk-testactions...done.
(gdb) r "-i" 
"/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha" 
"-a" 
"/root/packaging/camitk-debian-ci/camitk-build/lib/camitk-4.2/actions/libeditframes.so"
Starting program: 
/root/packaging/camitk-debian-ci/camitk-build/bin/camitk-testactions 
"-i" 
"/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha" 
"-a" 
"/root/packaging/camitk-debian-ci/camitk-build/lib/camitk-4.2/actions/libeditframes.so"

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
camitk-testactions run with arguments:
- action library file: 
"/root/packaging/camitk-debian-ci/camitk-build/lib/camitk-4.2/actions/libeditframes.so"
- input test file: 
"/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha"

Working directory: /root/packaging/camitk-debian-ci/camitk-build
Starting the camitk default application...
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[New Thread 0x7fffec879700 (LWP 8505)]
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[New Thread 0x7fffe7f46700 (LWP 8507)]
[OK]
Opening component: 
/root/packaging/camitk-debian-ci/camitk-build/share/camitk-4.2/testdata/brain.mha...

[New Thread 0x7fffda562700 (LWP 8514)]
[New Thread 0x7fffd9d61700 (LWP 8515)]
[New Thread 0x7fffd9560700 (LWP 8516)]
[Thread 0x7fffda562700 (LWP 8514) exited]
[New Thread 0x7fffd8d5f700 (LWP 8517)]
[Thread 0x7fffd9d61700 (LWP 8515) exited]
[New Thread 0x7fffd3fff700 (LWP 8518)]
[New Thread 0x7fffd37fe700 (LWP 8519)]
[New Thread 0x7fffd2ffd700 (LWP 8520)]
[Thread 0x7fffd9560700 (LWP 8516) exited]
[Thread 0x7fffd8d5f700 (LWP 8517) exited]
[Thread 0x7fffd3fff700 (LWP 8518) exited]
[Thread 0x7fffd2ffd700 (LWP 8520) exited]
[Thread 0x7fffd37fe700 (LWP 8519) exited]
[New Thread 0x7fffd2ffd700 (LWP 8521)]
[New Thread 0x7fffd37fe700 (LWP 8522)]
[New Thread 0x7fffd3fff700 (LWP 8523)]
[New Thread 0x7fffd8d5f700 (LWP 8524)]
[New Thread 0x7fffd25c4700 (LWP 8525)]
[New Thread 0x7fffd1dc3700 (LWP 8526)]
[New Thread 0x7fffd15c2700 (LWP 8527)]
[New Thread 0x7fffd0dc1700 (LWP 8528)]

Thread 1 "camitk-testacti" received signal SIGSEGV, Segmentation fault.
0x75718f15 in vtkTextProperty::ShallowCopy(vtkTextProperty*) () 
from /lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3

(gdb) where
#0  0x75718f15 in vtkTextProperty::ShallowCopy(vtkTextProperty*) 
() from /lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3
#1  0x77f457d7 in 
camitk::RendererWidget::RendererWidget(QWidget*, 
camitk::RendererWidget::ControlMode) () at 
/usr/include/vtk-6.3/vtkSmartPointer.h:77
#2  0x77f31d42 in 
camitk::InteractiveViewer::InteractiveViewer(QString&, 
camitk::InteractiveViewer::ViewerType) ()

    at ./sdk/libraries/core/viewer/InteractiveViewer.cpp:192
#3  0x77f33533 in 
camitk::InteractiveViewer::getNewViewer(QString, 
camitk::InteractiveViewer::ViewerType) ()

    at ./sdk/libraries/core/viewer/InteractiveViewer.cpp:90
#4 

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-09-20 Thread Andreas Tille 
Control: tags -1 upstream

Hi Bernhard,

thanks a lot for your investigation.  Emmanuel Promayon is Uploader and
Upstream and I think he will come back to you and hopefully will
implement the fix soon.

Kind regards

   Andreas.

On Thu, Sep 20, 2018 at 06:01:38PM +0200, Bernhard Übelacker wrote:
> Hello all,
> I tried to reproduce this issue.
> 
> Unfortunately I never get the "(SEGFAULT)" output for all tests,
> just "(Failed)" for most. But some do really segfault in my amd64 VM.
> 
> I think the segfaults are caused by the line "delete component;", that
> invalidates the iterator by removing its element from the components vector.
> 
> For some reason the iterator contains still the previous pointer
> and therefore we try to delete the same pointer twice.
> 
> 
> Attached patch tries to change the loop assuming that the
> deleted element will always be removed inside the delete operation.
> 
> With that patch I do not get any segfault, but still tests
> fail for some reason.
> 
> 
> Kind regards,
> Bernhard
> 
> 
> 
> 
> # Here we crash:
> 
> (gdb) bt
> #0  0x0061 in ?? ()
> #1  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
> (this=this@entry=0x56d98330) at 
> ./modeling/libraries/pml/MultiComponent.cpp:50
> #2  0x7fffeb32c11f in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:41
> #3  0x7fffeb32c149 in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:38
> #4  0x7fffeb32ce3a in PhysicalModel::clear 
> (this=this@entry=0x55705ef0) at 
> ./modeling/libraries/pml/PhysicalModel.cpp:99
> #5  0x7fffeb32cf17 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
> __in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:68
> #6  0x7fffeb32cf59 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
> __in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:67
> #7  0x7fffeb317a3d in PMLComponent::~PMLComponent (this=0x55660a00, 
> __in_chrg=) at 
> ./modeling/components/pmlcomponent/PMLComponent.cpp:96
> #8  0x7fffeb3185a9 in PMLComponent::~PMLComponent (this=0x55660a00, 
> __in_chrg=) at 
> ./modeling/components/pmlcomponent/PMLComponent.cpp:93
> #9  0x77ec4ad7 in camitk::Application::close(camitk::Component*) () 
> at ./sdk/libraries/core/application/Application.cpp:623
> #10 0xbc5c in main () at 
> ./sdk/applications/testcomponents/main.cpp:204
> #11 0x76e99b17 in __libc_start_main (main=0xb080 , 
> argc=9, argv=0x7fffe398, init=, fini=, 
> rtld_fini=, stack_end=0x7fffe388) at 
> ../csu/libc-start.c:310
> #12 0xc35a in _start () at 
> ./sdk/applications/testcomponents/main.cpp:136
> 
> (gdb) list -
> 46
> 47  // -- deleteAllSubComponents -
> 48  void MultiComponent::deleteAllSubComponents() {
> 49  for (auto& component : components) {
> 50  delete component;
> 51  }
> 52  components.clear();
> 53  }
> 
> 
> 
> 
> # Here the pointer being deleted is removed from the components vector
> # and that way invalidating the iterator.
> 
> (gdb) bt
> #0  MultiComponent::removeSubComponent (c=0x579d70f0, 
> this=0x56d98330) at ./modeling/libraries/pml/MultiComponent.h:134
> #1  Component::removeFromParents() () at 
> ./modeling/libraries/pml/Component.cpp:60
> #2  0x7fffeb32c127 in MultiComponent::~MultiComponent 
> (this=0x579d70f0, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:44
> #3  0x7fffeb32c149 in MultiComponent::~MultiComponent 
> (this=0x579d70f0, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:38
> #4  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
> (this=this@entry=0x56d98330) at 
> ./modeling/libraries/pml/MultiComponent.cpp:50
> #5  0x7fffeb32c11f in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:41
> #6  0x7fffeb32c149 in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:38
> #7  0x7fffeb32ce3a in PhysicalModel::clear 
> (this=this@entry=0x55705ef0) at 
> ./modeling/libraries/pml/PhysicalModel.cpp:99
> ...
> 
> (gdb) list modeling/libraries/pml/MultiComponent.h:134
> 129 }
> 130 inline void MultiComponent::removeSubComponent(Component* c) {
> 131 auto it = std::find(components.begin(), components.end(), c);
> 132 if (it != components.end()) {
> 133 components.erase(it);
> 134 c->removeParentMultiComponent(this);
> 135 }
> 136 }

> From 52f172e553ebddf068b8e35601da5eefd295cf3d Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
> Date: Thu, 20 Sep 2018 17:42:14 +0200
> Subject: [PATCH] Make loop safe for removal of elements.
> 
> Bug-Debian:

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

2018-09-20 Thread Bernhard Übelacker 
Hello all,
I tried to reproduce this issue.

Unfortunately I never get the "(SEGFAULT)" output for all tests,
just "(Failed)" for most. But some do really segfault in my amd64 VM.

I think the segfaults are caused by the line "delete component;", that
invalidates the iterator by removing its element from the components vector.

For some reason the iterator contains still the previous pointer
and therefore we try to delete the same pointer twice.


Attached patch tries to change the loop assuming that the
deleted element will always be removed inside the delete operation.

With that patch I do not get any segfault, but still tests
fail for some reason.


Kind regards,
Bernhard




# Here we crash:

(gdb) bt
#0  0x0061 in ?? ()
#1  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
(this=this@entry=0x56d98330) at 
./modeling/libraries/pml/MultiComponent.cpp:50
#2  0x7fffeb32c11f in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:41
#3  0x7fffeb32c149 in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:38
#4  0x7fffeb32ce3a in PhysicalModel::clear (this=this@entry=0x55705ef0) 
at ./modeling/libraries/pml/PhysicalModel.cpp:99
#5  0x7fffeb32cf17 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
__in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:68
#6  0x7fffeb32cf59 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
__in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:67
#7  0x7fffeb317a3d in PMLComponent::~PMLComponent (this=0x55660a00, 
__in_chrg=) at 
./modeling/components/pmlcomponent/PMLComponent.cpp:96
#8  0x7fffeb3185a9 in PMLComponent::~PMLComponent (this=0x55660a00, 
__in_chrg=) at 
./modeling/components/pmlcomponent/PMLComponent.cpp:93
#9  0x77ec4ad7 in camitk::Application::close(camitk::Component*) () at 
./sdk/libraries/core/application/Application.cpp:623
#10 0xbc5c in main () at 
./sdk/applications/testcomponents/main.cpp:204
#11 0x76e99b17 in __libc_start_main (main=0xb080 , 
argc=9, argv=0x7fffe398, init=, fini=, 
rtld_fini=, stack_end=0x7fffe388) at ../csu/libc-start.c:310
#12 0xc35a in _start () at 
./sdk/applications/testcomponents/main.cpp:136

(gdb) list -
46
47  // -- deleteAllSubComponents -
48  void MultiComponent::deleteAllSubComponents() {
49  for (auto& component : components) {
50  delete component;
51  }
52  components.clear();
53  }




# Here the pointer being deleted is removed from the components vector
# and that way invalidating the iterator.

(gdb) bt
#0  MultiComponent::removeSubComponent (c=0x579d70f0, this=0x56d98330) 
at ./modeling/libraries/pml/MultiComponent.h:134
#1  Component::removeFromParents() () at 
./modeling/libraries/pml/Component.cpp:60
#2  0x7fffeb32c127 in MultiComponent::~MultiComponent (this=0x579d70f0, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:44
#3  0x7fffeb32c149 in MultiComponent::~MultiComponent (this=0x579d70f0, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:38
#4  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
(this=this@entry=0x56d98330) at 
./modeling/libraries/pml/MultiComponent.cpp:50
#5  0x7fffeb32c11f in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:41
#6  0x7fffeb32c149 in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:38
#7  0x7fffeb32ce3a in PhysicalModel::clear (this=this@entry=0x55705ef0) 
at ./modeling/libraries/pml/PhysicalModel.cpp:99
...

(gdb) list modeling/libraries/pml/MultiComponent.h:134
129 }
130 inline void MultiComponent::removeSubComponent(Component* c) {
131 auto it = std::find(components.begin(), components.end(), c);
132 if (it != components.end()) {
133 components.erase(it);
134 c->removeParentMultiComponent(this);
135 }
136 }
From 52f172e553ebddf068b8e35601da5eefd295cf3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Thu, 20 Sep 2018 17:42:14 +0200
Subject: [PATCH] Make loop safe for removal of elements.

Bug-Debian: https://bugs.debian.org/909120
Forwarded: no
Last-Update: 2018-09-20

---
 modeling/libraries/pml/MultiComponent.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/modeling/libraries/pml/MultiComponent.cpp b/modeling/libraries/pml/MultiComponent.cpp
index 5a3a9ab..3f32d7b 100644
--- a/modeling/libraries/pml/MultiComponent.cpp
+++ b/modeling/libraries/pml/MultiComponent.cpp
@@ -46,8 +46,10 @@ MultiComponent::~MultiComponent() {
 
 // -- deleteAllSubComponents -
 void