procyberian/gimp
2
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-07-04 01:43:24 +00:00
Code Issues 1 Projects 1 Releases Packages Wiki Activity Actions

Issue #7539: Opening some images lock GIMP.

Browse source 
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.
This commit is contained in:
Jehan 2021-12-01 18:37:18 +01:00
parent ee30d50d60
commit 9b94e347bc
1 changed files with 10 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

11
libgimpbase/gimputils.c
View file

@ -1277,7 +1277,16 @@ gimp_stack_trace_print (const gchar *prog_name,
/* Child process. */ /* Child process. */
gchar *args[9] = { "gdb", "-batch", gchar *args[9] = { "gdb", "-batch",
"-ex", "info threads", "-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 }; (gchar *) prog_name, NULL, NULL };
if (prog_name == NULL) if (prog_name == NULL)