summaryrefslogtreecommitdiff
path: root/vcl/unx/gtk
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2013-08-23 12:03:45 +0200
committerFridrich Strba <fridrich@documentfoundation.org>2013-08-26 08:40:25 +0000
commit8ea056e716d87c07343adc8532ce6f265de13624 (patch)
treef1e148b60ea0c904145dc0d51f06e37910f028d4 /vcl/unx/gtk
parent587b8034d3b53ffd28b80261683713ae0b1bab47 (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')
-rw-r--r--vcl/unx/gtk/app/gtkdata.cxx12
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()