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 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Wed, 2013-07-17 at 17:31 -0400, Partha Bagchi 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.

This is most certainly due to the new language string translations, please file a bug.

--Mitch

Partha

On Wed, Jul 17, 2013 at 7:51 AM, su_v 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Sounds good. I will file a bug.

Thanks, Partha

On Thu, Jul 18, 2013 at 8:40 AM, Michael Natterer wrote:

On Wed, 2013-07-17 at 17:31 -0400, Partha Bagchi 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.

This is most certainly due to the new language string translations, please file a bug.

--Mitch

Partha

On Wed, Jul 17, 2013 at 7:51 AM, su_v

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 Pags 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 Pags 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

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

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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 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 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 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 Pags 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 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 Pags <

jehan.marmottard@gmail.com>

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 Pags <

jehan.marmottard@gmail.com>

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 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 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Partha,

nothing pushed yet. I'll do this and send a message. :-)

Jehan

On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi 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 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 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

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

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 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 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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 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 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

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

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 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 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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 Pags 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 Pags 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

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 Pags <

jehan.marmottard@gmail.com>

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

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 Pags

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 Pags

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@gmail.com>

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@users.sourceforge.net>

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi 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 Pags 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 Pags 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

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 Pags <

jehan.marmottard@gmail.com>

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

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 Pags

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 Pags

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@gmail.com>

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@users.sourceforge.net>

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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  
#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  wrote:

> Jehan,
>
> Looks like the segfault is back?
>
> Thanks,
> Partha
>
>
>
> On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi  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 Pags > > 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 Pags
>>>  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 
>>> 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 Pags <
>>> jehan.marmottard@gmail.com>
>>> >> 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 
>>> 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 Pags
>>> >>> > 
>>> >>> > 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 Pags
>>> >>> >> 
>>> >>> >> 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@gmail.com>
>>> >>> >> > 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@users.sourceforge.net>
>>> >>> >> >> 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  
>>> >>> >> >>> > #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@gnome.org
>>> >>> >> >>> List membership:
>>> >>> >> >>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>> >>> >> >>>
>>> >>> >> >> _______________________________________________
>>> >>> >> >> gimp-developer-list mailing list
>>> >>> >> >> List address:    gimp-developer-list@gnome.org
>>> >>> >> >> List membership:
>>> >>> >> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>> >>> >
>>> >>> >
>>> >>
>>> >>
>>>
>>
>>
>

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 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
#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 wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi 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 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 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 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

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 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

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

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

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

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Well, not to worry. I have a Mac handy and willing to test. :)

Good news for you is that if I comment out gimp_language_store_parser_init() in gui.c, Gimp compiles and runs fine without language support of course.

Thanks, Partha

On Sat, Jul 27, 2013 at 9:47 PM, Jehan Pags 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 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
#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

wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi

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 Pags 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 Pags 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

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 Pags

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@gmail.com>

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 Pags

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 Pags

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

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

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
#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@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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
#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 wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi 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 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 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 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

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 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

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

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

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

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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

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
#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

wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi

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 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 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@gmail.com>

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

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@gmail.com>

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

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

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

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

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
#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@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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 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 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
#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 wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi 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 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 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

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

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

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

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

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

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

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
#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@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 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 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 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 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 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
#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 wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi 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 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 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

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

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

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

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

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

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

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
#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@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:

https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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  
#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 Pags 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 Pags 
> 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 
> 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 Pags <
> jehan.marmottard@gmail.com>
> >> 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 Pags <
> jehan.marmottard@gmail.com>
> >>> 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 
> >>> > 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  
> >>> >> #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 
> >>> >> wrote:
> >>> >>>
> >>> >>> Jehan,
> >>> >>>
> >>> >>> Looks like the segfault is back?
> >>> >>>
> >>> >>> Thanks,
> >>> >>> Partha
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi  >
> >>> >>> 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 Pags
> >>> >>>>  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 Pags
> >>> >>>>>  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
> >>> >>>>> > 
> >>> >>>>> > 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 Pags
> >>> >>>>> >> 
> >>> >>>>> >> 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
> >>> >>>>> >>> 
> >>> >>>>> >>> 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 Pags
> >>> >>>>> >>> > 
> >>> >>>>> >>> > 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 Pags
> >>> >>>>> >>> >> 
> >>> >>>>> >>> >> 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
> >>> >>>>> >>> >> > 
> >>> >>>>> >>> >> > 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
> >>> >>>>> >>> >> >> 
> >>> >>>>> >>> >> >> 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  
> >>> >>>>> >>> >> >>> > #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@gnome.org
> >>> >>>>> >>> >> >>> List membership:
> >>> >>>>> >>> >> >>>
> >>> >>>>> >>> >> >>>
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >>> >>>>> >>> >> >>>
> >>> >>>>> >>> >> >> _______________________________________________
> >>> >>>>> >>> >> >> gimp-developer-list mailing list
> >>> >>>>> >>> >> >> List address:    gimp-developer-list@gnome.org
> >>> >>>>> >>> >> >> List membership:
> >>> >>>>> >>> >> >>
> >>> >>>>> >>> >> >>
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >>> >>>>> >>> >
> >>> >>>>> >>> >
> >>> >>>>> >>
> >>> >>>>> >>
> >>> >>>>
> >>> >>>>
> >>> >>>
> >>> >>
> >>
> >>
>

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 wrote:

On my system (10.7.5), GIMP launches ok, but crashes when opening the preferences. See stack trace in

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 Pags 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 Pags

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

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
#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

wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi

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 Pags 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 Pags 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@gmail.com>

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 Pags

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@gmail.com>

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 Pags

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 Pags

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

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

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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 wrote:

On my system (10.7.5), GIMP launches ok, but crashes when opening the preferences. See stack trace in

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 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 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
#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 wrote:

Jehan,

Looks like the segfault is back?

Thanks, Partha

On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi 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 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 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 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

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 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

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

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

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

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
#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@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi,

On Sun, Jul 28, 2013 at 5:42 PM, su_v wrote:

On 2013-07-28 07:32 +0100, Jehan Pagès wrote:

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?

No, it lists all languages.

Hmmm... ok. So it lists them all of them, nicely displayed "language name [code]" as usual?

On 2013-07-28 07:31 +0100, Partha Bagchi wrote:

Are you using Macport? I don't use Macport and build all my dependencies from scratch.

Yes, I use MacPorts for the dependencies.

What is MacPorts? Is it like a package manager for Mac?

Also I see you run the command "gimp-git.sh quartz". Is there something particular you do in this script? Also why the "quartz"? Can you like switch backend at startup or something (not even at compilation?)? Like between X11 and quartz? How does this work under OSX, I heard there is X11 too, so are there layers running on each other? Concurrent systems and you can use one or the other?

Jehan

[ fullquote below trimmed to avoid moderation ]

On Sun, Jul 28, 2013 at 5:19 PM, su_v wrote:

On my system (10.7.5), GIMP launches ok, but crashes when opening the preferences. See stack trace in

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

As of night, the crash still occurred. Jehan, is there a new patch?

Thanks, Partha

On Sun, Jul 28, 2013 at 2:57 AM, su_v wrote:

On 2013-07-28 08:03 +0100, Jehan Pags wrote:

Hi,

On Sun, Jul 28, 2013 at 5:42 PM, su_v

wrote:

On 2013-07-28 07:32 +0100, Jehan Pags wrote:

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?

No, it lists all languages.

Hmmm... ok. So it lists them all of them, nicely displayed "language name [code]" as usual?

Screenshot here
<
https://www.dropbox.com/s/6haa2tq0vow3u29/gimp-013c9d3-patched-prefs-languages-1.png

On 2013-07-28 07:31 +0100, Partha Bagchi wrote:

Are you using Macport? I don't use Macport and build all my dependencies from scratch.

Yes, I use MacPorts for the dependencies.

What is MacPorts? Is it like a package manager for Mac?

Yes:

Also I see you run the command "gimp-git.sh quartz". Is there something particular you do in this script?

Since I install into a custom prefix, it mainly sets $PATH accordingly. The script was originally based on the launch script described here:

There is no difference whether I launch the gimp-2.9 binary directly, or with the script: same result (crash unpatched, no crash with patch).

Also why the "quartz"? Can you like switch backend at startup or something (not even at compilation?)? Like between X11 and quartz? How does this work under OSX, I heard there is X11 too, so are there layers running on each other? Concurrent systems and you can use one or the other?

I have two MacPorts trees installed into custom prefixes, one with GTK+ compiled using the Quartz backend (native backend for OS X), one with the X11 backend ("legacy" backend on OS X: all GTK+ apps require to run under X11/XQuartz).
For GIMP I use two local git clones - one for building with Quartz-based dependencies, one for building with X11-based dependencies. They both are configured to install into different prefixes. The launch script just sets $PATH for gimp-2.9 accordingly, depending on the command line argument given (quartz, x11).

AFAICT the backend is not relevant for this issue: the crash is the same with unpatched builds, independent of the GTK+ backend used. I only built GIMP with the X11 backend (and integrated it as command line option in the script) because I wanted to compare the redraw performance between the two backends [1].

Note: Above build setup has a lot of rendundant packages installed, because with GTK2 one cannot have multiple backends compiled in. I maintain it for building & testing Inkscape, and thus can easily reuse it to test local builds of GIMP 2.8 & GIMP 2.9 (git master).

[1] see footnote in

On Sun, Jul 28, 2013 at 5:19 PM, su_v

wrote:

On my system (10.7.5), GIMP launches ok, but crashes when opening the preferences. See stack trace in

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 Pags 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

Hi,

On Sun, Jul 28, 2013 at 11:51 PM, Partha Bagchi wrote:

As of night, the crash still occurred. Jehan, is there a new patch?

Sorry Partha, I went out. I am kind of a particular timezone (New Zealand). I just realized I completely misused a macro. That may have been the issue, even though it did not show on my platform. Could you please try the attached patch please? Of course remove the previous one first ("git checkout -- ." to clean out your git repository, so that with a "git status", it should list no modified files).
Thanks.

Jehan

Thanks,
Partha

On Sun, Jul 28, 2013 at 2:57 AM, su_v wrote:

On 2013-07-28 08:03 +0100, Jehan Pagès wrote:

Hi,

On Sun, Jul 28, 2013 at 5:42 PM, su_v wrote:

On 2013-07-28 07:32 +0100, Jehan Pagès wrote:

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?

No, it lists all languages.

Hmmm... ok. So it lists them all of them, nicely displayed "language name [code]" as usual?

Screenshot here

On 2013-07-28 07:31 +0100, Partha Bagchi wrote:

Are you using Macport? I don't use Macport and build all my dependencies from scratch.

Yes, I use MacPorts for the dependencies.

What is MacPorts? Is it like a package manager for Mac?

Yes:

Also I see you run the command "gimp-git.sh quartz". Is there something particular you do in this script?

Since I install into a custom prefix, it mainly sets $PATH accordingly. The script was originally based on the launch script described here:

There is no difference whether I launch the gimp-2.9 binary directly, or with the script: same result (crash unpatched, no crash with patch).

Also why the "quartz"? Can you like switch backend at startup or something (not even at compilation?)? Like between X11 and quartz? How does this work under OSX, I heard there is X11 too, so are there layers running on each other? Concurrent systems and you can use one or the other?

I have two MacPorts trees installed into custom prefixes, one with GTK+ compiled using the Quartz backend (native backend for OS X), one with the X11 backend ("legacy" backend on OS X: all GTK+ apps require to run under X11/XQuartz).
For GIMP I use two local git clones - one for building with Quartz-based dependencies, one for building with X11-based dependencies. They both are configured to install into different prefixes. The launch script just sets $PATH for gimp-2.9 accordingly, depending on the command line argument given (quartz, x11).

AFAICT the backend is not relevant for this issue: the crash is the same with unpatched builds, independent of the GTK+ backend used. I only built GIMP with the X11 backend (and integrated it as command line option in the script) because I wanted to compare the redraw performance between the two backends [1].

Note: Above build setup has a lot of rendundant packages installed, because with GTK2 one cannot have multiple backends compiled in. I maintain it for building & testing Inkscape, and thus can easily reuse it to test local builds of GIMP 2.8 & GIMP 2.9 (git master).

[1] see footnote in

On Sun, Jul 28, 2013 at 5:19 PM, su_v wrote:

On my system (10.7.5), GIMP launches ok, but crashes when opening the preferences. See stack trace in

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

Sorry Jehan, didn't mean to "bug" you. :) Didn't realize you are in NZ.

Yes, all is good now. The crash is history!!

Thanks so much! Partha

On Sun, Jul 28, 2013 at 8:07 AM, Jehan Pags wrote:

Hi,

On Sun, Jul 28, 2013 at 11:51 PM, Partha Bagchi wrote:

As of night, the crash still occurred. Jehan, is there a new patch?

Sorry Partha, I went out. I am kind of a particular timezone (New Zealand). I just realized I completely misused a macro. That may have been the issue, even though it did not show on my platform. Could you please try the attached patch please? Of course remove the previous one first ("git checkout -- ." to clean out your git repository, so that with a "git status", it should list no modified files).
Thanks.

Jehan

Thanks,
Partha

On Sun, Jul 28, 2013 at 2:57 AM, su_v

wrote:

On 2013-07-28 08:03 +0100, Jehan Pags wrote:

Hi,

On Sun, Jul 28, 2013 at 5:42 PM, su_v wrote:

On 2013-07-28 07:32 +0100, Jehan Pags wrote:

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?

No, it lists all languages.

Hmmm... ok. So it lists them all of them, nicely displayed "language name [code]" as usual?

Screenshot here

<

https://www.dropbox.com/s/6haa2tq0vow3u29/gimp-013c9d3-patched-prefs-languages-1.png

On 2013-07-28 07:31 +0100, Partha Bagchi wrote:

Are you using Macport? I don't use Macport and build all my dependencies from scratch.

Yes, I use MacPorts for the dependencies.

What is MacPorts? Is it like a package manager for Mac?

Yes:

Also I see you run the command "gimp-git.sh quartz". Is there something particular you do in this script?

Since I install into a custom prefix, it mainly sets $PATH accordingly. The script was originally based on the launch script described here:

There is no difference whether I launch the gimp-2.9 binary directly, or with the script: same result (crash unpatched, no crash with patch).

Also why the "quartz"? Can you like switch backend at startup or something (not even at compilation?)? Like between X11 and quartz? How does this work under OSX, I heard there is X11 too, so are there layers running on each other? Concurrent systems and you can use one or the other?

I have two MacPorts trees installed into custom prefixes, one with GTK+ compiled using the Quartz backend (native backend for OS X), one with the X11 backend ("legacy" backend on OS X: all GTK+ apps require to run under X11/XQuartz).
For GIMP I use two local git clones - one for building with Quartz-based dependencies, one for building with X11-based dependencies. They both are configured to install into different prefixes. The launch script just sets $PATH for gimp-2.9 accordingly, depending on the command line argument given (quartz, x11).

AFAICT the backend is not relevant for this issue: the crash is the same with unpatched builds, independent of the GTK+ backend used. I only built GIMP with the X11 backend (and integrated it as command line option in the script) because I wanted to compare the redraw performance between the two backends [1].

Note: Above build setup has a lot of rendundant packages installed, because with GTK2 one cannot have multiple backends compiled in. I maintain it for building & testing Inkscape, and thus can easily reuse it to test local builds of GIMP 2.8 & GIMP 2.9 (git master).

[1] see footnote in

On Sun, Jul 28, 2013 at 5:19 PM, su_v

wrote:

On my system (10.7.5), GIMP launches ok, but crashes when opening the preferences. See stack trace in

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 Pags 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

Hi,

On Mon, Jul 29, 2013 at 1:28 AM, Partha Bagchi wrote:

Sorry Jehan, didn't mean to "bug" you. :) Didn't realize you are in NZ.

No prob. I prefer these kind of annoying crashes gone as soon as possible myself! ;-)

Yes, all is good now. The crash is history!!

Cool! I'll push this then. :-)

Jehan

Thanks so much!
Partha

On Sun, Jul 28, 2013 at 8:07 AM, Jehan Pagès wrote:

Hi,

On Sun, Jul 28, 2013 at 11:51 PM, Partha Bagchi wrote:

As of night, the crash still occurred. Jehan, is there a new patch?

Sorry Partha, I went out. I am kind of a particular timezone (New Zealand).
I just realized I completely misused a macro. That may have been the issue, even though it did not show on my platform. Could you please try the attached patch please? Of course remove the previous one first ("git checkout -- ." to clean out your git repository, so that with a "git status", it should list no modified files).
Thanks.

Jehan

Thanks,
Partha

On Sun, Jul 28, 2013 at 2:57 AM, su_v wrote:

On 2013-07-28 08:03 +0100, Jehan Pagès wrote:

Hi,

On Sun, Jul 28, 2013 at 5:42 PM, su_v wrote:

On 2013-07-28 07:32 +0100, Jehan Pagès wrote:

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?

No, it lists all languages.

Hmmm... ok. So it lists them all of them, nicely displayed "language name [code]" as usual?

Screenshot here

On 2013-07-28 07:31 +0100, Partha Bagchi wrote:

Are you using Macport? I don't use Macport and build all my dependencies from scratch.

Yes, I use MacPorts for the dependencies.

What is MacPorts? Is it like a package manager for Mac?

Yes:

Also I see you run the command "gimp-git.sh quartz". Is there something particular you do in this script?

Since I install into a custom prefix, it mainly sets $PATH accordingly. The script was originally based on the launch script described here:

There is no difference whether I launch the gimp-2.9 binary directly, or
with the script: same result (crash unpatched, no crash with patch).

Also why the "quartz"? Can you like switch backend at startup or something (not even at compilation?)? Like between X11 and quartz? How
does this work under OSX, I heard there is X11 too, so are there layers running on each other? Concurrent systems and you can use one or the other?

I have two MacPorts trees installed into custom prefixes, one with GTK+ compiled using the Quartz backend (native backend for OS X), one with the X11 backend ("legacy" backend on OS X: all GTK+ apps require to run under X11/XQuartz).
For GIMP I use two local git clones - one for building with Quartz-based
dependencies, one for building with X11-based dependencies. They both are configured to install into different prefixes. The launch script just sets $PATH for gimp-2.9 accordingly, depending on
the command line argument given (quartz, x11).

AFAICT the backend is not relevant for this issue: the crash is the same
with unpatched builds, independent of the GTK+ backend used. I only built GIMP with the X11 backend (and integrated it as command line option in the script) because I wanted to compare the redraw performance
between the two backends [1].

Note: Above build setup has a lot of rendundant packages installed, because with GTK2 one cannot have multiple backends compiled in. I maintain it for building & testing Inkscape, and thus can easily reuse it to test local builds of GIMP 2.8 & GIMP 2.9 (git master).

[1] see footnote in

On Sun, Jul 28, 2013 at 5:19 PM, su_v

wrote:

On my system (10.7.5), GIMP launches ok, but crashes when opening the preferences. See stack trace in

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