Hi su_v, yes I saw your message in the report too. Actually I was feeling this would work your crash around when I wrote this patch. But that is still not a fix. When you open the preferences and check the Interface tab, then the language list, this list is empty now, right? Jehan On Sun, Jul 28, 2013 at 5:19 PM, su_v <suv-sf@xxxxxxxxxxxxxxxxxxxxx> wrote: > On my system (10.7.5), GIMP launches ok, but crashes when opening > the preferences. See stack trace in > <https://bugzilla.gnome.org/show_bug.cgi?id=704592#c6> > > With your patch applied (and no other local changes), GIMP still > launches ok, and now no longer crashes when opening the preferences > dialog (see attached log). > > > On 2013-07-28 05:47 +0100, Jehan Pagès 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
