Are you using Macport? I don't use Macport and build all my dependencies from scratch. On Sun, Jul 28, 2013 at 1:19 AM, 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
