On 12/20/2016 02:21 AM, Norbert Thiebaud wrote:
Analysis of sampling idlc (pid 3535) every 1 millisecond
Process: idlc [3535]
Path:
/Users/tdf/lode/jenkins/workspace/lo_gerrit/Config/macosx_clang_dbgutil/instdir/LibreOffice5.4_SDK/bin/idlc
Load Address: 0x108408000
Identifier: idlc
Version: 0
Code Type: X86-64
Parent Process: idlc [3503]
Date/Time: 2016-12-19 19:05:16.839 -0600
OS Version: Mac OS X 10.9.5 (13F1077)
Report Version: 7
Call graph:
2391 Thread_117354590: Main Thread DispatchQueue_<multiple>
2391 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff93ae5fc9]
2391 _pthread_start (in libsystem_pthread.dylib) + 137
[0x7fff93ae172a]
2391 _pthread_body (in libsystem_pthread.dylib) + 138
[0x7fff93ae1899]
2391 osl_thread_start_Impl(void*) (in libuno_sal.dylib.3)
+ 335 [0x1085c352f] thread.cxx:240
2391 ChildStatusProc(void*) (in libuno_sal.dylib.3) +
8863 [0x1085ab35f] process.cxx:208
2391 std::__1::basic_ostream<char,
std::__1::char_traits<char> >&
std::__1::operator<<<std::__1::char_traits<char>
(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char
const*) (in libuno_sal.dylib.3) + 68 [0x10852e674] ostream:882
idlc spawns a child process exec'ing ucpp; this backtrace is apparently
from that child process, doing
SAL_INFO("sal.osl", "ChildStatusProc : starting " <<
data.m_pszArgs[0]);
(sal/osl/unx/process.cxx:208) before calling execv. Why that
std::ostringstream operator << would go into an endless loop allocating
(ever more?) memory (if that is what that "Analysis of sampling idlc"
claims), I have no idea. Would need further debugging.
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
