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 <partha1b@xxxxxxxxx> 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 <jehan.marmottard@xxxxxxxxx> > wrote: >> >> Hey Partha, su_v, >> >> could you test the following patch: >> - copy it in your GIMP directory; >> - apply it with this command from the GIMP directory: >> patch -p0 < osx_crash.diff >> - compile and try again. >> >> I believe it would not fix your crash, because I did not change the >> calls where your traces say it happens. Problem is that it apparently >> crashes at strchr() but there are 5 of them in this function. Looking >> at what seems to be the code in MacOSX of strchr(), looks like it may >> be when the string is NULL, but in my code, I don't see anywhere where >> this is supposed to be possible. >> So unless you can run a debugger to know which exact strchr() line it >> happens at, I added some debug output in the code. Just copy paste >> anything which may be outputted before crash. >> You will most likely have a whole bunch of lines on screen because I >> want to cover as much ground as possible, so you can run like this: >> $ ./gimp-2.9 --verbose >output.txt >> >> Then send me the output.txt after the crash occurs. >> Thanks. >> >> Jehan >> >> >> On Sun, Jul 28, 2013 at 1:47 PM, Jehan Pagès <jehan.marmottard@xxxxxxxxx> >> wrote: >> > Argh! I should nearly have a Mac just to test code there! uhuh >> > Let me have a look. :-) >> > >> > Jehan >> > >> > On Sun, Jul 28, 2013 at 10:39 AM, Partha Bagchi <partha1b@xxxxxxxxx> >> > wrote: >> >> Should have mentioned the segfault is related to >> >> gimp_language_store_parser_init () >> >> >> >> __________________________________________________________________________ >> >> ./gimp-2.9 --verbose >> >> Cannot spawn a message bus without a machine-id: Unable to load >> >> /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file >> >> '/var/lib/dbus/machine-id': No such file or directory >> >> This is a development version of GIMP. Debug messages may appear here. >> >> >> >> INIT: gimp_load_config >> >> Parsing '/Users/partha/Library/Application Support/GIMP/2.9/unitrc' >> >> Parsing >> >> >> >> '/Users/partha/projects/src/gimp/Gimp-2.9.app/Contents/Resources/etc/gimp/2.0/gimprc' >> >> Parsing '/Users/partha/Library/Application Support/GIMP/2.9/gimprc' >> >> ./gimp-2.9: fatal error: Segmentation fault: 11 >> >> ./gimp-2.9 (pid:63964): [E]xit, [H]alt, show [S]tack trace or >> >> [P]roceed: S >> >> #0 0x00007fff8b970698 in __wait4 () >> >> #1 0x0000000101868353 in g_on_error_stack_trace () >> >> #2 0x00000001018687f2 in g_on_error_query () >> >> #3 0x000000010000dee4 in gimp_eek () >> >> #4 0x000000010000df58 in gimp_fatal_error () >> >> #5 0x000000010000e7b6 in gimp_sigfatal_handler () >> >> #6 <signal handler called> >> >> #7 0x00007fff8cb0a60b in strchr () >> >> #8 0x0000000100167614 in gimp_language_store_parser_init () >> >> #9 0x0000000100012c75 in gui_init () >> >> #10 0x000000010000d890 in app_run () >> >> #11 0x000000010000fe24 in main () >> >> >> >> __________________________________________________________________________ >> >> >> >> Thanks, >> >> Partha >> >> >> >> >> >> On Sat, Jul 27, 2013 at 3:01 PM, Partha Bagchi <partha1b@xxxxxxxxx> >> >> wrote: >> >>> >> >>> Jehan, >> >>> >> >>> Looks like the segfault is back? >> >>> >> >>> Thanks, >> >>> Partha >> >>> >> >>> >> >>> >> >>> On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi <partha1b@xxxxxxxxx> >> >>> wrote: >> >>>> >> >>>> Jehan, >> >>>> >> >>>> Thumbs up! All good now. It didn't crash and I was able to open >> >>>> images >> >>>> etc. >> >>>> >> >>>> Thanks again, >> >>>> Partha >> >>>> >> >>>> >> >>>> >> >>>> On Thu, Jul 18, 2013 at 10:56 PM, Jehan Pagès >> >>>> <jehan.marmottard@xxxxxxxxx> wrote: >> >>>>> >> >>>>> Hey Partha, >> >>>>> >> >>>>> you can pull and test now. I made a simple commit where I only take >> >>>>> care of the unset env variable issue. Hopefully this will fix the >> >>>>> OSX >> >>>>> crash. I'll handle the other issue I discovered about not being >> >>>>> thread-safe later. >> >>>>> Tell me how it goes. :-) >> >>>>> >> >>>>> Jehan >> >>>>> >> >>>>> On Fri, Jul 19, 2013 at 11:26 AM, Jehan Pagès >> >>>>> <jehan.marmottard@xxxxxxxxx> wrote: >> >>>>> > Partha, >> >>>>> > >> >>>>> > nothing pushed yet. I'll do this and send a message. :-) >> >>>>> > >> >>>>> > Jehan >> >>>>> > >> >>>>> > On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi >> >>>>> > <partha1b@xxxxxxxxx> >> >>>>> > wrote: >> >>>>> >> Jehan, >> >>>>> >> >> >>>>> >> Do you want me to go ahead test the current code or wait for you >> >>>>> >> to >> >>>>> >> add >> >>>>> >> additional logic? >> >>>>> >> >> >>>>> >> Thanks! >> >>>>> >> Partha >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès >> >>>>> >> <jehan.marmottard@xxxxxxxxx> >> >>>>> >> wrote: >> >>>>> >>> >> >>>>> >>> Hi, >> >>>>> >>> >> >>>>> >>> I searched a little more though, and it seems on BSDs, hence on >> >>>>> >>> OSX, >> >>>>> >>> indeed setenv with a NULL value could crash the program. The >> >>>>> >>> setenv >> >>>>> >>> in >> >>>>> >>> GNU libc on the other hand perfectly handles the case >> >>>>> >>> explicitly. >> >>>>> >>> So obviously when I see this kind of code (note I am not 100% >> >>>>> >>> sure >> >>>>> >>> this is the code for Darwin on Mountain Lion but I can't find a >> >>>>> >>> reference linking the libc numbers there and the Darwin version >> >>>>> >>> 10.8, >> >>>>> >>> but I assume that should be a similar code): >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> http://www.opensource.apple.com/source/Libc/Libc-825.26/stdlib/FreeBSD/setenv.c >> >>>>> >>> >> >>>>> >>> Before any test on the value pointer, it dereferences it (which >> >>>>> >>> is >> >>>>> >>> undefined!), and read the content of the non-existing first >> >>>>> >>> character >> >>>>> >>> of the NULL string (which I assume would crash!): >> >>>>> >>> >> >>>>> >>> if (*value == '=') /* no `=' in value */ >> >>>>> >>> ++value; >> >>>>> >>> >> >>>>> >>> I don't know what is the policy on BSD but I thought they were >> >>>>> >>> very >> >>>>> >>> keen on security, but this code does not look very sane to me. >> >>>>> >>> So yeah anyway that's a problem too in the end. I'll deal with >> >>>>> >>> it. >> >>>>> >>> >> >>>>> >>> Jehan >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> On Fri, Jul 19, 2013 at 7:14 AM, Partha Bagchi >> >>>>> >>> <partha1b@xxxxxxxxx> >> >>>>> >>> wrote: >> >>>>> >>> > Jehan, >> >>>>> >>> > >> >>>>> >>> > I will test it tomorrow. I will get back to you with the >> >>>>> >>> > results. >> >>>>> >>> > >> >>>>> >>> > Thanks for your prompt response! >> >>>>> >>> > >> >>>>> >>> > Partha >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >>> > On Thu, Jul 18, 2013 at 11:42 AM, Jehan Pagès >> >>>>> >>> > <jehan.marmottard@xxxxxxxxx> >> >>>>> >>> > wrote: >> >>>>> >>> >> >> >>>>> >>> >> Hi again, >> >>>>> >>> >> >> >>>>> >>> >> I have some working code in my working branch now where I >> >>>>> >>> >> applied >> >>>>> >>> >> the >> >>>>> >>> >> concepts I wrote about (basically initializing the language >> >>>>> >>> >> store >> >>>>> >>> >> only >> >>>>> >>> >> once and at the very start of the program, before any >> >>>>> >>> >> threading >> >>>>> >>> >> would >> >>>>> >>> >> occur hopefully). >> >>>>> >>> >> Don't know if that will be the finale code, but should be at >> >>>>> >>> >> least >> >>>>> >>> >> good enough to test on OSX (I don't have access to a OSX >> >>>>> >>> >> machine >> >>>>> >>> >> to >> >>>>> >>> >> reproduce the bug myself and see if this indeed fixes the >> >>>>> >>> >> issue). >> >>>>> >>> >> As >> >>>>> >>> >> soon as the report is up, I'll upload the patch there so that >> >>>>> >>> >> someone >> >>>>> >>> >> with OSX can test it and tell me if that fixes it. :-) >> >>>>> >>> >> Thanks. >> >>>>> >>> >> >> >>>>> >>> >> Jehan >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >>> >> On Thu, Jul 18, 2013 at 9:47 PM, Jehan Pagès >> >>>>> >>> >> <jehan.marmottard@xxxxxxxxx> >> >>>>> >>> >> wrote: >> >>>>> >>> >> > Hey all, >> >>>>> >>> >> > >> >>>>> >>> >> > it seems I am the culprit for this bug. I don't have this >> >>>>> >>> >> > crash >> >>>>> >>> >> > on >> >>>>> >>> >> > Linux >> >>>>> >>> >> > though. >> >>>>> >>> >> > >> >>>>> >>> >> > It looks like the implementation of setenv/getenv is >> >>>>> >>> >> > different >> >>>>> >>> >> > on >> >>>>> >>> >> > OSX. >> >>>>> >>> >> > According to glib doc, the problem may be that on some >> >>>>> >>> >> > implementations, successive calls may use the same buffer. >> >>>>> >>> >> > I >> >>>>> >>> >> > guess >> >>>>> >>> >> > that's the case on OSX. And also these calls are not >> >>>>> >>> >> > thread-safe. >> >>>>> >>> >> > Also >> >>>>> >>> >> > the fact that there is no LANGUAGE env variable should >> >>>>> >>> >> > normally >> >>>>> >>> >> > not >> >>>>> >>> >> > be >> >>>>> >>> >> > a real problem. I don't have this variable set on my system >> >>>>> >>> >> > either >> >>>>> >>> >> > and, as I said, no crash here. I guess this brought the >> >>>>> >>> >> > real >> >>>>> >>> >> > issue of >> >>>>> >>> >> > the OSX getenv/setenv implementation into light though. >> >>>>> >>> >> > >> >>>>> >>> >> > In any case, I think that the real solution is to have the >> >>>>> >>> >> > list >> >>>>> >>> >> > of >> >>>>> >>> >> > all >> >>>>> >>> >> > localized languages generated at startup, before any thread >> >>>>> >>> >> > or >> >>>>> >>> >> > anything happens (I just saw that's also what glib doc >> >>>>> >>> >> > says: we >> >>>>> >>> >> > should >> >>>>> >>> >> > only use these calls on startup before any thread happens). >> >>>>> >>> >> > Then we >> >>>>> >>> >> > just use this pre-generated list each time it is needed. I >> >>>>> >>> >> > was >> >>>>> >>> >> > already >> >>>>> >>> >> > thinking that the current design was bad anyway, because we >> >>>>> >>> >> > are >> >>>>> >>> >> > basically parsing a huge file of language codes and names >> >>>>> >>> >> > each >> >>>>> >>> >> > time >> >>>>> >>> >> > we >> >>>>> >>> >> > open the preference dialog! Such a waste of resources and >> >>>>> >>> >> > time. >> >>>>> >>> >> > I did not modify it at the time because I did not feel like >> >>>>> >>> >> > using >> >>>>> >>> >> > more >> >>>>> >>> >> > time towards this, but I guess that should be the occasion >> >>>>> >>> >> > to >> >>>>> >>> >> > do it. >> >>>>> >>> >> > >> >>>>> >>> >> > In any case, please fill a bug report and I'll have a look! >> >>>>> >>> >> > :-) >> >>>>> >>> >> > >> >>>>> >>> >> > Jehan >> >>>>> >>> >> > >> >>>>> >>> >> > >> >>>>> >>> >> > On Thu, Jul 18, 2013 at 6:31 AM, Partha Bagchi >> >>>>> >>> >> > <partha1b@xxxxxxxxx> >> >>>>> >>> >> > wrote: >> >>>>> >>> >> >> Hey V, >> >>>>> >>> >> >> >> >>>>> >>> >> >> Thanks for checking on this. I am glad (in a way) that my >> >>>>> >>> >> >> system is >> >>>>> >>> >> >> not >> >>>>> >>> >> >> the >> >>>>> >>> >> >> only one having this issue! :) >> >>>>> >>> >> >> >> >>>>> >>> >> >> I will try to revert the above changes and see if the >> >>>>> >>> >> >> problem >> >>>>> >>> >> >> disappears. >> >>>>> >>> >> >> >> >>>>> >>> >> >> Partha >> >>>>> >>> >> >> >> >>>>> >>> >> >> >> >>>>> >>> >> >> >> >>>>> >>> >> >> On Wed, Jul 17, 2013 at 7:51 AM, su_v >> >>>>> >>> >> >> <suv-sf@xxxxxxxxxxxxxxxxxxxxx> >> >>>>> >>> >> >> wrote: >> >>>>> >>> >> >> >> >>>>> >>> >> >>> On 2013-07-17 01:19 +0100, Partha Bagchi wrote: >> >>>>> >>> >> >>> > My recent (last built a few moment ago) git builds >> >>>>> >>> >> >>> > (2.9) >> >>>>> >>> >> >>> > have >> >>>>> >>> >> >>> > been >> >>>>> >>> >> >>> > instantly segfaulting on MBR running Mountain Lion. >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> > gdb backtrace (or commandline execution) shows: >> >>>>> >>> >> >>> > ./gimp-2.9 (pid:42315): [E]xit, [H]alt, show [S]tack >> >>>>> >>> >> >>> > trace >> >>>>> >>> >> >>> > or >> >>>>> >>> >> >>> > [P]roceed: >> >>>>> >>> >> >>> S >> >>>>> >>> >> >>> > #0 0x00007fff8b257698 in __wait4 () >> >>>>> >>> >> >>> > #1 0x00000001018de353 in g_on_error_stack_trace () >> >>>>> >>> >> >>> > #2 0x00000001018de7f2 in g_on_error_query () >> >>>>> >>> >> >>> > #3 0x000000010000fa54 in gimp_eek () >> >>>>> >>> >> >>> > #4 0x000000010000fac8 in gimp_fatal_error () >> >>>>> >>> >> >>> > #5 0x0000000100010326 in gimp_sigfatal_handler () >> >>>>> >>> >> >>> > #6 <signal handler called> >> >>>>> >>> >> >>> > #7 0x00007fff8c40887e in setenv () >> >>>>> >>> >> >>> > #8 0x00000001018f76cf in g_setenv () >> >>>>> >>> >> >>> > #9 0x0000000100168c11 in gimp_language_store_self_l10n >> >>>>> >>> >> >>> > () >> >>>>> >>> >> >>> > #10 0x0000000101915c99 in emit_start_element () >> >>>>> >>> >> >>> > #11 0x00000001019170b0 in g_markup_parse_context_parse >> >>>>> >>> >> >>> > () >> >>>>> >>> >> >>> > #12 0x000000010035a7ba in >> >>>>> >>> >> >>> > gimp_xml_parser_parse_io_channel >> >>>>> >>> >> >>> > () >> >>>>> >>> >> >>> > #13 0x000000010035a9ab in gimp_xml_parser_parse_file () >> >>>>> >>> >> >>> > #14 0x0000000100168f71 in >> >>>>> >>> >> >>> > gimp_language_store_parse_iso_codes () >> >>>>> >>> >> >>> > #15 0x000000010188619b in g_object_new_internal () >> >>>>> >>> >> >>> > #16 0x0000000101886cdd in g_object_newv () >> >>>>> >>> >> >>> > #17 0x0000000101886edc in g_object_new () >> >>>>> >>> >> >>> > #18 0x0000000100168025 in gimp_language_entry_new () >> >>>>> >>> >> >>> > #19 0x000000010017cc00 in gimp_prop_language_entry_new >> >>>>> >>> >> >>> > () >> >>>>> >>> >> >>> > #20 0x00000001000a3df2 in gimp_text_options_gui () >> >>>>> >>> >> >>> > #21 0x000000010005e9e6 in gimp_tools_restore () >> >>>>> >>> >> >>> > #22 0x000000010001428b in gui_restore_callback () >> >>>>> >>> >> >>> > #23 0x000000010187dd0d in g_closure_invoke () >> >>>>> >>> >> >>> > #24 0x000000010189483b in signal_emit_unlocked_R () >> >>>>> >>> >> >>> > #25 0x0000000101897111 in g_signal_emit_valist () >> >>>>> >>> >> >>> > #26 0x0000000101897964 in g_signal_emit () >> >>>>> >>> >> >>> > #27 0x000000010000f2fe in app_run () >> >>>>> >>> >> >>> > #28 0x0000000100011994 in main () >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> > and gimp-2.9 --verbose >> >>>>> >>> >> >>> > ... >> >>>>> >>> >> >>> > Parsing '/Users/partha/Library/Application >> >>>>> >>> >> >>> > Support/GIMP/2.9/tool-options/gimp-text-tool' >> >>>>> >>> >> >>> > ./gimp-2.9: fatal error: Segmentation fault: 11 >> >>>>> >>> >> >>> > ./gimp-2.9 (pid:42330): [E]xit, [H]alt, show [S]tack >> >>>>> >>> >> >>> > trace >> >>>>> >>> >> >>> > or >> >>>>> >>> >> >>> > [P]roceed: >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> > Is anyone else on the Mac having this issue? Should I >> >>>>> >>> >> >>> > file >> >>>>> >>> >> >>> > a >> >>>>> >>> >> >>> > bug-report? >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> Reproduced (same stack trace) on MBR (13-inch, Late 2011) >> >>>>> >>> >> >>> running >> >>>>> >>> >> >>> OS X >> >>>>> >>> >> >>> 10.7.5; dependencies for GIMP installed via MacPorts >> >>>>> >>> >> >>> (custom >> >>>>> >>> >> >>> portfiles >> >>>>> >>> >> >>> for babl, gegl and GIMP git master). >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> Workaround (at least for this segfault at launch time) is >> >>>>> >>> >> >>> to >> >>>>> >>> >> >>> run >> >>>>> >>> >> >>> GIMP >> >>>>> >>> >> >>> like this: >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> $ echo $LANG >> >>>>> >>> >> >>> en_US.UTF-8 >> >>>>> >>> >> >>> $ LANGUAGE="$LANG" gimp --verbose >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> Possibly related to the changes in >> >>>>> >>> >> >>> < >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> https://git.gnome.org/browse/gimp/commit/?id=f6dcde1ee66fda4dfdc063022c4d2e901adb9a71 >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> < >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> https://git.gnome.org/browse/gimp/commit/?id=4eecd9b4ac71615f10819378938dcdce7e531167 >> >>>>> >>> >> >>> > >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> hth, V >> >>>>> >>> >> >>> _______________________________________________ >> >>>>> >>> >> >>> gimp-developer-list mailing list >> >>>>> >>> >> >>> List address: gimp-developer-list@xxxxxxxxx >> >>>>> >>> >> >>> List membership: >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> >>>>> >>> >> >>> >> >>>>> >>> >> >> _______________________________________________ >> >>>>> >>> >> >> gimp-developer-list mailing list >> >>>>> >>> >> >> List address: gimp-developer-list@xxxxxxxxx >> >>>>> >>> >> >> List membership: >> >>>>> >>> >> >> >> >>>>> >>> >> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >> >> >>>>> >> >> >>>> >> >>>> >> >>> >> >> > > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
