Hi Sascha, hope you are well. If you re-read the email below, I was under them impression that I still have a problem with the Mac build.
However, things have slightly changed since the last email on this subject. If I go to Finder, and run the application by clicking on the ExtApp icon it works. If I go to MITK-build/MITK-build/bin and run ./ExtApp/Contents/MacOS/ExtApp it works If I go to MITK-build/MITK-build and run ./ExtApp/Contents/MacOS/ExtApp it crashes as below. Is this "expected behaviour". Should I stop worrying about this, and just ignore it? Or is it a real issue? Thanks Matt On 25 Jun 2011, at 16:07, Sascha Zelzer wrote: > Hi Matt, > > Thanks again for your "debugging". Our Mac guy confirms your issues but it > seems that it is somehow related to the "CMake Makefile Generator". He is > using mainly XCode projects, where the errors do not seem to appear. We will > investigate it further. > > Thanks a lot, > > Sascha > > On 06/20/2011 11:09 PM, Matt Clarkson wrote: >> Hi Sascha, >> >> Well, I was about to write "I still have a problem here", but then I found >> something interesting. It may in one sense be just a usage question, but I >> think there is still something that needs fixing. >> >> If delete ~/.CoreApp and ~/.ExtApp, and then I run CoreApp.app or ExtApp.app >> by double clicking on them in Finder, they both give SIGSEGV, with a stack >> trace like this: >> >> Exception Type: EXC_BAD_ACCESS (SIGSEGV) >> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 >> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >> >> Thread 0 Crashed: Dispatch queue: com.apple.main-thread >> 0 ...TKPluginFramework.0.1.dylib 0x000000010967d19e >> ctkPluginContext::d_func() + 32 (ctkPluginContext.h:102) >> 1 ...TKPluginFramework.0.1.dylib 0x000000010967c856 >> ctkPluginContext::getServiceReference(QString const&) + 208 >> (ctkPluginContext.cpp:159) >> 2 liborg_blueberry_osgi.dylib 0x00000001004ae100 ctkServiceReference >> ctkPluginContext::getServiceReference<berry::IExtensionPointService>() + 388 >> (ctkPluginContext.h:384) >> 3 liborg_blueberry_osgi.dylib 0x00000001004ae554 >> berry::IExtensionPointService::Pointer >> berry::ServiceRegistry::GetServiceById<berry::IExtensionPointService>(std::string >> const&) + 218 (berryServiceRegistry.txx:49) >> 4 liborg_blueberry_osgi.dylib 0x00000001004a7051 >> berry::InternalPlatform::GetExtensionPointService() + 69 >> (berryInternalPlatform.cpp:332) >> 5 liborg_blueberry_osgi.dylib 0x0000000100484c71 >> berry::Starter::Run(int&, char**, Poco::Util::AbstractConfiguration*) + 261 >> (berryStarter.cpp:62) >> 6 0x0000000100020b39 main + 1205 >> (ExtApp.cpp:96) >> 7 0x0000000100020540 start + 52 >> >> If in the terminal window, I do: >> >> cd MITK-build/MITK-build/bin >> ./CoreApp.app/Contents/MacOS/CoreApp >> ./ExtApp.app/Contents/MacOS/ExtApp >> >> these both also give SIGSEGV. >> >> If in the terminal window I do: >> >> cd MITK-build/MITK-build >> ./bin/CoreApp.app/Contents/MacOS/CoreApp >> ./bin/ExtApp.app/Contents/MacOS/ExtApp >> >> Then both applications run. So, by starting on the command line in the >> MITK-build directory rather than from within the bin directory, the >> applications do start up. Furthermore, i was running in the debugger, and >> the CoreApp program was working. So, I was stuck, thinking that the >> application failed on the command line, when run without the debugger, but >> worked within the debugger. At first I thought this was a timing issue, or a >> race condition. Then I realised that the debugger had a different working >> directory. >> >> So, if in the debugger, the "working directory" is the >> MITK-build/MITK-build/bin, you get a segmentation fault. >> But if in the debugger, the "working directory" is any other folder such as >> MITK-build/MITK-build/, you do not get a segmentation fault. >> >> The reason for the segmentation fault is because in >> ctkPluginContext::getServiceReference(const QString& clazz), the "this" >> pointer becomes NULL, so Q_D(ctkPluginContext) fails due to the macro >> accessing "this" which is NULL. >> >> Further up the stack, it's the call in >> InternalPlatform::GetExtensionPointService() to >> m_ServiceRegistry->GetServiceById<IExtensionPointService>(IExtensionPointService::SERVICE_ID). >> So, I don't understand why this is dependent on which directory you run the >> application from? >> >> Any idea? >> >> Thanks as always. >> >> Matt >> > ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
