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
