Re: Gimp git on Mac Segfault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux