Re: [Gimp-developer] Gimp git on Mac Segfault



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 you to
add
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 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
<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 Pagès
<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
<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  <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 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










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