Hi Taylor,
thanks for reporting that issue. There might be some thread safety
problems with the mbilog::BackendCout class which is used as dummy
backend when no other logging backend is available. However, in MITK
usually the MITK logging backend is used (class mitk::LoggingBackend,
files mitkLog.h and mitkLog.cpp in the core). This logging backend
should be tread safe, there even is a unit test to assure this
(mitkLogTest.cpp). When using the MITK workbench the
mitk::LoggingBackend is registerd in the plugin activator of
org.mitk.core.services. Do you use the MITK workbench, or do you have
your own application?
If you register the backend by yourself I would propose to simply use
the static method
mitk::LoggingBackend::Register()
to register the MITK logging backend. Then you can use MITK_INFO,
MITK_WARN, etc. to log your messages.
Anyway there are two possible bugs which we might want to file because
of your problems:
1. There are logging messages before registration of the MITK logging
backend in org.mitk.core.services which are not thread safe because of (2).
2. The backend mbilog::BackendCout is not thread safe.
Do you agree?
Regards,
Alfred
Am 14.03.2014 03:58, schrieb Taylor Braun-Jones:
> I'm merging the latest updates from MITK master into my local branch
> and seeing an mbilog thread safety issue that I had encountered
> before, but was able to work around by always making sure to register
> a backend at the beginning of main before any threads are spawned:
>
> mbilog::RegisterBackend(new mbilog::BackendCout());
>
> Now, however, with the latest MITK changes I see that some mbilog
> output is written before main even runs (lines like "In
> AutoLoadModulesFromPath at ... Auto-loading module ...") so this block
> of code in mbilog::DistributeToBackends generates a "dummy backend":
>
> static mbilog::BackendCout* dummyBackend = NULL;
>
> if(backends.empty() && (dummyBackend == NULL))
> {
> dummyBackend = new mbilog::BackendCout();
> dummyBackend->SetFull(false);
> RegisterBackend(dummyBackend);
> }
>
> Then the first mbilog output that I write is comes at the beginning of
> an OMP parallelized for loop and more than one (usually) hits the next
> block of code in the same mbilog::RegisterBackend method:
>
> else if((backends.size()>1) && (dummyBackend != NULL))
> {
> //if there was added another backend remove the dummy backend and
> delete it
> UnregisterBackend(dummyBackend);
> delete dummyBackend;
> dummyBackend = NULL;
> }
>
> Since there is no protection anywhere on dummyBackend I get glibc
> double free errors. (backends should also be protected)
>
> I know it's a bit old, but these bug squashing slides indicate that
> logging in MITK is thread safe:
> http://www.mitk.org/BugSquashingSeminars?action=AttachFile&do=view&target=logging.pdf
>
> <http://www.mitk.org/BugSquashingSeminars?action=AttachFile&do=view&target=logging.pdf>
>
> Have things changed? I could put in another workaround for this
> problem, but I'd rather resolve it properly this time.
>
> Thanks for the help!
>
> Taylor
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
