diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2013-08-23 12:03:45 +0200 |
---|---|---|
committer | Fridrich Strba <fridrich@documentfoundation.org> | 2013-08-26 08:40:25 +0000 |
commit | 8ea056e716d87c07343adc8532ce6f265de13624 (patch) | |
tree | f1e148b60ea0c904145dc0d51f06e37910f028d4 /vcl/unx/gtk/app/gtkdata.cxx | |
parent | 587b8034d3b53ffd28b80261683713ae0b1bab47 (diff) |
rhbz#1000150: Do not call exit upon XIOError
...as done in _XIOError (libX11-1.6.0/src/XlibInt.c) after calling the XIOError
handler function (either the one supplied with XSetIOErrorHandler or
_XDefaultIOError), as that calls the atexit handlers, which can wreak havoc in
unrelated threads that happen to be running in parallel, leading to arbitrary
crashes. So avoid that by always calling _exit already from our XIOError
handler.
The old code was careful to /not/ call _exit when the XIOError happened on any
thread but the main one, but I do not see the sense of that---after all,
_XIOError will inevitably call exit afterwards, so this cannot be a way to
"ignore" XIOErrors from special threads (that are set up say for the sole
purpose of trying out "known-shaky" activities without affecting the stability
of the whole process). And findings like comment 12 to
<https://bugzilla.redhat.com/show_bug.cgi?id=831628#c12> "[abrt]
libreoffice-core-3.5.4.2-1.fc17: ICEConnectionWorker thread still running during
exit" ("it is very likely that this is not a normal exit from reaching the end
of main, but rather some explicit call to exit from some error handling code")
make it clear that we apparenly do suffer from such calls to _XIOError -> exit
on non-main threads.
I have no idea why vcl/unx/gtk has its own XIOErrorHdl that is substantially
different from the vcl/unx/generic one, though.
cherry picked from commit ffea65915b9cc6d4f3c01f829552702654a040f9, plus
follow-up b240a1c188b58e3e717335339bfc3f5e20bb2bf4:
rhbz#1000150: Do not call exit upon XIOError, take two
The _XDefaultIOError handler (libX11-1.6.0/src/XlibInt.c) already calls exit
(even though _XIOError calling _XDefaultIOError would call exit afterwards,
too), so our XIOError handler must not call aOrigXIOErrorHandler.
Change-Id: Ida7d407cf5f0fa4e719118cab5e725144ceb3a35
Reviewed-on: https://gerrit.libreoffice.org/5596
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
Diffstat (limited to 'vcl/unx/gtk/app/gtkdata.cxx')
-rw-r--r-- | vcl/unx/gtk/app/gtkdata.cxx | 12 |
1 files changed, 5 insertions, 7 deletions
diff --git a/vcl/unx/gtk/app/gtkdata.cxx b/vcl/unx/gtk/app/gtkdata.cxx index 14a19495b22a..2f7cc3f9d638 100644 --- a/vcl/unx/gtk/app/gtkdata.cxx +++ b/vcl/unx/gtk/app/gtkdata.cxx @@ -519,14 +519,12 @@ GtkData::GtkData( SalInstance *pInstance ) XIOErrorHandler aOrigXIOErrorHandler = NULL; -int XIOErrorHdl(Display *pDisplay) +int XIOErrorHdl(Display *) { - if (::osl::Thread::getCurrentIdentifier() != Application::GetMainThreadIdentifier()) - { - pthread_exit(NULL); - return 0; - } - return aOrigXIOErrorHandler ? aOrigXIOErrorHandler(pDisplay) : 0; + fprintf(stderr, "X IO Error\n"); + _exit(1); + // avoid crashes in unrelated threads that still run while atexit + // handlers are in progress } GtkData::~GtkData() |