GNOME Bugzilla – Bug 796289
Gimp segfaults on launch on multi-CPU (72 cores) workstation
Last modified: 2018-05-22 12:39:03 UTC
Hi, I have a multi-CPU workstation with a total of 72 hyperthreaded cores, and cannot launch Gimp 2.10+. The best I can tell, Gimp and/or Gegl does support more than 64 cores (per the release notes), the number of cores is polled from the system on launch, and there is no way of configuring a ceiling number of processors such that Gimp does not crash. I've tried setting (num-processors 1) in my gimprc, but it has no effect on the outcome. What follows is a GDB session that shows Gimp crashing when configuring the number of threads for GEGL: $ gdb gimp master|✚5 ✭ GNU gdb (GDB) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gimp...done. (gdb) run Starting program: /usr/bin/gimp [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". (gimp:6094): GLib-GObject-CRITICAL **: 17:30:54.772: g_param_spec_int: assertion 'default_value >= minimum && default_value <= maximum' failed (gimp:6094): GLib-GObject-CRITICAL **: 17:30:54.772: validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed (gimp:6094): Gtk-WARNING **: 17:30:55.968: Unable to locate theme engine in module_path: "adwaita", (gimp:6094): Gtk-WARNING **: 17:30:55.972: Unable to locate theme engine in module_path: "adwaita", [New Thread 0x7fffe8863700 (LWP 6115)] [New Thread 0x7fffe8062700 (LWP 6116)] Missing fast-path babl conversion detected, Implementing missing babl fast paths accelerates GEGL, GIMP and other software using babl, warnings are printed on first occurance of formats used where a conversion has to be synthesized programmatically by babl based on format description *WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double" Thread 1 "gimp" received signal SIGSEGV, Segmentation fault. gimp_gegl_config_class_init (klass=0x55555621e340) at gimpgeglconfig.c:137 137 gimpgeglconfig.c: No such file or directory. (gdb) quit A debugging session is active. Inferior 1 [process 6094] will be killed. Quit anyway? (y or n) y
(In reply to Dylon from comment #0) > Hi, > > I have a multi-CPU workstation with a total of 72 hyperthreaded cores, and > cannot launch Gimp 2.10+. The best I can tell, Gimp and/or Gegl does > support more than 64 cores (per the release notes), the number of cores is > polled from the system on launch, and there is no way of configuring a > ceiling number of processors such that Gimp does not crash. I've tried > setting (num-processors 1) in my gimprc, but it has no effect on the > outcome. What follows is a GDB session that shows Gimp crashing when > configuring the number of threads for GEGL: > > $ gdb gimp > master|✚5 ✭ > GNU gdb (GDB) 8.1 > Copyright (C) 2018 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from gimp...done. > (gdb) run > Starting program: /usr/bin/gimp > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > > (gimp:6094): GLib-GObject-CRITICAL **: 17:30:54.772: g_param_spec_int: > assertion 'default_value >= minimum && default_value <= maximum' failed > > (gimp:6094): GLib-GObject-CRITICAL **: 17:30:54.772: > validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed > > (gimp:6094): Gtk-WARNING **: 17:30:55.968: Unable to locate theme engine in > module_path: "adwaita", > > (gimp:6094): Gtk-WARNING **: 17:30:55.972: Unable to locate theme engine in > module_path: "adwaita", > [New Thread 0x7fffe8863700 (LWP 6115)] > [New Thread 0x7fffe8062700 (LWP 6116)] > Missing fast-path babl conversion detected, Implementing missing babl fast > paths > accelerates GEGL, GIMP and other software using babl, warnings are printed on > first occurance of formats used where a conversion has to be synthesized > programmatically by babl based on format description > > *WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double" > > Thread 1 "gimp" received signal SIGSEGV, Segmentation fault. > gimp_gegl_config_class_init (klass=0x55555621e340) at gimpgeglconfig.c:137 > 137 gimpgeglconfig.c: No such file or directory. > (gdb) quit > A debugging session is active. > > Inferior 1 [process 6094] will be killed. > > Quit anyway? (y or n) y I think this is a GEGL problem, I get the same crash if I replace this: https://git.gnome.org/browse/gegl/tree/gegl/gegl-config.c#n228 g_get_num_processors () call with 72. I think g_get_num_processors () output should be limited to GEGL_MAX_THREADS otherwise I think GeglConfig "threads" property is not installed and GIMP dereferences it unconditionally assuming to find the property in the gegl_config() object: https://git.gnome.org/browse/gimp/tree/app/config/gimpgeglconfig.c#n138
Yes, GEGL must use MIN (_gegl_threads, GEGL_MAX_THREADS).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gegl/issues/72.
Created attachment 372331 [details] [review] gegl: Ensure that the "threads" property gets installed on big machines Turned Massimo's suggestion into a patch. :P
By the way, I will take this opportunity to repeat that just increasing the number of threads might not necessarily make GEGL faster. :) For example, on my two Intel Core i7s, the optimal value for a number of operations is to match the number of physical cores, not virtual hyperthreading cores.