Sign up now! · Forgot password?
RSS/Atom feed identi.ca Twitter

missing babl fast path and lt-gimp-2.9 segfault

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

11 of 11 messages available
Toggle history

Please log in to manage your subscriptions.

missing babl fast path and lt-gimp-2.9 segfault richard brown 06 Aug 17:49
  missing babl fast path and lt-gimp-2.9 segfault Carol Spears 06 Aug 20:20
   missing babl fast path and lt-gimp-2.9 segfault richard brown 06 Aug 21:30
    missing babl fast path and lt-gimp-2.9 segfault Carol Spears 06 Aug 23:00
     missing babl fast path and lt-gimp-2.9 segfault Carol Spears 07 Aug 02:00
      missing babl fast path and lt-gimp-2.9 segfault richard brown 09 Aug 11:31
       missing babl fast path and lt-gimp-2.9 segfault Ell via gimp-developer-list 10 Aug 18:45
        missing babl fast path and lt-gimp-2.9 segfault richard brown 11 Aug 02:54
         missing babl fast path and lt-gimp-2.9 segfault Ell via gimp-developer-list 11 Aug 13:15
        missing babl fast path and lt-gimp-2.9 segfault Tobias Ellinghaus 11 Aug 08:02
         missing babl fast path and lt-gimp-2.9 segfault Ell via gimp-developer-list 11 Aug 13:17
richard brown
2017-08-06 17:49:52 UTC (4 months ago)

missing babl fast path and lt-gimp-2.9 segfault

No-one?

Carol Spears
2017-08-06 20:20:14 UTC (4 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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

richard brown
2017-08-06 21:30:21 UTC (4 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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.

Carol

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

Carol Spears
2017-08-06 23:00:27 UTC (4 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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

Carol Spears
2017-08-07 02:00:41 UTC (4 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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

richard brown
2017-08-09 11:31:03 UTC (3 months ago)

missing babl fast path and lt-gimp-2.9 segfault

On 07/08/17 03:00, Carol Spears wrote:

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

Got gdb working with it:

[New Thread 0x7fffaeffd700 (LWP 18150)] [New Thread 0x7fffae7fc700 (LWP 18151)] [New Thread 0x7fffbcbb0700 (LWP 18152)]

Thread 1 "gimp-2.9" received signal SIGSEGV, Segmentation fault. g_type_check_instance (type_instance=type_instance@entry=0x1de98880) at gtype.c:4131
4131 TypeNode *node = lookup_type_node_I (type_instance->g_class->g_type);

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.

>*Schoolboy error*<

But thanks for your help.

(The non-standard prefix stuff that I use to run gimp was outlined here if you're interested:

http://ninedegreesbelow.com/photography/build-gimp-in-prefix.html)

Ell via gimp-developer-list
2017-08-10 18:45:57 UTC (3 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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

richard brown
2017-08-11 02:54:17 UTC (3 months ago)

missing babl fast path and lt-gimp-2.9 segfault

On 10/08/17 19:45, Ell via gimp-developer-list wrote:

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
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

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.

Tobias Ellinghaus
2017-08-11 08:02:49 UTC (3 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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

Ell via gimp-developer-list
2017-08-11 13:15:59 UTC (3 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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

Ell via gimp-developer-list
2017-08-11 13:17:28 UTC (3 months ago)

missing babl fast path and lt-gimp-2.9 segfault

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