Issue 111271 - Mac OS X: crash during shutdown, __tcf_2 on stack
Summary: Mac OS X: crash during shutdown, __tcf_2 on stack
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: DEV300m77
Hardware: Mac Mac OS X, all
: P2 Trivial (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2010-04-30 07:47 UTC by Stephan Bergmann
Modified: 2017-05-20 11:33 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2010-04-30 07:47:32 UTC
Building smoketestoo_native of DEV300_m77 based CWS sb120 on unxmacxi non-pro
once failed with a crashing soffice, build output

Test name: (anonymous namespace)::Test::test
tearDown() failed
- equality assertion failed
- Expected: 0
- Actual  : 4294967295

Failures !!!
Run: 1   Failure total: 1   Failures: 1   Errors: 0
dmake:  Error code 1, while making 'cpptest'

and a new soffice instance starting up (with the first start wizard, as
smoketestoo_native calls soffice with -nofirststartwizard), even though
smoketestoo_native calls soffice -norestore.  Thanks to ulimit -c unlimited, a
/cores/core.59712 was generated, which does not look to helpful though:

(gdb) info threads
  15 core thread 14  0x9630a688 in objc_msgSend ()
  14 core thread 13  0x96e54b96 in recvfrom$NOCANCEL$UNIX2003 ()
  13 core thread 12  0x96e0c2ae in semaphore_wait_signal_trap ()
  12 core thread 11  0x96e7918e in wait4 ()
  11 core thread 10  0x96e0c266 in mach_msg_trap ()
  10 core thread 9  0x96e0c266 in mach_msg_trap ()
  9 core thread 8  0x96e0c266 in mach_msg_trap ()
  8 core thread 7  0x96e0c266 in mach_msg_trap ()
  7 core thread 6  0x96e0c2a2 in semaphore_wait_trap ()
  6 core thread 5  0x96e0c266 in mach_msg_trap ()
  5 core thread 4  0x96e0c266 in mach_msg_trap ()
  4 core thread 3  0x96e0c266 in mach_msg_trap ()
  3 core thread 2  0x96e0c266 in mach_msg_trap ()
  2 core thread 1  0x96e0c2c6 in semaphore_timedwait_signal_trap ()
* 1 core thread 0  0x2a75a7f6 in __tcf_2 ()
(gdb) thread 1
[Switching to thread 1 (core thread 0)]
0x2a75a7f6 in __tcf_2 ()
(gdb) where
#0  0x2a75a7f6 in __tcf_2 ()
#1  0x96e34d9c in __cxa_finalize ()
#2  0x96e34c90 in exit ()
#3  0x96f7927a in NSApplicationMain ()
#4  0x01f3ce0e in ImplSVMainHook ()
#5  0x01c592cb in SVMain ()
#6  0x000d5f2c in soffice_main ()
#7  0x00002f0e in main ()
(gdb) info sharedlibrary 0x2a75a7f6
217 libbf_frmmxi.dylib            - 0x2a6ce000        dyld Y Y
at 0x2a6ce000 (offset 0x2a6ce000)
                                                  (objfile is) [memory object
at 0x2a6ce000]
(gdb) disas 0x2a75a7f6
Dump of assembler code for function __tcf_2:
0x2a75a7f6 <__tcf_2+0>: push   %ebp
0x2a75a7f7 <__tcf_2+1>: mov    %esp,%ebp
0x2a75a7f9 <__tcf_2+3>: call   0x2a7bed64 <>
0x2a75a7fe <__tcf_2+8>: mov    0xf90f2(%ecx),%eax
0x2a75a804 <__tcf_2+14>:        mov    %eax,0x8(%ebp)
0x2a75a807 <__tcf_2+17>:        pop    %ebp
0x2a75a808 <__tcf_2+18>:        jmp    0x2a85405f <dyld_stub_rtl_uString_release>
0x2a75a80d <__tcf_2+23>:        nop
End of assembler dump.
(gdb) info reg
eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0x96e34cb6       -1763488586
esp            0xbfffa6fc       0xbfffa6fc
ebp            0xbfffa758       0xbfffa758
esi            0x437e5a8        70772136
edi            0x19     25
eip            0x2a75a7f6       0x2a75a7f6 <__tcf_2>
eflags         0x10246  66118
cs             0x17     23
ss             0x1f     31
ds             0x1f     31
es             0x1f     31
fs             0x0      0
gs             0x37     55
(gdb) x/16b 0xbfffa6f0
0xbfffa6f0:     0xa8    0xe5    0x37    0x04    0x19    0x00    0x00    0x00
0xbfffa6f8:     0x58    0xa7    0xff    0xbf    0x9c    0x4d    0xe3    0x96

(I had also occasionally experienced similar scenarios during shutdown when
running the unoapi tests in the same setting, also with __tcf_2 on top of the
crashing(?) stack, but that symbol belonging to various libraries, not
necessarily libbf_frmmxi.dylib.)
Comment 1 philipp.lohmann 2010-04-30 12:57:53 UTC
No idea, only that __tcf_ seem to be destructors for static objects; see e.g.
this bug report

That issue itself is of course not the problem here; might be loading/unloading

Me no likey static destructors :-(
Comment 2 Stephan Bergmann 2010-07-14 16:01:13 UTC
raising prio, as this affects build stability (see
<> for
enabling subsequenttests on buildbots)
Comment 3 Stephan Bergmann 2010-09-17 14:19:53 UTC
Comment 4 Marcus 2017-05-20 11:33:12 UTC
Reset assigne to the default "".