GIMP issueshttps://gitlab.gnome.org/GNOME/gimp/-/issues2023-08-13T11:42:44Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/6927Text tool text editor dialog fails to display text with color tags when openi...2023-08-13T11:42:44ZStanislav GrinkovText tool text editor dialog fails to display text with color tags when opening xcf saved in 2.10### Environment/Versions
- GIMP version: master commit: 81b076aed4
- Package: meson self-built
- Operating System: Xubuntu 20.04
### Description of the bug
Text tool text style editor widget fails to display text with tags when openin...### Environment/Versions
- GIMP version: master commit: 81b076aed4
- Package: meson self-built
- Operating System: Xubuntu 20.04
### Description of the bug
Text tool text style editor widget fails to display text with tags when opening xcf saved in 2.10
### Reproduction
Is the bug reproducible? Always.
Reproduction steps:
In 2.10.24 (self-built 2.10 branch)
0. Create new image, create text layer
0. Write some text about 10 characters
0. Select part of text and change color using floating box.
0. Check 'use editor' box and in Text Editor text area confirm that text has appropriate color and size.
0. Save xcf without compression.
In 2.99.7 (self built master commit 81b076aed4)
0. Open saved image
0. Select `text tool`
0. Check 'Use editor' box
0. Click on text layer
Expected result:
![Screenshot_2021-05-30_20-43-08](/uploads/cc9ee973cc2e6adc0ed941f6a8080400/Screenshot_2021-05-30_20-43-08.png)
Text is being displayed and styled with appropriate tags in Text Editor like in 2.10.24
Actual result:
![Screenshot_2021-05-30_20-43-47](/uploads/120cbfb70909dbd8be5c1b58f6d069e8/Screenshot_2021-05-30_20-43-47.png)
Text characters styled with color tags are not displayed.
### Additional information
Sample file with all tags. Looks like only color tags are affected.
[all-tags-2-10.xcf](/uploads/f167e34c727fa17e19c63f5b776bac34/all-tags-2-10.xcf)
Built with
```plain
using babl version 0.1.85 (compiled against version 0.1.85)
using GEGL version 0.4.30 (compiled against version 0.4.30)
using GLib version 2.64.6 (compiled against version 2.64.6)
using GdkPixbuf version 2.40.0 (compiled against version 2.40.0)
using GTK+ version 3.24.20 (compiled against version 3.24.20)
using Pango version 1.44.7 (compiled against version 1.44.7)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```2.99.18https://gitlab.gnome.org/GNOME/gimp/-/issues/6850Patch: support for memory in the dashboard under OpenBSD2021-05-09T18:04:07ZMarc EspiePatch: support for memory in the dashboard under OpenBSD**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> OpenBSD
### Description of the feature
This shows memory usage in the dashboard under OpenBSD
### Use cases
we don't have any support for /proc...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> OpenBSD
### Description of the feature
This shows memory usage in the dashboard under OpenBSD
### Use cases
we don't have any support for /proc and we are very unlikely to ever get some.
but it's easy to get the necessary information through getrusage and sysctl
I'm unfamiliar with the gimp's project code guidelines... please tell me if more glue is needed.
[openbsd-dashboard.txt](/uploads/171ff4f68609bbbefe53864f05bf27e7/openbsd-dashboard.txt)2.10.26https://gitlab.gnome.org/GNOME/gimp/-/issues/6730About GIMP, link color2023-02-15T04:48:26ZTameoAbout GIMP, link colorThe link text `Visit the GIMP website` in the `Help > About GIMP` window is hard to read.
The blue link color "clashes" with the gray background color.
![gimp-2.10_2021-04-13_10-35-32](/uploads/689971ce77d4379ab76f8d7374e37494/gimp-2.1...The link text `Visit the GIMP website` in the `Help > About GIMP` window is hard to read.
The blue link color "clashes" with the gray background color.
![gimp-2.10_2021-04-13_10-35-32](/uploads/689971ce77d4379ab76f8d7374e37494/gimp-2.10_2021-04-13_10-35-32.png)
System:
Windows 10 20042.10.26https://gitlab.gnome.org/GNOME/gimp/-/issues/6711GIMP crashed with a fatal error: unhandled exception (when using the gradient...2023-12-10T00:48:40ZGideon O. StewardGIMP crashed with a fatal error: unhandled exception (when using the gradient tool)When using Gimp 2.99.2 & 2.99.4 While designing when i click the Gradient tool to open up & choose a color for the design (it usually stops & give me a massage saying Fatal error: unhandled exception, then Crushes.
Image down below
![Gr...When using Gimp 2.99.2 & 2.99.4 While designing when i click the Gradient tool to open up & choose a color for the design (it usually stops & give me a massage saying Fatal error: unhandled exception, then Crushes.
Image down below
![Gradient_tool_always_crushing_gimp_2.99.2](/uploads/dc8c6fd2c0a73d5f0fd63d5586260936/Gradient_tool_always_crushing_gimp_2.99.2.PNG)
Gimp 2.99.2 or 4
Windows 10 pro 64 bit op system -version 2004
processor Intel(R) core (TM) Duo CPU E7500 @2.93GHz 2.92 GHz2.99.18https://gitlab.gnome.org/GNOME/gimp/-/issues/6435Off canvas guides2022-02-11T05:11:20ZYash Pal GoyalOff canvas guidesOperating System: Windows
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help for
understanding the feature or for implementation.
Also add link...Operating System: Windows
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help for
understanding the feature or for implementation.
Also add links when needed, for instance for implementation standards
or other relevant resources.-->
currently Guides can be created only on canvas. This is a bad restriction.
### Use cases
<!-- If not obvious, explain the use cases or problems to solve. -->
Most of the times, when working with layers, my layers go off canvas. And guides cant be created there.
Comment:\
*When u add features, dont impound them to canvas*\
***Free them!***
<!-- ![2.10.12](https://static.gimp.org/news/2019/06/12/gimp-2-10-12-released/20190526-bug-squashing.jpg) -->
![image](/uploads/e69c5caeca983e8c132f4e8df697e81b/image.png)2.99.6https://gitlab.gnome.org/GNOME/gimp/-/issues/6281Add missing libraries to libgimp's Makefile2024-02-16T12:08:50ZLiam Quin (ankh/demib0y/barefootliam)Add missing libraries to libgimp's MakefileFor 2.99.4 Mageia Linux packagers changed libgimp/Makefile.am slightly to add missing libraries;
patch here:
http://svnweb.mageia.org/packages/cauldron/gimp/current/SOURCES/gimp-2.99.4-link.patch?revision=1667434&view=markupFor 2.99.4 Mageia Linux packagers changed libgimp/Makefile.am slightly to add missing libraries;
patch here:
http://svnweb.mageia.org/packages/cauldron/gimp/current/SOURCES/gimp-2.99.4-link.patch?revision=1667434&view=markuphttps://gitlab.gnome.org/GNOME/gimp/-/issues/62552.99 Enhance ScriptFu error handling and debug, patch attached2021-04-26T14:53:39ZLloyd Konnekerkonnekerl@gmail.com2.99 Enhance ScriptFu error handling and debug, patch attached
# To fix these issues:
1. omits domain on g_error_new_literal which throws
GLib-WARNING **: 11:29:10.711: (../../../glib/gerror.c:412):g_error_new_valist: runtime check failed: (domain != 0)
2. Many script error messages do not provid...
# To fix these issues:
1. omits domain on g_error_new_literal which throws
GLib-WARNING **: 11:29:10.711: (../../../glib/gerror.c:412):g_error_new_valist: runtime check failed: (domain != 0)
2. Many script error messages do not provide useful details.
For example, "Invalid type for argument"
omits to says what formal Lisp type was expected (e.g. vector, list, number, string)
3. messages do not distinguish errors by script authors
from errors by the ScriptFu developers.
4. Debugging code is implemented by #ifdef spread throughout the code
making it hard to read.
5. Debugging code has not been maintained and does not compile.
6. There is no test suite
7. A few other small bugs (e.g. missing break on one switch case)
# About the patch
For reviewers of the patch.
TLDR: makes the code easier to read/change, and reduces size of
scheme-wrapper.c by hundreds of lines. No change in behaviour,
except for changes in error message texts or debug log.
Refactors by extracting functions for declaring errors in scripts.
The functions/errors are of two kinds:
- plugin author's errors in scripts
- implementation errors in ScriptFu or in called PDB procedures.
Functions are extracted to script-fu-errors.c
Refactors by extracting functions for debugging (dumping large structs)
Functions are extracted to script-fu-errors.c (same as functions for errors)
Uses GLib logging (g_debug convenience function) instead of g_printerr and #ifdef.
Thus debugging ScriptFu is now:
- controllable at runtime by defining G_MESSAGE_DEBUG=scriptfu
- log messages follow conventions and print the domain "scriptfu"
In my opinion, there is no need to worry about performance in ScriptFu.
However, in the future one could easily:
- conditionally compile the debug functions that were extracted.
- additionally wrap all the g_debug() calls remaining in scheme-wrapper.c
into a conditionally compiled wrapper function
# Related issues
I suggest applying this patch first.
Then other needed patches will be easier.
Some discussion of the future of ScriptFu re GI in #5402, #5426
Other scriptfu issues:
- #5402 (ScriptFu unhandled GIMP types)
- #5426 (need compatibility for changed PDB API re ID vs object)
- #6026 (need compatibility for changed PDB API re multilayer)
# Testing
I tested thoroughly (if not quite exhaustively.)
I did not test exhaustively because it is more important
to fix other issues in ScriptFu that are extant in GIMP repository scripts
(which will add test cases)
than to test cases that are extremely rare, e.g. in arg is STRING_ARRAY.
Since there is still some question about the future of ScriptFu re GI,
no point in testing something that might be scrapped.
A test plugin is at https://github.com/bootchk/testGimpScriptFuBinding.git
It is a GimpFu Python plugin that calls plugin-script-fu-eval
on Scheme constructs, once per test case.
Since is Python, easy to add test cases.2.99.6https://gitlab.gnome.org/GNOME/gimp/-/issues/61072.99 Throws GIMP-CRITICAL when emitting signal for plugin add menu branch, pa...2021-04-24T13:28:50ZLloyd Konnekerkonnekerl@gmail.com2.99 Throws GIMP-CRITICAL when emitting signal for plugin add menu branch, patch attachedGIMP version: master, yesterday's commit 9893f60d
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
Operating System:...GIMP version: master, yesterday's commit 9893f60d
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Ubuntu 20.10
Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> self-built, meson build
# Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
Console shows:
```
> GIMP-CRITICAL: gimp_marshal_VOID__OBJECT_STRING_STRING: assertion 'n_param_values == 4' failed
```
and gimp dialog shows a backtrace (for a crashed plugin?)
# Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
No simple case, I use my test suite that exercises the PDB.
I am not sure the issue really is critical (has any effect on normal users.)
I export GIMP_PLUGIN_DEBUG=all,fatal-criticals
# Additional information
A snippet of the backtrace:
```
#4 0x0000556617bb3b6f in gimp_message_log_func (log_domain=0x55661820d755 "Gimp-Core", flags=G_LOG_LEVEL_CRITICAL, message=0x55661d752100 "gimp_marshal_VOID__OBJECT_STRING_STRING: assertion 'n_param_values == 4' failed", data=0x556618e6c3d0) at ../app/errors.c:263
gimp = 0x556618e6c3d0
config = 0x556618eefc10
msg_domain = 0x0
severity = GIMP_MESSAGE_BUG_CRITICAL
gui_message = 1
debug_policy = GIMP_DEBUG_POLICY_WARNING
#5 0x00007f71d69dbb79 in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f71d69dbe13 in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x0000556617d6d344 in gimp_marshal_VOID__OBJECT_STRING_STRING (closure=0x55661af9d3d0, return_value=0x0, n_param_values=2, param_values=0x7ffc91e00ed0, invocation_hint=0x7ffc91e00e50, marshal_data=0x0) at app/core/gimpmarshal.c:1160
cc = 0x55661af9d3d0
data1 = 0x556600110002
data2 = 0x7ffc91e00e60
callback = 0x7f71d6ace769 <g_object_ref+89>
__func__ = "gimp_marshal_VOID__OBJECT_STRING_STRING"
#8 0x00007f71d6ac98fa in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007f71d6adc4b3 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007f71d6ae2c41 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
```
See attached patch, which I now discuss.
In app/plug-in/gimppluginmanager.c at line 105, error at line 113, the '1':
```
manager_signals[MENU_BRANCH_ADDED] =
g_signal_new ("menu-branch-added",
G_TYPE_FROM_CLASS (klass),
G_SIGNAL_RUN_LAST,
G_STRUCT_OFFSET (GimpPlugInManagerClass,
menu_branch_added),
NULL, NULL,
gimp_marshal_VOID__OBJECT_STRING_STRING,
G_TYPE_NONE, 1,
G_TYPE_FILE,
G_TYPE_STRING,
G_TYPE_STRING);
```
On the face of it, this is wrong, since the value '1' is given
for the 'num_params' argument to g_signal_new,
but it should be '3' since three arguments follow.
I could be wrong, I have little experience with glib or the gimp/app code.
That code was last touched 15 years ago, makes me wonder:
if no one has experienced it yet, how could it be critical?
I did test the patch, it seems to work.
[0002-GIMP-CRITICAL-gimp_marshal_VOID__OBJECT_STRING_STRIN.patch](/uploads/d5b8dfc3120c455b2871e8afd3f4243c/0002-GIMP-CRITICAL-gimp_marshal_VOID__OBJECT_STRING_STRIN.patch)2.10.26https://gitlab.gnome.org/GNOME/gimp/-/issues/60332.99 Python call to PDB procedure taking (void) throws CRITICAL and fails2021-04-08T21:14:05ZLloyd Konnekerkonnekerl@gmail.com2.99 Python call to PDB procedure taking (void) throws CRITICAL and fails```
Replicate:
result = Gimp.get_pdb().run_procedure('gimp-context-list-paint-methods', [] )
gimp-context-list-paint-methods(void) is an INTERNAL procedure taking no arguments
(see attached small plugin test case)
Expect:
result is ...```
Replicate:
result = Gimp.get_pdb().run_procedure('gimp-context-list-paint-methods', [] )
gimp-context-list-paint-methods(void) is an INTERNAL procedure taking no arguments
(see attached small plugin test case)
Expect:
result is a tuple (True, ['gimp-pencil', ...])
Actual:
(testEmptyArgs.py:192): LibGimp-CRITICAL **: 16:44:10.397: gimp_pdb_run_procedure_argv: assertion 'arguments != NULL' failed
and result is None
```
A call to libgimp works:
result = Gimp.gimp-context-list-paint-methods()
so there is a workaround, but there are reasons some authors may want to use the PDB call.
I also tried passing an empty GimpValueArray (see comments in test case.)
43d0f0fb changed how the args are passed to run_procedure()
I vaguely recall changing the annotations somewhere so you could pass a native list
instead of a GimpValueArray for the args parameter? I am not saying the commit is the
cause.
If you install my patch in #5971 and set env GIMP_DEBUG=all,fatal-criticals
so that a CRITICAL is fatal and generates a stack trace,
you get this stack trace:
```
#3 0x00007f0a27f8fcbb in gimp_fatal_func (log_domain=0x7f0a27f9bef2 "LibGimp", flags=10, message=0x13ae380 "gimp_pdb_run_procedure_argv: assertion 'arguments != NULL' failed", data=0x0) at ../libgimp/gimp-debug.c:397
sigset = {__val = {0 <repeats 16 times>}}
level = 0x7f0a27fa3534 "CRITICAL"
#4 0x00007f0a29fdd39c in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f0a29fdd583 in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f0a27f62170 in gimp_pdb_run_procedure_argv (pdb=0x13ae860, procedure_name=0x13c46a0 "gimp-context-list-paint-methods", arguments=0x0, n_arguments=0) at ../libgimp/gimppdb.c:306
args = 0x0
return_values = 0x1
__func__ = "gimp_pdb_run_procedure_argv"
#7 0x00007f0a2a34dff5 in () at /lib/x86_64-linux-gnu/libffi.so.7
#8 0x00007f0a2a34d40a in () at /lib/x86_64-linux-gnu/libffi.so.7
#9 0x00007f0a2a0d60a5 in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#10 0x00007f0a2a0cd25c in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#11 0x00007f0a2a0d119d in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#12 0x00000000005f46d6 in _PyObject_MakeTpCall ()
#13 0x0000000000570936 in _PyEval_EvalFrameDefault ()
#14 0x00000000005f7146 in _PyFunction_Vectorcall ()
#15 0x00000000005f6e27 in PyObject_CallObject ()
#16 0x00007f0a2a0cde4e in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#17 0x00007f0a2a34de06 in () at /lib/x86_64-linux-gnu/libffi.so.7
#18 0x00007f0a2a34e188 in () at /lib/x86_64-linux-gnu/libffi.so.7
#19 0x00007f0a27f5dcdd in gimp_image_procedure_run (procedure=0x13be150, args=0x13afae0) at ../libgimp/gimpimageprocedure.c:138
image_proc = 0x13be150
remaining = 0x13b2b20
return_values = 0x1399748
run_mode = GIMP_RUN_INTERACTIVE
image = 0x137f010
drawable = 0x13a82d0
i = 3
#20 0x00007f0a27f6a53a in gimp_procedure_run (procedure=0x13be150, args=0x13afae0) at ../libgimp/gimpprocedure.c:1819
return_vals = 0x90a9f0 <_Py_NoneStruct>
error = 0x0
i = 9480688
__func__ = "gimp_procedure_run"
#21 0x00007f0a27f652be in gimp_plug_in_proc_run_internal (plug_in=0x13a7560, proc_run=0x12e92c0, procedure=0x13be150, proc_return=0x7ffe55315840) at ../libgimp/gimpplugin.c:1216
arguments = 0x13afae0
return_values = 0x0
#22 0x00007f0a27f65129 in gimp_plug_in_proc_run (plug_in=0x13a7560, proc_run=0x12e92c0) at ../libgimp/gimpplugin.c:1163
proc_return = {name = 0x7ffe55315880 "\005", n_params = 20381232, params = 0x1399598}
procedure = 0x13be150
#23 0x00007f0a27f64e42 in gimp_plug_in_loop (plug_in=0x13a7560) at ../libgimp/gimpplugin.c:1071
msg = {type = 5, data = 0x12e92c0}
#24 0x00007f0a27f6446c in _gimp_plug_in_run (plug_in=0x13a7560) at ../libgimp/gimpplugin.c:820
__func__ = "_gimp_plug_in_run"
#25 0x00007f0a27f57c9a in gimp_main (plug_in_type=Python Exception <class 'gdb.error'> No type named TypeNode.:
, argc=7, argv=0x1399760) at ../libgimp/gimp.c:538
read_channel = 0x136fe30
write_channel = 0x1109e20
basename = 0x139b810 "\001"
protocol_version = 270
__func__ = "gimp_main"
#26 0x00007f0a2a34dff5 in () at /lib/x86_64-linux-gnu/libffi.so.7
#27 0x00007f0a2a34d40a in () at /lib/x86_64-linux-gnu/libffi.so.7
#28 0x00007f0a2a0d60a5 in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#29 0x00007f0a2a0cd25c in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#30 0x00000000005f46d6 in _PyObject_MakeTpCall ()
#31 0x0000000000570936 in _PyEval_EvalFrameDefault ()
#32 0x000000000056955a in _PyEval_EvalCodeWithName ()
#33 0x000000000068c4a7 in PyEval_EvalCode ()
#34 0x000000000067bc91 in ()
#35 0x000000000067bd0f in ()
#36 0x000000000067bdcb in PyRun_FileExFlags ()
#37 0x000000000067de4e in PyRun_SimpleFileExFlags ()
#38 0x00000000006b6032 in Py_RunMain ()
#39 0x00000000006b63bd in Py_BytesMain ()
#40 0x00007f0a2aa0d0b3 in __libc_start_main () at /lib/x86_64-linux-gnu/libc.so.6
#41 0x00000000005fa4de in _start ()
[Inferior 1 (process 193) detached]
LibGimp (pid:193): [E]xit, show [S]tack trace or [P]roceed:
```
[testEmptyArgs.py](/uploads/68e544910b4cc77faf7c17adafd0dfcd/testEmptyArgs.py)https://gitlab.gnome.org/GNOME/gimp/-/issues/59842.99 PDB procedure file-openraster-save throws CRITICAL at Gimp.ObjectArray....2022-04-14T16:26:11ZLloyd Konnekerkonnekerl@gmail.com2.99 PDB procedure file-openraster-save throws CRITICAL at Gimp.ObjectArray.new(), patch attached
Reproduce, simply but without a useful backtrace:
"Export As" format ora
1) File>New, choose OK
2) File>Export As.., choose "SelectFileType>Open Raster", choose "Export"
Expect: success
Actual: Console shows
```
/usr/lib/python3/d...
Reproduce, simply but without a useful backtrace:
"Export As" format ora
1) File>New, choose OK
2) File>Export As.., choose "SelectFileType>Open Raster", choose "Export"
Expect: success
Actual: Console shows
```
/usr/lib/python3/dist-packages/gi/overrides/GObject.py:266: Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
_gi._gvalue_set(self, py_value)
/usr/local/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/file-openraster/file-openraster.py:142: Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Gimp.get_pdb().run_procedure('file-png-save', [
(gimp-2.99:37): GLib-GObject-CRITICAL **: 10:42:04.955: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(gimp-2.99:37): GLib-GObject-CRITICAL **: 10:42:04.955: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(file-png:82): GLib-GObject-CRITICAL **: 10:42:04.985: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(file-png:82): GLib-GObject-CRITICAL **: 10:42:04.985: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(file-png:82): GLib-GObject-CRITICAL **: 10:42:04.985: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(file-png:82): GLib-GObject-CRITICAL **: 10:42:04.985: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(file-png:82): GLib-GObject-CRITICAL **: 10:42:04.986: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(file-png:82): GEGL-CRITICAL **: 10:42:05.122: gegl_buffer_get_extent: assertion 'GEGL_IS_BUFFER (buffer)' failed
/usr/local/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/file-png/file-png: fatal error: Segmentation fault
/usr/local/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/file-png/file-png (pid:82): [E]xit, show [S]tack trace or [P]roceed:
```
I omit the backtrace, its not useful since many errors intervene with the root cause.
To reproduce so that it stops at the first fault:
1) set env var GIMP_PLUGIN_DEBUG=file-png,fatal-warnings (note openraster.py calls file-png-save, where error is)
2) as before, try export as ora
```
Aside: this is one case where my patch #5971 helps debug, since there is a tree of PDB procedure calls,
you don't know which one is at fault ahead of time:
1) install my patch from #5971 (has simple merge conflicts)
2) set env var GIMP_PLUGIN_DEBUG=all,fatal-critical
3) as before, try export as ora
```
Now the console shows:
```
Plugin file-openraster.py: GLib-GObject: CRITICAL: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
GLib-GObject (pid:80): [E]xit, show [S]tack trace or [P]roceed:
```
Enter "s".
Snippet of backtrace is:
```
# Stack traces obtained from PID 80 - Thread 80 #
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f5a3fd22142 in read () from /lib/x86_64-linux-gnu/libc.so.6
Id Target Id Frame
* 1 Thread 0x7f5a3fa45740 (LWP 80) "python3" 0x00007f5a3fd22142 in read () from /lib/x86_64-linux-gnu/libc.so.6
Thread 1 (Thread 0x7f5a3fa45740 (LWP 80)):
#0 0x00007f5a3fd22142 in read () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f5a3ea822c1 in gimp_stack_trace_print (prog_name=0x7f5a3f195300 "GLib-GObject", stream=0x7f5a3fdfd6a0 <_IO_2_1_stdout_>, trace=0x0) at ../libgimpbase/gimputils.c:1345
status = 32602
stack_printed = 0
gtrace = 0x0
gimp_pid = "80\000G_IS_OBJECT ("
buffer = "ct_ref: assertioCRITICAL: g_objep\022n?Z\177\000\000pbK?Z\177\000\000", '\377' <repeats 16 times>, "\000\000\000\000\000\000\000\000\000\000 \000 \000\000\000\000\000\000\377\000\000\000\377\377\377\377\377\377\360\251\220\000\000\000\000\000\360\251\220\000\000\000\000\000\360\251\220", '\000' <repeats 13 times>, "\360\251\220\000\000\000\000\000\360\251\220\000\000\000\000\000\360\251\220", '\000' <repeats 13 times>, "\026\000\000\000\001", '\000' <repeats 12 times>, "S\031?Z\177\000\000\200\311\337?Z\177\000\000\b\000\000\000\000\000\000\000"...
read_n = 42136848
sync_fd = {8, 9}
out_fd = {10, 11}
fork_pid = 83
pid = 80
eintr_count = 0
tid = 80
#2 0x00007f5a3ea82617 in gimp_stack_trace_query (prog_name=0x7f5a3f195300 "GLib-GObject") at ../libgimpbase/gimputils.c:1515
buf = "s\n", '\000' <repeats 13 times>
#3 0x00007f5a3d03bdae in gimp_fatal_func (log_domain=0x7f5a3f195300 "GLib-GObject", flags=10, message=0x2819d20 "g_object_ref: assertion 'G_IS_OBJECT (object)' failed", data=0x0) at ../libgimp/gimp-debug.c:397
sigset = {__val = {0 <repeats 16 times>}}
level = 0x7f5a3d04ee24 "CRITICAL"
#4 0x00007f5a3f20839c in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f5a3f208583 in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f5a3f168960 in g_object_ref () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007f5a3ea7dc3e in gimp_object_array_new (object_type=Python Exception <class 'gdb.error'> No type named TypeNode.:
, data=0x28da340, length=1, static_data=0) at ../libgimpbase/gimpparamspecs.c:1483
tmp = 0x28ded90
i = 0
array = 0x281dec0
__func__ = "gimp_object_array_new"
#8 0x00007f5a3ea7dcc6 in gimp_object_array_copy (array=0x281dee0) at ../libgimpbase/gimpparamspecs.c:1510
#9 0x00007f5a3f16175b in g_boxed_copy () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007f5a3f161a92 in g_value_set_boxed () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007f5a3f30abc7 in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#12 0x00007f5a3f30b1c2 in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#13 0x00000000005f42ea in PyCFunction_Call ()
#14 0x00000000005f46d6 in _PyObject_MakeTpCall ()
#15 0x0000000000570936 in _PyEval_EvalFrameDefault ()
#16 0x00000000005f7146 in _PyFunction_Vectorcall ()
#17 0x000000000056b399 in _PyEval_EvalFrameDefault ()
#18 0x000000000056955a in _PyEval_EvalCodeWithName ()
#19 0x00000000005f7323 in _PyFunction_Vectorcall ()
#20 0x000000000059c654 in ()
#21 0x00000000005f463f in _PyObject_MakeTpCall ()
#22 0x0000000000570936 in _PyEval_EvalFrameDefault ()
#23 0x000000000056955a in _PyEval_EvalCodeWithName ()
#24 0x00000000005f7323 in _PyFunction_Vectorcall ()
#25 0x000000000056b26e in _PyEval_EvalFrameDefault ()
#26 0x000000000056955a in _PyEval_EvalCodeWithName ()
#27 0x00000000005f7323 in _PyFunction_Vectorcall ()
#28 0x000000000056b26e in _PyEval_EvalFrameDefault ()
#29 0x000000000056955a in _PyEval_EvalCodeWithName ()
#30 0x00000000005f7323 in _PyFunction_Vectorcall ()
#31 0x00000000005f6e27 in PyObject_CallObject ()
#32 0x00007f5a3f2f8e4e in () at /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#33 0x00007f5a3f578e06 in () at /lib/x86_64-linux-gnu/libffi.so.7
#34 0x00007f5a3f579188 in () at /lib/x86_64-linux-gnu/libffi.so.7
#35 0x00007f5a3d01be06 in gimp_save_procedure_run (procedure=0x28d3170, args=0x281d8c0) at ../libgimp/gimpsaveprocedure.c:176
save_proc = 0x28d3170
remaining = 0x281df00
return_values = 0x271b378
run_mode = GIMP_RUN_INTERACTIVE
image = 0x280fe10
drawables = 0x285e760
file = 0x281de80
n_drawables = 1
i = 5
```
Reading the stack trace:
6 throws the CRITICAL
7 ..... "object_type=Python Exception <class 'gdb.error'>" only means that gdb failed
while trying to print the stacktrace, not that the openraster.py faulted
I believe the issue starts at about line 149 of openraster.py,
trying to create a GimpObjectArray for a list of drawables.
(committed recently in dbc19800.)
```
[
...
GObject.Value(Gimp.ObjectArray, Gimp.ObjectArray.new(Gimp.Drawable, [drawable], 1)),
...
]
```
This code fixes it (see the attached patch.)
```
# Create an empty gvalue that is a GimpObjectArray
a_gvalue = GObject.Value(Gimp.ObjectArray.__gtype__)
# Set its value from a list holding one drawable
Gimp.value_set_object_array(a_gvalue, drawable.__gtype__, [drawable])
[
...
a_gvalue,
...
]
```
I can't explain why the original code fails.
Maybe there is a problem in GI annotations.
The attached patch might be considered an expedient work-around.
Maybe there is another Python construct that works, but several I tried failed.
```
GObject.Value(Gimp.ObjectArray, Gimp.ObjectArray.new(Gimp.Drawable, [drawable])),
GObject.Value(Gimp.ObjectArray, Gimp.ObjectArray.new(Gimp.Drawable, [drawable], 1)),
GObject.Value(Gimp.ObjectArray, Gimp.ObjectArray.new(drawable.__gtype__, [drawable], 1)),
```
There could also be an education/documentation issue.
It is hard to understand what the gir doc means, for Gimp, language Python. It says:
```
Gimp.ObjectArray
from gi.repository import Gimp
object_array = Gimp.ObjectArray()
Methods
Gimp.ObjectArray.copy
Gimp.ObjectArray.free
Fields
Gimp.ObjectArray->data
Gimp.ObjectArray->length
Gimp.ObjectArray->object_type
Gimp.ObjectArray->static_data
More Information
Gimp
```
" object_array = Gimp.ObjectArray()" seems to suggest you could instantiate one,
that the class/type name is the constructor?
The new() method is not documented, but in my experience, works sometimes,
e.g. for Gimp.Image.new()
Gimp.ObjectArray is a type that you can use where you need to pass a type,
and in Python you can instantiate one but it would always be empty?
and there is no method to give or take its contents ?
and the other methods should rarely be needed?
The GI annotation for Gimp.ObjectArray might say
"is an opaque type only used to create a GValue
using the factory method Gimp.value_set_object_array()" ?
Or maybe a Gimp.ObjectArrayFactory would be helpful?
Related: #5312 #5838 (dbc19800) both trying to fix openraster
Context:
self-built recent master using meson build
Ubuntu 20.04
[0003-file-openraster-save-throws-CRITICAL.patch](/uploads/01792077d4bb4b3f278e11735efa24b0/0003-file-openraster-save-throws-CRITICAL.patch)3.0https://gitlab.gnome.org/GNOME/gimp/-/issues/59712.99 Enhance: GIMP_PLUGIN_DEBUG backtrace for plugins2020-12-18T00:23:22ZLloyd Konnekerkonnekerl@gmail.com2.99 Enhance: GIMP_PLUGIN_DEBUG backtrace for plugins```
This has several items. A patch is attached (having a few small merge conflicts.)
This is about the "machinery" behind the GIMP_PLUGIN_DEBUG env var.
See both the old and the enhanced devel-docs/debug-plug-ins.txt.
The enhancement...```
This has several items. A patch is attached (having a few small merge conflicts.)
This is about the "machinery" behind the GIMP_PLUGIN_DEBUG env var.
See both the old and the enhanced devel-docs/debug-plug-ins.txt.
The enhancements benefit a developer/tester of plugins.
Since v3, more plugins will rely on GLib and benefit from enhanced debugging.
1) Currently, the machinery only works for the plug-in logging domain.
That is it catches log events from plug-in code proper,
and not from e.g. GLib code itself.
A developer may want to catch log events regardless of logging domain.
The enhanced code installs a fatal log handler for more domains .
(As is currently done for the app process.
The list of domains is not entirely in common with app.
The patch does not catch GEGL events.
The coded const array of domains is not shared with app, but it could be.
)
2) Currently, the machinery only works for one named plug-in.
Since plugins can call plugins, a tester may not know in advance which plugin is faulty.
The enhancement allows GIMP_PLUGIN_DEBUG=all, to catch fatal log events for any plugin.
3) Currently, the machinery only allows GIMP_PLUGIN_DEBUG=foo,fatal-warnings that
catches both WARNINGS and/or CRITICALS (not fine-grained.)
Anecdotal evidence suggests that CRITICALS are more serious than WARNINGSs.
A tester might want to filter more serious events.
The enhancement allows GIMP_PLUGIN_DEBUG=foo,fatal-criticals
to make fatal any CRITICAL log events, but not WARNINGs.
4) Currently, the machinery does not print the process name that received log events,
only the log domain that sent the event.
Many processes (the app and many plugins) may be printing interleaved to stderr.
So it is hard to read the console.
The enhancement prints the name of the receiving plugin ahead of the sender
e.g. "file-psd: GLib-GIO: ... "
The prefix is new, but the message format remains similar
to that printed currently, similar to what the GLib default log handler prints.
5) In the absence of options ( e.g. GIMP_PLUGIN_DEBUG=all ) the default option
is the same as "=all,run:fatal-warnings". This means that a tester cannot
define options that can print a backtrace only for ERROR.
The enhancement eliminates the default, so that GIMP_PLUGIN_DEBUG=all means an
ERROR will print a backtrace according to stack-trace-mode. The option "on",
which was shorthand for option "run:fatal-warning", is eliminated.
6) The code that implements the machinery is mixed with other irrelevant code.
Making the code hard to read or change.
The enhancement refactors by extracting functions relevant to debugging
from libgimp/gimp.c to libgimp/gimp-debug.c.
Done without changing the build system or changing any #include statements.
(Extracting means taking a chunk of code from gimp.c, replacing it with a function
call, and defining the function in gimp-debug.c whose body is the chunk.
The patch goes slightly beyond that with other small code improvements.
)
7) The documentation is stale.
The enhancement updates devel-docs/debug-plug-ins.txt, to make it clearer,
and to document the enhancements.
```
[0001-enhance-GIMP-PLUGIN-DEBUG-backtrace.patch](/uploads/124df714b6cafb0dfdda0e88d497b875/0001-enhance-GIMP-PLUGIN-DEBUG-backtrace.patch)2.99.4https://gitlab.gnome.org/GNOME/gimp/-/issues/5918file_jpeg_save(): throws GLib-GObject-CRITICAL when called non-interactively.2024-03-21T17:51:17ZLloyd Konnekerkonnekerl@gmail.comfile_jpeg_save(): throws GLib-GObject-CRITICAL when called non-interactively.To reproduce:
in a plugin call the pdb procedure file-jpeg-save with args (runmode, image, num_drawables, drawables, file).
The rest of the parameters should default.
Expect:
no error messages.
Actual:
(file-jpeg:89): GLib-GObject...To reproduce:
in a plugin call the pdb procedure file-jpeg-save with args (runmode, image, num_drawables, drawables, file).
The rest of the parameters should default.
Expect:
no error messages.
Actual:
(file-jpeg:89): GLib-GObject-CRITICAL **: 19:37:03.157: g_value_get_double: assertion 'G_VALUE_HOLDS_DOUBLE (value)' failed
(Its not clear in my testing whether it actually created a file and if it did, what jpg options it used.
I would think the behavior was undefined after such an error.)
When you use the GUI, File>ExportAs>jpg succeeds without a message. I.E. when called in interactive runmode.
Just reading the code: the cause is likely at plug-ins/file-jpeg/jpeg.c near line 485.
There the code calls g_value_get_double to get values of type double for args 5-8,
which does not agree with the code near line 232 where the procedure registers those args as types (int, bool, int, int).
Context:
I found this using my test plugin https://github.com/bootchk/testGimpExportImport.git,
but it is not a small test case.
When I also set export G_DEBUG=fatal-warnings, the plugin actually aborts.
Ubuntu 20.04
Latest gimp 2.99 self-built using meson build.https://gitlab.gnome.org/GNOME/gimp/-/issues/5911GimpUnitComboBox doesn't show full unit names in 2.992023-06-22T23:04:27ZJehanGimpUnitComboBox doesn't show full unit names in 2.99GIMP version: master branch
# Description of the bug
The `GimpUnitComboBox` widget used to show the full names when the list is unfolded. It still works in 2.10.22, but not on the master branch.
![Screenshot_from_2020-11-12_18-07-36](...GIMP version: master branch
# Description of the bug
The `GimpUnitComboBox` widget used to show the full names when the list is unfolded. It still works in 2.10.22, but not on the master branch.
![Screenshot_from_2020-11-12_18-07-36](/uploads/1fafe99f87e827e02bb0d7392c409655/Screenshot_from_2020-11-12_18-07-36.png)
# Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Just click a unit combo box, for instance when creating a new image or in the status bar.2.99.16https://gitlab.gnome.org/GNOME/gimp/-/issues/5809Meson build using lld linker fails: missing dependency on libm for libgimpwid...2020-10-24T16:35:33ZLloyd Konnekerkonnekerl@gmail.comMeson build using lld linker fails: missing dependency on libm for libgimpwidgets/test-eevlThis is a trivial issue with build system, use case: meson, clang, lld. Patch attached.
Symptom: build stops with linker error: unresolved symbol 'pow' when linking test-eevl, which is an executable for testing.
Analysis: libgimpwidge...This is a trivial issue with build system, use case: meson, clang, lld. Patch attached.
Symptom: build stops with linker error: unresolved symbol 'pow' when linking test-eevl, which is an executable for testing.
Analysis: libgimpwidgets/test-eevl.c does include math.h and so depends on the system math library (libm usually)
but libgimpwidgets/meson.build does not declare that dependency.
More specifics:
- Gimp 2.99 pulled a few days ago
- Ubuntu 20.04 with installed packages [meson, clang, lld]
- I am attempting to build with address sanitizer asan.
Build command is:
```
env CC=clang CXX=clang++ CC_LD=/usr/bin/ld.lld CXX_LD=/usr/bin/ld.lld LDFLAGS=-shared-libasan meson _build \
--buildtype=debug \
-Djavascript=false \
-Dlua=false \
-Dpython=true \
-Dgtk-doc=false \
-Db_sanitize=address
```
I looked at Gimp's CI build using clang. I can't explain why it seems to work while this build doesn't.
Possibly that build uses a more recent debian-testing container and version of clang.
Even after fixing this, the build stops at another issue, g-ir-scanner seems to invoke gcc instead of clang,
but passes clang style warning options, and stops.
[patch.diff](/uploads/45d6e138fa6bc78204f43d18b7e44e18/patch.diff)2.99.2https://gitlab.gnome.org/GNOME/gimp/-/issues/5785Screenshot fails with "process is not authorized" error in KDE Plasma 5.202021-12-27T22:49:48ZJonathan LiuScreenshot fails with "process is not authorized" error in KDE Plasma 5.20GIMP version: 2.10.22
Operating System: Linux
Package: Arch Linux (gimp 2.10.22-1)
Taking screenshot using GIMP running in KDE Plasma 5.20 desktop environment fails.
# Reproduction
Is the bug reproducible? Always
Reproduction steps...GIMP version: 2.10.22
Operating System: Linux
Package: Arch Linux (gimp 2.10.22-1)
Taking screenshot using GIMP running in KDE Plasma 5.20 desktop environment fails.
# Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Click File > Create > Screenshot
2. Click Snap button
Expected result: Screenshot taken and opened
Actual result: GIMP Message error dialog is shown
# Additional information
The error dialog has the following error text:
GIMP Message
Execution error for 'Screenshot':
GDBus.Error:org.kde.kwin.Screenshot.Error.NoAuthorized: The process is not authorized to take a screenshot2.10.30https://gitlab.gnome.org/GNOME/gimp/-/issues/5783Accessibility: Button focus not visible in dark theme2022-09-28T18:58:59Z積丹尼 Dan Jacobsonjidanni@jidanni.orgAccessibility: Button focus not visible in dark themeThings were going great.
I could get everywhere with keyboard navigation...
OK, time to quit. So I click CTRL+Q. Everything still great, until…
![21633-2](/uploads/600bbd25b8377d7c1778ca63b6e50ac2/21633-2.jpg)
That's right, no matter...Things were going great.
I could get everywhere with keyboard navigation...
OK, time to quit. So I click CTRL+Q. Everything still great, until…
![21633-2](/uploads/600bbd25b8377d7c1778ca63b6e50ac2/21633-2.jpg)
That's right, no matter how many TAB TAB TABs I press, or ALT+ key sequences I use,
there is no way to penetrate the Close Dialog with keyboard navigation.
Ideally TAB TAB TAB should navigate between the three buttons at the bottom.
OK, it indeed does say one can press CTRL+D... but still... that is only for one of the choices too.2.10.24https://gitlab.gnome.org/GNOME/gimp/-/issues/5750[Patch] Fix for typos2021-02-15T22:48:12Zluzpaz[Patch] Fix for typosUsing a proprietary git program doesn't let me connect to private repositories. So I'm submitting a patch in a now unorthodox way. Sorry about that. Hopefully I can figure out a workaround soon.
Patch: ~~https://gist.githubusercontent.c...Using a proprietary git program doesn't let me connect to private repositories. So I'm submitting a patch in a now unorthodox way. Sorry about that. Hopefully I can figure out a workaround soon.
Patch: ~~https://gist.githubusercontent.com/luzpaz/15f0a64e1a0ba109c05d927985a579e2/raw/6bf1cf51d2e3209eb9958f2913fcf0b42dd901d2/typo.patch~~2.99.4https://gitlab.gnome.org/GNOME/gimp/-/issues/5736gimp-2.10.22/app/core/gimpimage-convert-indexed.c:2008: possible cut'n'paste ...2021-08-06T09:51:55Zdcb314gimp-2.10.22/app/core/gimpimage-convert-indexed.c:2008: possible cut'n'paste error ?gimp-2.10.22/app/core/gimpimage-convert-indexed.c:2008:16: style: Variable 'b2->Rmin' is reassigned a value before the old one has been used. [redundantAssignment]
Source code is
b1->Rmax = lb;
b2->Rmin = lb + 1;
Maybe bet...gimp-2.10.22/app/core/gimpimage-convert-indexed.c:2008:16: style: Variable 'b2->Rmin' is reassigned a value before the old one has been used. [redundantAssignment]
Source code is
b1->Rmax = lb;
b2->Rmin = lb + 1;
Maybe better code:
b1->Rmax = lb;
b1->Rmin = lb + 1;https://gitlab.gnome.org/GNOME/gimp/-/issues/5735gimp-2.10.22/plug-ins/common/file-psp.c:854:45: style: Suspicious condition ?2020-10-09T00:34:50Zdcb314gimp-2.10.22/plug-ins/common/file-psp.c:854:45: style: Suspicious condition ?Source code is
&& (fread (&init_len, 4, 1, f) < 1 || (init_len = GUINT32_FROM_LE (init_len) < 42)))
Maybe better code:
&& (fread (&init_len, 4, 1, f) < 1 || ((init_len = GUINT32_FROM_LE (init_len)) < 42)))Source code is
&& (fread (&init_len, 4, 1, f) < 1 || (init_len = GUINT32_FROM_LE (init_len) < 42)))
Maybe better code:
&& (fread (&init_len, 4, 1, f) < 1 || ((init_len = GUINT32_FROM_LE (init_len)) < 42)))2.10.24https://gitlab.gnome.org/GNOME/gimp/-/issues/5734gimp-2.10.22/plug-ins/common/file-heif.c: 2 * bad if statement ?2020-10-07T23:48:08Zdcb314gimp-2.10.22/plug-ins/common/file-heif.c: 2 * bad if statement ?1.
gimp-2.10.22/plug-ins/common/file-heif.c:1142:54: style: Same expression on both sides of '&&'. [duplicateExpression]
Source code is
if (tiffheader[0] == tiffHeaderBE[0] && tiffheader[1] == tiffHeaderBE[1] &&
...1.
gimp-2.10.22/plug-ins/common/file-heif.c:1142:54: style: Same expression on both sides of '&&'. [duplicateExpression]
Source code is
if (tiffheader[0] == tiffHeaderBE[0] && tiffheader[1] == tiffHeaderBE[1] &&
tiffheader[2] == tiffHeaderBE[2] && tiffheader[2] == tiffHeaderBE[2])
Maybe better code:
if (tiffheader[0] == tiffHeaderBE[0] && tiffheader[1] == tiffHeaderBE[1] &&
tiffheader[2] == tiffHeaderBE[2] && tiffheader[3] == tiffHeaderBE[3])
2.
gimp-2.10.22/plug-ins/common/file-heif.c:1147:54: style: Same expression on both sides of '&&'. [duplicateExpression]2.10.24