GNOME.org
 

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

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]