On Sun, Aug 6, 2017 at 1:49 PM, richard brown wrote:

No-one?

Asking me?

The babl fast path is probably not the problem, at least it is not a problem here. Actually, I kind of like it because I can watch it to know where some of the other plug-ins are at in their progress.

The last time I had a segfault like that, I was instructed to install gdb ( https://www.gnu.org/software/gdb/) because the regular stack trace is not so helpful.

That has been a few years now, so maybe my advice is outdated.

Carol

On Sun, Aug 6, 2017 at 5:30 PM, richard brown wrote:

On 06/08/17 21:20, Carol Spears wrote:

On Sun, Aug 6, 2017 at 1:49 PM, richard brown wrote:

No-one?

Asking me?

The babl fast path is probably not the problem, at least it is not a problem here. Actually, I kind of like it because I can watch it to know where some of the other plug-ins are at in their progress.

The last time I had a segfault like that, I was instructed to install gdb ( https://www.gnu.org/software/gdb/) because the regular stack trace is not so helpful.

That has been a few years now, so maybe my advice is outdated.

Thanks. I tried it, and it doesn't like the "gimp-2.9" script that launches the program.

"/home/richard/Software/gimp-git/gimp/app/gimp-2.9": not in executable format: File format not recognised

gdb is going to want to be started from the command line.

It is weird to me that you are running this from the source file. You don't install into /usr/local or /opt or some such? If you have been building and using gimp from there for a long while, that would not be the problem but I would have thought that this could cause problems, like gimp finding the plug-ins it brings, etc.

Here is a how-to that doesn't mention anything I remember when I used gdb: http://web.eecs.umich.edu/~sugih/pointers/summary.html

I remember using "bt" something like 'gdb bt /path/to/binary/gimp-2.n'

If you could get a good output from that, perhaps you could file a bug report and maybe the real hackers are there....

Carol

On Sun, Aug 6, 2017 at 7:00 PM, Carol Spears wrote:

On Sun, Aug 6, 2017 at 5:30 PM, richard brown wrote:

On 06/08/17 21:20, Carol Spears wrote:

On Sun, Aug 6, 2017 at 1:49 PM, richard brown wrote:

No-one?

Asking me?

The babl fast path is probably not the problem, at least it is not a problem here. Actually, I kind of like it because I can watch it to know where some of the other plug-ins are at in their progress.

The last time I had a segfault like that, I was instructed to install gdb (https://www.gnu.org/software/gdb/) because the regular stack trace is not so helpful.

That has been a few years now, so maybe my advice is outdated.

Thanks. I tried it, and it doesn't like the "gimp-2.9" script that launches the program.

"/home/richard/Software/gimp-git/gimp/app/gimp-2.9": not in executable format: File format not recognised

gdb is going to want to be started from the command line.

It is weird to me that you are running this from the source file. You don't install into /usr/local or /opt or some such? If you have been building and using gimp from there for a long while, that would not be the problem but I would have thought that this could cause problems, like gimp finding the plug-ins it brings, etc.

Here is a how-to that doesn't mention anything I remember when I used gdb: http://web.eecs.umich.edu/~sugih/pointers/summary.html

I remember using "bt" something like 'gdb bt /path/to/binary/gimp-2.n'

If you could get a good output from that, perhaps you could file a bug report and maybe the real hackers are there....

After some thought, (and unfortunately no reading) I suspect that the "bt" was typed during the stack trace.

Perhaps there is some reliable advice in the mail list archives....

Carol

On 08/09/2017 07:31 AM, richard brown wrote:

But, I checked 'Preferences' and I was running 4 threads, and there's a warning there about instability. So, I tried putting that to 1, and, so far, no crash.

Hi! We're trying to track down (and fix) as many threading related bugs as we can. They're especially sneaky, so reporting these bugs helps us greatly. Could you please file a bug report, explaining what you did to trigger the crash? A backtrace at the point of the crash would also be very helpful: when you run gimp under gdb, type "bt" once gimp crashes, and include the output in the bug report.

Thanks :)

-- Ell

Am Donnerstag, 10. August 2017, 14:45:57 CEST schrieb Ell via gimp-developer- list:

On 08/09/2017 07:31 AM, richard brown wrote:

But, I checked 'Preferences' and I was running 4 threads, and there's a warning there about instability. So, I tried putting that to 1, and, so far, no crash.

Hi! We're trying to track down (and fix) as many threading related bugs as we can. They're especially sneaky, so reporting these bugs helps us greatly. Could you please file a bug report, explaining what you did to trigger the crash? A backtrace at the point of the crash would also be very helpful: when you run gimp under gdb, type "bt" once gimp crashes, and include the output in the bug report.

To make the backtrace even more useful you can use these commands in gdb once GIMP crashed (just copy&paste them over):

set pagination off set logging file gdb.txt
set logging on
where
echo \n=========\n\n
info threads
echo \n=========\n
thread apply all bt full

the result will be in the file "gdb.txt".

Thanks :)

--
Ell

Tobias

On 08/10/2017 10:54 PM, richard brown wrote:

Here we are:

Thread 1 "gimp-2.9" received signal SIGSEGV, Segmentation fault. g_type_check_instance (type_instance=type_instance@entry=0x4ce7a90) at gtype.c:4131
4131 TypeNode *node = lookup_type_node_I (type_instance->g_class->g_type);
(gdb) bt
#0 g_type_check_instance (type_instance=type_instance@entry=0x4ce7a90) at gtype.c:4131
#1 0x00007ffff3d67d5e in g_signal_emit_valist (instance=0x4ce7a90, signal_id=227, detail=0, var_args=var_args@entry=0x7fffffffdbf0) at gsignal.c:3176
#2 0x00007ffff3d6900f in g_signal_emit (instance=, signal_id=, detail=detail@entry=0) at gsignal.c:3447 #3 0x00007ffff50a51d3 in delayed_emission (data=0x7fffb8005040) at gegl-node.c:2192
#4 0x00007ffff3a71a9a in g_main_dispatch (context=0xd42e90) at gmain.c:3148 #5 g_main_context_dispatch (context=context@entry=0xd42e90) at gmain.c:3813 #6 0x00007ffff3a71e48 in g_main_context_iterate (context=0xd42e90, block=block@entry=1, dispatch=dispatch@entry=1, self=) at gmain.c:3886
#7 0x00007ffff3a72172 in g_main_loop_run (loop=0x33289c0) at gmain.c:4082 #8 0x0000000000494612 in app_run (full_prog_name=, filenames=,
alternate_system_gimprc=alternate_system_gimprc@entry=0x0, alternate_gimprc=alternate_gimprc@entry=0x0, session_name=, batch_interpreter=0x0, batch_commands=0x0, as_new=0, no_interface=0, no_data=0, no_fonts=0, no_splash=0, be_verbose=0, use_shm=1, use_cpu_accel=1, console_messages=0, use_debug_handler=0, show_playground=1,
stack_trace_mode=GIMP_STACK_TRACE_QUERY, pdb_compat_mode=GIMP_PDB_COMPAT_WARN) at app.c:331 #9 0x0000000000493f45 in main (argc=, argv=0xc866c0) at main.c:551

I have four threads set in preferences. The image is 16bit gamma integer, and I try and stretch HSV contrast.

Thanks. This should be fixed in GEGL master:

commit e3787440917255b6936a8d55428aa9402fdfba08 Author: Ell
Date: Fri Aug 11 08:44:27 2017 -0400

gegl-node: only emit the progress signal from the main thread

Only emit the progress signal when gegl_node_progress() is called from the main thread -- don't queue a signal emission from other threads. Otherwise, the queued signal may be emitted after the operation is complete, and, in particular, after the node is destroyed (we could keep a the node alive while the signal is queued, but that's not really useful.)

Regardless, for auto-threaded ops, each thread would track its progress independently, so emitting interleaving progress signals from different threads is not too meaningful anyway, while only reporting the main thread's progress should give a good-enough indication of the overall progress.

gegl/graph/gegl-node.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)

Note that the HSV stretch contrast operation doesn't work correctly with multiple threads atm, so you're still better off using a single thread, but at least it doesn't crash anymore :)

If you run into more issues, feel free to report them through our bugzilla:

https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP

-- Ell

On 08/11/2017 04:02 AM, Tobias Ellinghaus wrote:

To make the backtrace even more useful you can use these commands in gdb once GIMP crashed (just copy&paste them over):

set pagination off set logging file gdb.txt
set logging on
where
echo \n=========\n\n
info threads
echo \n=========\n
thread apply all bt full

the result will be in the file "gdb.txt".

Useful indeed :)

--
Ell