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 <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 Pagès <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 <partha1b gmail com>wrote:Should have mentioned the segfault is related to gimp_language_store_parser_init ()__________________________________________________________________________./gimp-2.9 --verbose Cannot spawn a message bus without a machine-id: Unable to load /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file '/var/lib/dbus/machine-id': No such file or directory This is a development version of GIMP. Debug messages may appear here. INIT: gimp_load_config Parsing '/Users/partha/Library/Application Support/GIMP/2.9/unitrc' Parsing'/Users/partha/projects/src/gimp/Gimp-2.9.app/Contents/Resources/etc/gimp/2.0/gimprc'Parsing '/Users/partha/Library/Application Support/GIMP/2.9/gimprc' ./gimp-2.9: fatal error: Segmentation fault: 11 ./gimp-2.9 (pid:63964): [E]xit, [H]alt, show [S]tack trace or[P]roceed: S#0 0x00007fff8b970698 in __wait4 () #1 0x0000000101868353 in g_on_error_stack_trace () #2 0x00000001018687f2 in g_on_error_query () #3 0x000000010000dee4 in gimp_eek () #4 0x000000010000df58 in gimp_fatal_error () #5 0x000000010000e7b6 in gimp_sigfatal_handler () #6 <signal handler called> #7 0x00007fff8cb0a60b in strchr () #8 0x0000000100167614 in gimp_language_store_parser_init () #9 0x0000000100012c75 in gui_init () #10 0x000000010000d890 in app_run () #11 0x000000010000fe24 in main ()__________________________________________________________________________Thanks, Partha On Sat, Jul 27, 2013 at 3:01 PM, Partha Bagchi <partha1b gmail com>wrote:Jehan, Looks like the segfault is back? Thanks, Partha On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi <partha1b gmail com>wrote:Jehan, Thumbs up! All good now. It didn't crash and I was able to open images etc. Thanks again, Partha On Thu, Jul 18, 2013 at 10:56 PM, Jehan Pagès <jehan marmottard gmail com> wrote:Hey Partha, you can pull and test now. I made a simple commit where I only take care of the unset env variable issue. Hopefully this will fix the OSX crash. I'll handle the other issue I discovered about not being thread-safe later. Tell me how it goes. :-) Jehan On Fri, Jul 19, 2013 at 11:26 AM, Jehan Pagès <jehan marmottard gmail com> 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 youtoadd additional logic? Thanks! Partha On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès <jehan marmottard gmail com> wrote:Hi, I searched a little more though, and it seems on BSDs, hence onOSX,indeed setenv with a NULL value could crash the program. Thesetenvin 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%surethis 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.cBefore any test on the value pointer, it dereferences it (whichisundefined!), 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 wereverykeen 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 withit.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 theresults.Thanks for your prompt response! Partha On Thu, Jul 18, 2013 at 11:42 AM, Jehan Pagès <jehan marmottard gmail com> wrote:Hi again, I have some working code in my working branch now where Iappliedthe concepts I wrote about (basically initializing the languagestoreonly once and at the very start of the program, before anythreadingwould 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 OSXmachineto reproduce the bug myself and see if this indeed fixes theissue).As soon as the report is up, I'll upload the patch there so that someone with OSX can test it and tell me if that fixes it. :-) Thanks. Jehan On Thu, Jul 18, 2013 at 9:47 PM, Jehan Pagès <jehan marmottard gmail com> wrote:Hey all, it seems I am the culprit for this bug. I don't have thiscrashon Linux though. It looks like the implementation of setenv/getenv isdifferenton 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 shouldnormallynot 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 thelistof all localized languages generated at startup, before any threadoranything happens (I just saw that's also what glib docsays: weshould only use these calls on startup before any thread happens). Then we just use this pre-generated list each time it is needed. Iwasalready thinking that the current design was bad anyway, because wearebasically parsing a huge file of language codes and nameseachtime we open the preference dialog! Such a waste of resources andtime.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 occasiontodo 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 theproblemdisappears. 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]tacktraceor [P]roceed:S#0 0x00007fff8b257698 in __wait4 () #1 0x00000001018de353 in g_on_error_stack_trace () #2 0x00000001018de7f2 in g_on_error_query () #3 0x000000010000fa54 in gimp_eek () #4 0x000000010000fac8 in gimp_fatal_error () #5 0x0000000100010326 in gimp_sigfatal_handler () #6 <signal handler called> #7 0x00007fff8c40887e in setenv () #8 0x00000001018f76cf in g_setenv () #9 0x0000000100168c11 in gimp_language_store_self_l10n()#10 0x0000000101915c99 in emit_start_element () #11 0x00000001019170b0 in g_markup_parse_context_parse()#12 0x000000010035a7ba ingimp_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]tacktraceor [P]roceed: Is anyone else on the Mac having this issue? Should Ifilea bug-report?Reproduced (same stack trace) on MBR (13-inch, Late 2011) running OS X 10.7.5; dependencies for GIMP installed via MacPorts(customportfiles for babl, gegl and GIMP git master). Workaround (at least for this segfault at launch time) istorun 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=4eecd9b4ac71615f10819378938dcdce7e531167hth, 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
Attachment:
output.txt
Description: Text document