To answer the first question, here is the trace: __________________________________________________________ #0 0x00007fff8b970698 in __wait4 () #1 0x0000000101868353 in g_on_error_stack_trace () #2 0x00000001018687f2 in g_on_error_query () #3 0x000000010000ebd4 in gimp_eek () #4 0x000000010000ec48 in gimp_fatal_error () #5 0x000000010000f4a6 in gimp_sigfatal_handler () #6 <signal handler called> #7 0x00007fff8cabd6b0 in strlen () #8 0x00007fff8cb44a65 in __vfprintf () #9 0x00007fff8cb43337 in vfprintf_l () #10 0x00007fff8cb3b718 in printf () #11 0x000000010016839b in gimp_language_store_parser_init () #12 0x0000000100013965 in gui_init () #13 0x000000010000e580 in app_run () #14 0x0000000100010b14 in main () ./gimp-2.9 (pid:13928): [E]xit, [H]alt, show [S]tack trace or [P]roceed: __________________________________________________________ After I comment out line 173, no change. On Sun, Jul 28, 2013 at 12:24 AM, Jehan Pagès <jehan.marmottard@xxxxxxxxx>wrote: > Just to try into another direction: if you comment out the line: > parse_iso_codes (base_lang_list, NULL); > (line 173 in app/widgets/gimplanguagestore-parser.c) > > Do you still have the crash? And if yes, the same trace? > > Jehan > > On Sun, Jul 28, 2013 at 4:22 PM, Jehan Pagès <jehan.marmottard@xxxxxxxxx> > wrote: > > Hmmm... NULL nowhere, no strange values, nothing. Did the trace still > > say it happened at strchr() inside gimp_language_store_parser_init ()? > > > > Jehan > > > > On Sun, Jul 28, 2013 at 4:16 PM, Partha Bagchi <partha1b@xxxxxxxxx> > wrote: > >> Hi Jehan, > >> > >> Here is the output from the crash. > >> > >> Hope it's helpful. I don't see anything myself. :( > >> > >> Thanks! > >> Partha > >> > >> > >> > >> > >> On Sat, Jul 27, 2013 at 11:47 PM, Jehan Pagès < > jehan.marmottard@xxxxxxxxx> > >> wrote: > >>> > >>> Hey Partha, su_v, > >>> > >>> could you test the following patch: > >>> - copy it in your GIMP directory; > >>> - apply it with this command from the GIMP directory: > >>> patch -p0 < osx_crash.diff > >>> - compile and try again. > >>> > >>> I believe it would not fix your crash, because I did not change the > >>> calls where your traces say it happens. Problem is that it apparently > >>> crashes at strchr() but there are 5 of them in this function. Looking > >>> at what seems to be the code in MacOSX of strchr(), looks like it may > >>> be when the string is NULL, but in my code, I don't see anywhere where > >>> this is supposed to be possible. > >>> So unless you can run a debugger to know which exact strchr() line it > >>> happens at, I added some debug output in the code. Just copy paste > >>> anything which may be outputted before crash. > >>> You will most likely have a whole bunch of lines on screen because I > >>> want to cover as much ground as possible, so you can run like this: > >>> $ ./gimp-2.9 --verbose >output.txt > >>> > >>> Then send me the output.txt after the crash occurs. > >>> Thanks. > >>> > >>> Jehan > >>> > >>> > >>> On Sun, Jul 28, 2013 at 1:47 PM, Jehan Pagès < > jehan.marmottard@xxxxxxxxx> > >>> wrote: > >>> > Argh! I should nearly have a Mac just to test code there! uhuh > >>> > Let me have a look. :-) > >>> > > >>> > Jehan > >>> > > >>> > On Sun, Jul 28, 2013 at 10:39 AM, Partha Bagchi <partha1b@xxxxxxxxx> > >>> > wrote: > >>> >> Should have mentioned the segfault is related to > >>> >> gimp_language_store_parser_init () > >>> >> > >>> >> > __________________________________________________________________________ > >>> >> ./gimp-2.9 --verbose > >>> >> Cannot spawn a message bus without a machine-id: Unable to load > >>> >> /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file > >>> >> '/var/lib/dbus/machine-id': No such file or directory > >>> >> This is a development version of GIMP. Debug messages may appear > here. > >>> >> > >>> >> INIT: gimp_load_config > >>> >> Parsing '/Users/partha/Library/Application Support/GIMP/2.9/unitrc' > >>> >> Parsing > >>> >> > >>> >> > '/Users/partha/projects/src/gimp/Gimp-2.9.app/Contents/Resources/etc/gimp/2.0/gimprc' > >>> >> Parsing '/Users/partha/Library/Application Support/GIMP/2.9/gimprc' > >>> >> ./gimp-2.9: fatal error: Segmentation fault: 11 > >>> >> ./gimp-2.9 (pid:63964): [E]xit, [H]alt, show [S]tack trace or > >>> >> [P]roceed: S > >>> >> #0 0x00007fff8b970698 in __wait4 () > >>> >> #1 0x0000000101868353 in g_on_error_stack_trace () > >>> >> #2 0x00000001018687f2 in g_on_error_query () > >>> >> #3 0x000000010000dee4 in gimp_eek () > >>> >> #4 0x000000010000df58 in gimp_fatal_error () > >>> >> #5 0x000000010000e7b6 in gimp_sigfatal_handler () > >>> >> #6 <signal handler called> > >>> >> #7 0x00007fff8cb0a60b in strchr () > >>> >> #8 0x0000000100167614 in gimp_language_store_parser_init () > >>> >> #9 0x0000000100012c75 in gui_init () > >>> >> #10 0x000000010000d890 in app_run () > >>> >> #11 0x000000010000fe24 in main () > >>> >> > >>> >> > __________________________________________________________________________ > >>> >> > >>> >> Thanks, > >>> >> Partha > >>> >> > >>> >> > >>> >> On Sat, Jul 27, 2013 at 3:01 PM, Partha Bagchi <partha1b@xxxxxxxxx> > >>> >> wrote: > >>> >>> > >>> >>> Jehan, > >>> >>> > >>> >>> Looks like the segfault is back? > >>> >>> > >>> >>> Thanks, > >>> >>> Partha > >>> >>> > >>> >>> > >>> >>> > >>> >>> On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi <partha1b@xxxxxxxxx > > > >>> >>> wrote: > >>> >>>> > >>> >>>> Jehan, > >>> >>>> > >>> >>>> Thumbs up! All good now. It didn't crash and I was able to open > >>> >>>> images > >>> >>>> etc. > >>> >>>> > >>> >>>> Thanks again, > >>> >>>> Partha > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> On Thu, Jul 18, 2013 at 10:56 PM, Jehan Pagès > >>> >>>> <jehan.marmottard@xxxxxxxxx> wrote: > >>> >>>>> > >>> >>>>> Hey Partha, > >>> >>>>> > >>> >>>>> you can pull and test now. I made a simple commit where I only > take > >>> >>>>> care of the unset env variable issue. Hopefully this will fix the > >>> >>>>> OSX > >>> >>>>> crash. I'll handle the other issue I discovered about not being > >>> >>>>> thread-safe later. > >>> >>>>> Tell me how it goes. :-) > >>> >>>>> > >>> >>>>> Jehan > >>> >>>>> > >>> >>>>> On Fri, Jul 19, 2013 at 11:26 AM, Jehan Pagès > >>> >>>>> <jehan.marmottard@xxxxxxxxx> wrote: > >>> >>>>> > Partha, > >>> >>>>> > > >>> >>>>> > nothing pushed yet. I'll do this and send a message. :-) > >>> >>>>> > > >>> >>>>> > Jehan > >>> >>>>> > > >>> >>>>> > On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi > >>> >>>>> > <partha1b@xxxxxxxxx> > >>> >>>>> > wrote: > >>> >>>>> >> Jehan, > >>> >>>>> >> > >>> >>>>> >> Do you want me to go ahead test the current code or wait for > you > >>> >>>>> >> to > >>> >>>>> >> add > >>> >>>>> >> additional logic? > >>> >>>>> >> > >>> >>>>> >> Thanks! > >>> >>>>> >> Partha > >>> >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > >>> >>>>> >> On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès > >>> >>>>> >> <jehan.marmottard@xxxxxxxxx> > >>> >>>>> >> wrote: > >>> >>>>> >>> > >>> >>>>> >>> Hi, > >>> >>>>> >>> > >>> >>>>> >>> I searched a little more though, and it seems on BSDs, hence > on > >>> >>>>> >>> OSX, > >>> >>>>> >>> indeed setenv with a NULL value could crash the program. The > >>> >>>>> >>> setenv > >>> >>>>> >>> in > >>> >>>>> >>> GNU libc on the other hand perfectly handles the case > >>> >>>>> >>> explicitly. > >>> >>>>> >>> So obviously when I see this kind of code (note I am not 100% > >>> >>>>> >>> sure > >>> >>>>> >>> this is the code for Darwin on Mountain Lion but I can't > find a > >>> >>>>> >>> reference linking the libc numbers there and the Darwin > version > >>> >>>>> >>> 10.8, > >>> >>>>> >>> but I assume that should be a similar code): > >>> >>>>> >>> > >>> >>>>> >>> > >>> >>>>> >>> > >>> >>>>> >>> > http://www.opensource.apple.com/source/Libc/Libc-825.26/stdlib/FreeBSD/setenv.c > >>> >>>>> >>> > >>> >>>>> >>> Before any test on the value pointer, it dereferences it > (which > >>> >>>>> >>> is > >>> >>>>> >>> undefined!), and read the content of the non-existing first > >>> >>>>> >>> character > >>> >>>>> >>> of the NULL string (which I assume would crash!): > >>> >>>>> >>> > >>> >>>>> >>> if (*value == '=') /* no `=' in value */ > >>> >>>>> >>> ++value; > >>> >>>>> >>> > >>> >>>>> >>> I don't know what is the policy on BSD but I thought they > were > >>> >>>>> >>> very > >>> >>>>> >>> keen on security, but this code does not look very sane to > me. > >>> >>>>> >>> So yeah anyway that's a problem too in the end. I'll deal > with > >>> >>>>> >>> it. > >>> >>>>> >>> > >>> >>>>> >>> Jehan > >>> >>>>> >>> > >>> >>>>> >>> > >>> >>>>> >>> On Fri, Jul 19, 2013 at 7:14 AM, Partha Bagchi > >>> >>>>> >>> <partha1b@xxxxxxxxx> > >>> >>>>> >>> wrote: > >>> >>>>> >>> > Jehan, > >>> >>>>> >>> > > >>> >>>>> >>> > I will test it tomorrow. I will get back to you with the > >>> >>>>> >>> > results. > >>> >>>>> >>> > > >>> >>>>> >>> > Thanks for your prompt response! > >>> >>>>> >>> > > >>> >>>>> >>> > Partha > >>> >>>>> >>> > > >>> >>>>> >>> > > >>> >>>>> >>> > > >>> >>>>> >>> > On Thu, Jul 18, 2013 at 11:42 AM, Jehan Pagès > >>> >>>>> >>> > <jehan.marmottard@xxxxxxxxx> > >>> >>>>> >>> > wrote: > >>> >>>>> >>> >> > >>> >>>>> >>> >> Hi again, > >>> >>>>> >>> >> > >>> >>>>> >>> >> I have some working code in my working branch now where I > >>> >>>>> >>> >> applied > >>> >>>>> >>> >> the > >>> >>>>> >>> >> concepts I wrote about (basically initializing the > language > >>> >>>>> >>> >> store > >>> >>>>> >>> >> only > >>> >>>>> >>> >> once and at the very start of the program, before any > >>> >>>>> >>> >> threading > >>> >>>>> >>> >> would > >>> >>>>> >>> >> occur hopefully). > >>> >>>>> >>> >> Don't know if that will be the finale code, but should be > at > >>> >>>>> >>> >> least > >>> >>>>> >>> >> good enough to test on OSX (I don't have access to a OSX > >>> >>>>> >>> >> machine > >>> >>>>> >>> >> to > >>> >>>>> >>> >> reproduce the bug myself and see if this indeed fixes the > >>> >>>>> >>> >> issue). > >>> >>>>> >>> >> As > >>> >>>>> >>> >> soon as the report is up, I'll upload the patch there so > that > >>> >>>>> >>> >> someone > >>> >>>>> >>> >> with OSX can test it and tell me if that fixes it. :-) > >>> >>>>> >>> >> Thanks. > >>> >>>>> >>> >> > >>> >>>>> >>> >> Jehan > >>> >>>>> >>> >> > >>> >>>>> >>> >> > >>> >>>>> >>> >> On Thu, Jul 18, 2013 at 9:47 PM, Jehan Pagès > >>> >>>>> >>> >> <jehan.marmottard@xxxxxxxxx> > >>> >>>>> >>> >> wrote: > >>> >>>>> >>> >> > Hey all, > >>> >>>>> >>> >> > > >>> >>>>> >>> >> > it seems I am the culprit for this bug. I don't have > this > >>> >>>>> >>> >> > crash > >>> >>>>> >>> >> > on > >>> >>>>> >>> >> > Linux > >>> >>>>> >>> >> > though. > >>> >>>>> >>> >> > > >>> >>>>> >>> >> > It looks like the implementation of setenv/getenv is > >>> >>>>> >>> >> > different > >>> >>>>> >>> >> > on > >>> >>>>> >>> >> > OSX. > >>> >>>>> >>> >> > According to glib doc, the problem may be that on some > >>> >>>>> >>> >> > implementations, successive calls may use the same > buffer. > >>> >>>>> >>> >> > I > >>> >>>>> >>> >> > guess > >>> >>>>> >>> >> > that's the case on OSX. And also these calls are not > >>> >>>>> >>> >> > thread-safe. > >>> >>>>> >>> >> > Also > >>> >>>>> >>> >> > the fact that there is no LANGUAGE env variable should > >>> >>>>> >>> >> > normally > >>> >>>>> >>> >> > not > >>> >>>>> >>> >> > be > >>> >>>>> >>> >> > a real problem. I don't have this variable set on my > system > >>> >>>>> >>> >> > either > >>> >>>>> >>> >> > and, as I said, no crash here. I guess this brought the > >>> >>>>> >>> >> > real > >>> >>>>> >>> >> > issue of > >>> >>>>> >>> >> > the OSX getenv/setenv implementation into light though. > >>> >>>>> >>> >> > > >>> >>>>> >>> >> > In any case, I think that the real solution is to have > the > >>> >>>>> >>> >> > list > >>> >>>>> >>> >> > of > >>> >>>>> >>> >> > all > >>> >>>>> >>> >> > localized languages generated at startup, before any > thread > >>> >>>>> >>> >> > or > >>> >>>>> >>> >> > anything happens (I just saw that's also what glib doc > >>> >>>>> >>> >> > says: we > >>> >>>>> >>> >> > should > >>> >>>>> >>> >> > only use these calls on startup before any thread > happens). > >>> >>>>> >>> >> > Then we > >>> >>>>> >>> >> > just use this pre-generated list each time it is > needed. I > >>> >>>>> >>> >> > was > >>> >>>>> >>> >> > already > >>> >>>>> >>> >> > thinking that the current design was bad anyway, > because we > >>> >>>>> >>> >> > are > >>> >>>>> >>> >> > basically parsing a huge file of language codes and > names > >>> >>>>> >>> >> > each > >>> >>>>> >>> >> > time > >>> >>>>> >>> >> > we > >>> >>>>> >>> >> > open the preference dialog! Such a waste of resources > and > >>> >>>>> >>> >> > time. > >>> >>>>> >>> >> > I did not modify it at the time because I did not feel > like > >>> >>>>> >>> >> > using > >>> >>>>> >>> >> > more > >>> >>>>> >>> >> > time towards this, but I guess that should be the > occasion > >>> >>>>> >>> >> > to > >>> >>>>> >>> >> > do it. > >>> >>>>> >>> >> > > >>> >>>>> >>> >> > In any case, please fill a bug report and I'll have a > look! > >>> >>>>> >>> >> > :-) > >>> >>>>> >>> >> > > >>> >>>>> >>> >> > Jehan > >>> >>>>> >>> >> > > >>> >>>>> >>> >> > > >>> >>>>> >>> >> > On Thu, Jul 18, 2013 at 6:31 AM, Partha Bagchi > >>> >>>>> >>> >> > <partha1b@xxxxxxxxx> > >>> >>>>> >>> >> > wrote: > >>> >>>>> >>> >> >> Hey V, > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >> Thanks for checking on this. I am glad (in a way) that > my > >>> >>>>> >>> >> >> system is > >>> >>>>> >>> >> >> not > >>> >>>>> >>> >> >> the > >>> >>>>> >>> >> >> only one having this issue! :) > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >> I will try to revert the above changes and see if the > >>> >>>>> >>> >> >> problem > >>> >>>>> >>> >> >> disappears. > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >> Partha > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >> On Wed, Jul 17, 2013 at 7:51 AM, su_v > >>> >>>>> >>> >> >> <suv-sf@xxxxxxxxxxxxxxxxxxxxx> > >>> >>>>> >>> >> >> wrote: > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >>> On 2013-07-17 01:19 +0100, Partha Bagchi wrote: > >>> >>>>> >>> >> >>> > My recent (last built a few moment ago) git builds > >>> >>>>> >>> >> >>> > (2.9) > >>> >>>>> >>> >> >>> > have > >>> >>>>> >>> >> >>> > been > >>> >>>>> >>> >> >>> > instantly segfaulting on MBR running Mountain Lion. > >>> >>>>> >>> >> >>> > > >>> >>>>> >>> >> >>> > gdb backtrace (or commandline execution) shows: > >>> >>>>> >>> >> >>> > ./gimp-2.9 (pid:42315): [E]xit, [H]alt, show [S]tack > >>> >>>>> >>> >> >>> > trace > >>> >>>>> >>> >> >>> > or > >>> >>>>> >>> >> >>> > [P]roceed: > >>> >>>>> >>> >> >>> S > >>> >>>>> >>> >> >>> > #0 0x00007fff8b257698 in __wait4 () > >>> >>>>> >>> >> >>> > #1 0x00000001018de353 in g_on_error_stack_trace () > >>> >>>>> >>> >> >>> > #2 0x00000001018de7f2 in g_on_error_query () > >>> >>>>> >>> >> >>> > #3 0x000000010000fa54 in gimp_eek () > >>> >>>>> >>> >> >>> > #4 0x000000010000fac8 in gimp_fatal_error () > >>> >>>>> >>> >> >>> > #5 0x0000000100010326 in gimp_sigfatal_handler () > >>> >>>>> >>> >> >>> > #6 <signal handler called> > >>> >>>>> >>> >> >>> > #7 0x00007fff8c40887e in setenv () > >>> >>>>> >>> >> >>> > #8 0x00000001018f76cf in g_setenv () > >>> >>>>> >>> >> >>> > #9 0x0000000100168c11 in > gimp_language_store_self_l10n > >>> >>>>> >>> >> >>> > () > >>> >>>>> >>> >> >>> > #10 0x0000000101915c99 in emit_start_element () > >>> >>>>> >>> >> >>> > #11 0x00000001019170b0 in > g_markup_parse_context_parse > >>> >>>>> >>> >> >>> > () > >>> >>>>> >>> >> >>> > #12 0x000000010035a7ba in > >>> >>>>> >>> >> >>> > gimp_xml_parser_parse_io_channel > >>> >>>>> >>> >> >>> > () > >>> >>>>> >>> >> >>> > #13 0x000000010035a9ab in > gimp_xml_parser_parse_file () > >>> >>>>> >>> >> >>> > #14 0x0000000100168f71 in > >>> >>>>> >>> >> >>> > gimp_language_store_parse_iso_codes () > >>> >>>>> >>> >> >>> > #15 0x000000010188619b in g_object_new_internal () > >>> >>>>> >>> >> >>> > #16 0x0000000101886cdd in g_object_newv () > >>> >>>>> >>> >> >>> > #17 0x0000000101886edc in g_object_new () > >>> >>>>> >>> >> >>> > #18 0x0000000100168025 in gimp_language_entry_new () > >>> >>>>> >>> >> >>> > #19 0x000000010017cc00 in > gimp_prop_language_entry_new > >>> >>>>> >>> >> >>> > () > >>> >>>>> >>> >> >>> > #20 0x00000001000a3df2 in gimp_text_options_gui () > >>> >>>>> >>> >> >>> > #21 0x000000010005e9e6 in gimp_tools_restore () > >>> >>>>> >>> >> >>> > #22 0x000000010001428b in gui_restore_callback () > >>> >>>>> >>> >> >>> > #23 0x000000010187dd0d in g_closure_invoke () > >>> >>>>> >>> >> >>> > #24 0x000000010189483b in signal_emit_unlocked_R () > >>> >>>>> >>> >> >>> > #25 0x0000000101897111 in g_signal_emit_valist () > >>> >>>>> >>> >> >>> > #26 0x0000000101897964 in g_signal_emit () > >>> >>>>> >>> >> >>> > #27 0x000000010000f2fe in app_run () > >>> >>>>> >>> >> >>> > #28 0x0000000100011994 in main () > >>> >>>>> >>> >> >>> > > >>> >>>>> >>> >> >>> > and gimp-2.9 --verbose > >>> >>>>> >>> >> >>> > ... > >>> >>>>> >>> >> >>> > Parsing '/Users/partha/Library/Application > >>> >>>>> >>> >> >>> > Support/GIMP/2.9/tool-options/gimp-text-tool' > >>> >>>>> >>> >> >>> > ./gimp-2.9: fatal error: Segmentation fault: 11 > >>> >>>>> >>> >> >>> > ./gimp-2.9 (pid:42330): [E]xit, [H]alt, show [S]tack > >>> >>>>> >>> >> >>> > trace > >>> >>>>> >>> >> >>> > or > >>> >>>>> >>> >> >>> > [P]roceed: > >>> >>>>> >>> >> >>> > > >>> >>>>> >>> >> >>> > Is anyone else on the Mac having this issue? Should > I > >>> >>>>> >>> >> >>> > file > >>> >>>>> >>> >> >>> > a > >>> >>>>> >>> >> >>> > bug-report? > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> Reproduced (same stack trace) on MBR (13-inch, Late > 2011) > >>> >>>>> >>> >> >>> running > >>> >>>>> >>> >> >>> OS X > >>> >>>>> >>> >> >>> 10.7.5; dependencies for GIMP installed via MacPorts > >>> >>>>> >>> >> >>> (custom > >>> >>>>> >>> >> >>> portfiles > >>> >>>>> >>> >> >>> for babl, gegl and GIMP git master). > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> Workaround (at least for this segfault at launch > time) is > >>> >>>>> >>> >> >>> to > >>> >>>>> >>> >> >>> run > >>> >>>>> >>> >> >>> GIMP > >>> >>>>> >>> >> >>> like this: > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> $ echo $LANG > >>> >>>>> >>> >> >>> en_US.UTF-8 > >>> >>>>> >>> >> >>> $ LANGUAGE="$LANG" gimp --verbose > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> Possibly related to the changes in > >>> >>>>> >>> >> >>> < > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > https://git.gnome.org/browse/gimp/commit/?id=f6dcde1ee66fda4dfdc063022c4d2e901adb9a71 > >>> >>>>> >>> >> >>> > > >>> >>>>> >>> >> >>> < > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > https://git.gnome.org/browse/gimp/commit/?id=4eecd9b4ac71615f10819378938dcdce7e531167 > >>> >>>>> >>> >> >>> > > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> hth, V > >>> >>>>> >>> >> >>> _______________________________________________ > >>> >>>>> >>> >> >>> gimp-developer-list mailing list > >>> >>>>> >>> >> >>> List address: gimp-developer-list@xxxxxxxxx > >>> >>>>> >>> >> >>> List membership: > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >>> > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > >>> >>>>> >>> >> >>> > >>> >>>>> >>> >> >> _______________________________________________ > >>> >>>>> >>> >> >> gimp-developer-list mailing list > >>> >>>>> >>> >> >> List address: gimp-developer-list@xxxxxxxxx > >>> >>>>> >>> >> >> List membership: > >>> >>>>> >>> >> >> > >>> >>>>> >>> >> >> > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > >>> >>>>> >>> > > >>> >>>>> >>> > > >>> >>>>> >> > >>> >>>>> >> > >>> >>>> > >>> >>>> > >>> >>> > >>> >> > >> > >> > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
