From 9b94e347bcb39c1f5bed2f0df16cbd7deefa6ff4 Mon Sep 17 00:00:00 2001 From: Jehan Date: Wed, 1 Dec 2021 18:37:18 +0100 Subject: [PATCH] Issue #7539: Opening some images lock GIMP. In some conditions, and only with some installations, the called GDB ends up hanging and never returning. Worse, even if you use non-blocking functions such as poll() or select() with a timeout, in order to wait for the debugger output, these block anyway and never return. We are currently unsure what exactly causes such problem, but not using the thread command in gdb avoids it for now. This is a bit of a regression, though most of the time anyway the useful traces are the main thread ones (I think ever since I implemented this, there must not have been more than 2 or 3 cases where we actually needed the secondary traces). So it's acceptable, at least for now. --- libgimpbase/gimputils.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/libgimpbase/gimputils.c b/libgimpbase/gimputils.c index 1b07acee57..227efd5b95 100644 --- a/libgimpbase/gimputils.c +++ b/libgimpbase/gimputils.c @@ -1277,7 +1277,16 @@ gimp_stack_trace_print (const gchar *prog_name, /* Child process. */ gchar *args[9] = { "gdb", "-batch", "-ex", "info threads", - "-ex", "thread apply all backtrace full", + /* We used to be able to ask for the full + * backtrace of all threads, but a bug, + * possibly in gdb, could lock the whole GIMP + * process. So for now, let's just have a + * backtrace of the main process (most bugs + * happen here anyway). + * See issue #7539. + */ + /*"-ex", "thread apply all backtrace full",*/ + "-ex", "backtrace full", (gchar *) prog_name, NULL, NULL }; if (prog_name == NULL)