Profiling LibreOfficeDev.app on OSX with XCode Instruments, Sudden Termination, and Unprotected File System Access

[Alexander Thurgood]

Hi all,

So, seeing as I don't know how to code in anything remotely useful to
the project, and at present, I don't have the time to learn, I've
started playing around with a tool that Apple provides called
Instruments.app, which is supplied as part of the XCode developer suite.

One of the profiles is "Sudden Termination". This registers all calls to
terminate the app (for the duration of time that the app is profiled)
and associates this to the function call stack and unprotected file
system access. In the words of Apple :

http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/MonitoringOSXAppBehaviors/MonitoringOSXAppBehaviors.html


"Preventing your app from suddenly terminating should be a high priority
when creating your app because no person has enjoys using an app that
has a tendency to shut down while in use. Often, sudden termination is
caused when the file system is accessed and the system is not protected
by calls designed to prevent the sudden termination of the app."

Note that I am not in a position to judge whether this is accurate or
even relevant for LO on OSX, or for LO as a whole, but personally, I
guess I wouldn't feel too happy about an app that thinks it can open
files in an unprotected manner if a mechanism for protecting that acess
exists.



Be that as it may, would it be of interest if I posted some of my
findings here, or somewhere else (e.g. the wiki ?)



For starters, I did the following :

Started my development build of LibreOfficeDev and then attached it to
Instruments. Started a profile with "sudden termination" and then
clicked on the StartCenter button to create a new, empty Writer document.

The following is what transpired from that operation flagged as
Unprotected File System Access :

   0 libsystem_kernel.dylib mkdir
   1 libuno_sal.dylib.3 create_dir_recursively_(unsigned short*, void
(*)(void*, _rtl_uString*), void*)
   2 libuno_sal.dylib.3 osl_createDirectoryPath
   3 configmgr.uno.dylib configmgr::writeModFile(configmgr::Components&,
rtl::OUString const&, configmgr::Data const&)
   4 configmgr.uno.dylib configmgr::Components::WriteThread::execute()
   5 libuno_salhelpergcc3.dylib.3 salhelper::Thread::run()
   6 libuno_salhelpergcc3.dylib.3 threadFunc
   7 libuno_sal.dylib.3 osl_thread_start_Impl


followed by osl-openfile (O_RDWR O_NONBLOCK O_CREAT O_EXCL O_EXLOCK) :

   0 libsystem_kernel.dylib __open
   1 libuno_sal.dylib.3 osl_openFile
   2 libuno_sal.dylib.3 osl_createTempFile
   3 configmgr.uno.dylib configmgr::writeModFile(configmgr::Components&,
rtl::OUString const&, configmgr::Data const&)
   4 configmgr.uno.dylib configmgr::Components::WriteThread::execute()
   5 libuno_salhelpergcc3.dylib.3 salhelper::Thread::run()
   6 libuno_salhelpergcc3.dylib.3 threadFunc
   7 libuno_sal.dylib.3 osl_thread_start_Impl


and then a series of pwrite functions with varying frames, but all
causing unprotected file system access :

  0 libsystem_kernel.dylib __pwrite
   1 libuno_sal.dylib.3 FileHandle_Impl::syncFile()
   2 libuno_sal.dylib.3 FileHandle_Impl::writeFileAt(long long, void
const*, unsigned long, unsigned long long*)
   3 libuno_sal.dylib.3 osl_writeFile
   4 configmgr.uno.dylib configmgr::(anonymous
namespace)::writeData(void*, char const*, long)
   5 configmgr.uno.dylib configmgr::(anonymous
namespace)::writeAttributeValue(void*, rtl::OUString const&)
   6 configmgr.uno.dylib configmgr::(anonymous
namespace)::writeModifications(configmgr::Components&, void*,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
configmgr::Modifications::Node const&)
   7 configmgr.uno.dylib configmgr::(anonymous
namespace)::writeModifications(configmgr::Components&, void*,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
configmgr::Modifications::Node const&)
   8 configmgr.uno.dylib configmgr::(anonymous
namespace)::writeModifications(configmgr::Components&, void*,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
configmgr::Modifications::Node const&)
   9 configmgr.uno.dylib configmgr::(anonymous
namespace)::writeModifications(configmgr::Components&, void*,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
rtl::OUString const&, rtl::Reference<configmgr::Node> const&,
configmgr::Modifications::Node const&)
  10 configmgr.uno.dylib configmgr::writeModFile(configmgr::Components&,
rtl::OUString const&, configmgr::Data const&)
  11 configmgr.uno.dylib configmgr::Components::WriteThread::execute()
  12 libuno_salhelpergcc3.dylib.3 salhelper::Thread::run()
  13 libuno_salhelpergcc3.dylib.3 threadFunc
  14 libuno_sal.dylib.3 osl_thread_start_Impl


Is this normal behaviour ? Is it of any use to anyone here ?


Alex