Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
> From: sfeam 
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-beta
> Date: 2015/3/4, Wed 12:34
> Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> 
> On Wednesday, 04 March 2015 09:54:08 AM Tatsuro MATSUOKA wrote:
>> 
>>  ----- Original Message -----
>>  >From: Ethan A Merritt 
>>  >To: gnuplot-beta@ Tatsuro MATSUOKA 
>>  >Date: 2015/3/4, Wed 05:29
>>  >Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 
> (MinGW64)
>>  >[snip]
>>  > 
>>  >> 32 bit
>>  >> ******
>>  >> gnuplot crashes by segmentation fault when one use cairo based 
> terminals.
>>  >> 
>>  >> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 
> bit gcc-4.9.2
>>  >> 
>>  >> I have met a  Segmentation fault at using gnuplot-5.1 built by 
> myself on windows.
>>  >> The Segmentation fault seems to be related with the cairo based 
> terminals.
>>  >> (The cairo based terminals use libglib.)
>>  >> 
>>  >> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
>>  >> Glib version : 2.42.1. Build from source.
>>  >> 
>>  >> gdb message:
>>  >> 
>>  >> Program received signal SIGSEGV, Segmentation fault.
>>  >> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", 
> max_len=-1, end=0xffffffff)
>>  >>     at ../../glib-2.42.1/glib/gutf8.c:1634
>>  >> 1634        *end = p;
>>  >> 
>>  >> Program received signal SIGSEGV, Segmentation fault.
>>  >> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", 
> max_len=-1, end=0xffffffff)
>>  >>     at ../../glib-2.42.1/glib/gutf8.c:1634
>>  >> 1634        *end = p;
>>  >> 
>>  >> 
>>  >> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
>>  >> 
>>  >> I have filed the issue to  the bug tracker of Gnome.
>>  >>  
>>  >> https://bugzilla.gnome.org/show_bug.cgi?id=745485
>>  >> 
>>  >> At this moment, I abandon the complier update. However, is the 
> trouble 2 for 64 bit case not a issue of gnuplot code?
>>  > 
>>  >That is possible.
>>  >Can you provide a more complete trace of the segfault that
>>  >shows where in the gnuplot code this failure happened?
>>  > 
>>  >Ethan
>>  > 
>> 
>> 
>>  Thank you for your response:
>> 
>>  I copy the back trace.
> 
>>  For wxt terminal,
>>  (gdb) bt
>>  #0  0x6862318f in g_utf8_validate (str=0x2a97fc8 "-1", 
> max_len=-1,
>>      end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
>>  #1  0x00529d21 in gp_cairo_convert (plot=0x2a0e0f0, string=0x2a97fc8 
> "-1")
>>      at ../../src/wxterminal/gp_cairo.c:737
> 
> [snip]
> 
> I think this indicates a bug in glib.
> Gnuplot is prepared for an error return from the call to g_utf8_validate,
> but apparently glib faults instead of cleanly returning an error.
> The gnuplot code is:
>         if (g_utf8_validate(string, -1, NULL)) {
>             string_utf8 = g_strdup(string);
>         } else {
>             charset = gp_cairo_get_encoding(plot);
>             string_utf8 = g_convert(string, -1, "UTF-8", charset, 
> &bytes_read, NULL, &error);
>         }
> 
> The strange thing is that the string being converted seems totally
> harmless: "-1".   I could more easily understand if the failure
> occurred for a string in, for example, SHIFT_JIS encoding since 
> I imagine the glib people have not tested that extensively.
> 
> The only thing I can think of to try in the gnuplot code is to invert
> the order of the tests.  Something like
> 
>         charset = gp_cairo_get_encoding(plot);
>         if (<some test on charset != UTF8>) {
>             string_utf8 = g_convert(string, -1, "UTF-8", charset, 
> &bytes_read, NULL, &error);
>         } else if (g_utf8_validate(string, -1, NULL)) {
>             string_utf8 = g_strdup(string);
>         } else {
>             more serious error code or failure
>         }
> 
> I am not sure what are the proper test in the pseudo-code above
> when run on Windows.
> 
>     Ethan


 Thank you for your reply. I will consider <some test on charset != UTF8>.

Tatsuro