Hi,
On 02/20/2015 05:08 PM, Clarkson, Matt wrote:
Hi Sascha et. al.
As an update, in the unit test i mention here:
https://github.com/MattClarkson/MITK/commit/2514bfad99ea3bc627362e235104438550231d8b
Thanks for providing the code with the unit test, this helped a lot.
I am not sure if this was just for demonstrating the core problem, but
one general issue with the new unit test in that branch is the following:
IO libraries like MitkDiffusionIO are meant to be auto-loaded. Auto-load
modules reside in sub-directories and for the sake of simplicity
should/must not be linked against. Typically, such libraries do not
provide any public symbols and just register "stuff".
Creating a test driver for an auto-load module using the MITK CMake
macros leads to a linker dependency from the test driver executable to
the auto-load module. Usually, no symbols are used from that module but
depending on the linker involved the link-time dependendy might be kept
or removed. This could lead to PATH (Windows) or DYLD_LIBRARY_PATH
(MacOS) issues, depending on the overall set-up.
to get it to work, I first had to add US_INITIALIZE_MODULE. In
addition to this, I had to set my DYLD_LIBRARY_PATH to include all
ITK, VTK, GDCM libraries. I believe this is due to MitkCore itself
requiring these libraries, and we are building our code and linking
against libraries kept within the install folder, which don’t have the
RPATHs compiled in.
Regarding DYLD_LIBRARY_PATH: In the recent MITK master and its
super-build set-up, we tried hard to configure external projects like
ITK, VTK, GDCM, etc. with correct (relative) install names and rpaths
for the install-tree. For MITK, we do not need to set DYLD_LIBRARY_PATH.
Are you maybe building these external projects yourself without custom
install name and rpath tweaks?
Also, I noticed that there were two readers for .trk files registered.
Would you expect this to be the case?
No, I would expect only one being registered. This could be a follow-up
bug due to the other issues involved.
So, does every unit test, and every executable need to have
US_INITIALIZE_MODULE? We have many many command line apps. Do they all
need one if they want to do IO via MitkCore?
No, definitely not. In your case, you are using MITK API which relies on
a special function default argument (us::GetModuleContext()) which in
turn needs US_INITIALIZE_MODULE to function properly. So you would need
US_INITIALIZE_MODULE only when using specific MITK classes.
The crash is definitely a bug in MITK (CppMicroServices), described in
http://bugs.mitk.org/show_bug.cgi?id=18872 . I will fix this probably
today and there will be a log message if you are using API which needs a
US_INITIALIZE_MODULE macro but you don't provide one.
So, once I got the above MITK based unit test to work, I similarly got
my unit test to work for our NifTK code, so its the same problem. So,
maybe I just need to understand more about what is required for
getting the microservices to run, when I am running a non GUI
application, or a 3rd party applications. Im also surprised that most
MITK unit tests don’t require this… I only see US_INITIALIZE_MODULE in
mitkOclResourceServiceTest.cpp (as of 2014.10 release).
I guess most MITK unit tests don't use that special MITK API subset yet.
I will just add a US_INITIALIZE_MODULE call to each test driver
generated via the standard MITK CMake macros.
Thanks for all the debugging,
Sascha
Thanks as always.
Matt
On 16 Feb 2015, at 20:19, Clarkson, Matt <[email protected]
<mailto:[email protected]>> wrote:
Hi Sascha,
I just did this unit test with a fresh clone of MITK.
https://github.com/MattClarkson/MITK/commit/71aea5ebd1a00b9ae442fba256771aab40d70583
Same problem occurs when trying to write a unit test load load one of
the diffusion imaging file formats.
Any idea?
Its entirely possible that I’m doing something wrong. i.e. the Unit
test needs to have other services up and running at the time you ask
the File Reader Registry to return something.
But when I was writing my unit test, I based it on an existing
mitk::PointSet reader unit test, and did that same sort of thing. So
I can’t see anything that Im meant to add.
i.e. I dont know what I dont know.
So, that said, the provided unit test seg-faults in an identical (to
my eyes) way as previously described.
Hope that helps.
Thanks
Matt
On 13 Feb 2015, at 14:01, Sascha Zelzer <[email protected]
<mailto:[email protected]>> wrote:
Okay, this is bad news.
Is the stack trace still the same (with the CoreServicePointer
changes) for the crash you are experiencing?
Thanks,
Sascha
On 02/11/2015 04:14 PM, Miklos Espak wrote:
I am afraid, the clean build did not solve the problem. Moreover,
this is not clang-specific, our unit test crashes on Linux as well,
with gcc.
It seems to me that the problem is the order in which modules are
initialised and accessed.
Miklos
On 10 February 2015 at 21:11, Sascha Zelzer
<[email protected] <mailto:[email protected]>>
wrote:
That sould do it. At least it fixed similar issues for me when
building with clang on Fedora...
On 02/10/2015 09:59 PM, Clarkson, Matt wrote:
Hi there,
I pulled that branch, and re-built MITK, and rebuilt our code,
and can’t see any difference.
I also changed into the source folder to check that I had got
the updated file and I have.
Do I need a full clean build?
M
On 10 Feb 2015, at 17:45, Sascha Zelzer
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
I pushed branch
bug-18731-hide-template-definitions-with-special-default-arguments
based on the 2014.10 release. Could you give it a try please
and report back?
Thanks,
Sascha
On 02/09/2015 09:00 PM, Clarkson, Matt wrote:
Currently, Mac OSX 10.9.5 and
/usr/bin/c++ --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
Thanks
M
On 9 Feb 2015, at 19:53, Sascha Zelzer
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
before going into details, on which OS and compiler are you
getting this?
Thanks,
Sascha
On 02/09/2015 01:23 PM, Clarkson, Matt wrote:
Hi there,
Im trying to change one of our file reader/writes to the
new framework.
I have code like this:
mitk::FileReaderRegistry readerRegistry;
std::vector<mitk::IFileReader*> readers =
readerRegistry.GetReaders(mitk::FileReaderRegistry::GetMimeTypeForFile("4x4"));
MITK_TEST_CONDITION_REQUIRED(readers.size() == 1, "Testing for 1
registered readers”)
that fails (seg fault) on call to
readerRegistry.GetReaders(..)
But the GUI program successfully loads/saves these files.
The unit test is for our own file type in our own module.
I based my code on the mitkPointSetReaderTest.cpp. In the
diffusion modules there are examples of new file
readers/writers, but no unit tests that i could find that
use the FileReaderRegistry. So, I must be missing
something in my unit test, failing to instantiate some
class/service. Is it possible that the PointSetReaderTest
works because the mitkCoreActivator is instantiating a lot
of stuff, whereas my unit test is not? i.e. I dont know
what Im supposed to look for.
Can anyone help? See 2 screenshots of stack trace.
Thanks
Matt
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel
Website,
sponsored by Intel and developed in partnership with Slashdot
Media, is your
hub for all things parallel software development, from weekly
thought
leadership blogs to news, videos, case studies, tutorials and
more. Take a
look and join the conversation now.
http://goparallel.sourceforge.net/
<http://goparallel.sourceforge.net/>
_______________________________________________
mitk-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
