Issue 106355 - Mac OS X: crash reporting does not work in soffice spawned after crash
Summary: Mac OS X: crash reporting does not work in soffice spawned after crash
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: OOO320m2
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: thorsten.martens
QA Contact: issues@porting
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-27 16:35 UTC by Stephan Bergmann
Modified: 2010-07-26 19:47 UTC (History)
5 users (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2009-10-27 16:35:47 UTC 
When upon a crash on Mac OS X DoRestart in desktop/source/app/app.cxx forks and
execs a new instance of the soffice process, this call is made from within the
signal handler, with many signals blocked (InitSignal in sal/osl/unx/signal.c
does sigfillset(&sa_mask) and does not include SA_NODEFER in sa_flags).  The
signal mask is inherited by the new process, so signal handling (and thus crash
reporting) will not work in the new process.

A fix might be to adjust the signal mask at the end of InitSignal in
sal/osl/unx/signal.c:

+ sigset_t unset;
+ if (sigemptyset(&unset) < 0 ||
+     pthread_sigmask(SIG_SETMASK, &unset, NULL) < 0)
+ {
+     OSL_TRACE("sigemptyset or pthread_sigmask failed");
+ }
+
  return sal_True;
Comment 1 Stephan Bergmann 2009-10-27 16:36:27 UTC 
.
Comment 2 Stephan Bergmann 2010-01-20 13:55:14 UTC 
fixed as <http://hg.services.openoffice.org/cws/sb119/rev/12a7f6de6dc5>
(virtually identical to the above patch)
Comment 3 hdu@apache.org 2010-01-21 08:45:41 UTC 
Thanks! IMHO this fix deserves to get into OOo321 too.
Comment 4 Stephan Bergmann 2010-01-21 09:10:14 UTC 
@hdu:  This was probably broken for a very long time (maybe since the
beginnings).  Not sure it qualifies for OOo 3.2.1, but feel free to lobby.
Comment 5 hdu@apache.org 2010-01-21 10:11:03 UTC 
Yup, crash reporting on OOo Aqua had problems for a long time. Often no automated report got created, 
sometimes the backtraces from the Apple crash reporter or the Java crash reporter provided some clues. A 
working OOoAqua specific crash reporting infrastructure would be so much better: it has access to the 
matching unstripped binaries so it can create good backtraces also in product builds.

@release managers: the fix here solves the probable root cause for many crash reporting issues on 
OOoAqua which severly hampered working on OOoAqua crashes. Please support my bidding for an ASAP 
target
Comment 6 Stephan Bergmann 2010-01-21 10:54:00 UTC 
@hdu:  Please note that apart from this issue (breaking crash handling in
soffice instance automatically restarted after crash) there is also a second
issue on Mac OS X, namely that crash handling becomes unreliable as soon as an
in-process JVM is created (i.e., as soon as anything implemented in Java is used
within OOo).  It is unclear to me whether this fix would susbstantially increase
the number of successfully received crash reports for Mac OS X.
Comment 7 hdu@apache.org 2010-01-21 11:06:18 UTC 
Ah, ok. So the problems with JVM-crash reporting have a different root cause. Nevertheless crash 
reporting failing for the other scenarios has troubled the OOoAqua port for a long time so I'm very happy 
that these problems will be gone soon. The sooner the better...
Comment 8 Stephan Bergmann 2010-02-08 10:04:55 UTC 
@tm: please verify (see the menu item trick in the description of issue 108411
for a reliable mechanism to let OOo crash)
Comment 9 thorsten.martens 2010-02-18 12:58:11 UTC 
checked and verified in cws sb119 -> OK !
Comment 10 Martin Hollmichel 2010-07-26 19:47:44 UTC 
close issue