gnuplot-beta

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

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

Hello

I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
Some observations happened for both 64 bit and 32 bit build.


Complier gcc-4.9.2-2 from MinGW-64 project
64 bit : exception:seh, thread:win32 
32 bit : exception:dwarf2, thread:win32 

Good point

 I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.


Troubles ?
**********
64 bit
**********
1. I have met an error in compiling qt_conversion.cpp.


../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was not declared in this scope

The error above can be avoided using the following patch:

--- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000 +0900
+++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
@@ -126,7 +126,7 @@
 QRgb* line = (QRgb*)(qimage.scanLine(n));
 for (int m = 0; m < M; m++)
 {
-if (isnan(*image))
+if (std::isnan(*image))
 {
 image++;
 *line++ = 0x00000000;


2. For first plotting in wxt terminal, I see a waring message like an attached file.
Here I write the text:

 You probably called setlocale() directly instead
 of using wxLocale and now there is a
 mismatch between C/C++ and Windows locale.
 Things are going to break, please only change
 locale by creating wxLocale objects to avoid this!

The above message is written in wxWidgets-3.0.2/src/common/intl.cpp

wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
{
    const wxLanguageInfo * const
        info = wxGetLocale() ? GetLanguageInfo(wxGetLocale()->GetLanguage())
                             : NULL;
    if ( !info )
    {
        // wxSetLocale() hadn't been called yet of failed, hence CRT must be
        // using "C" locale -- but check it to detect bugs that would happen if
        // this were not the case.
       wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
                      wxS("You probably called setlocale() directly instead ")
                      wxS("of using wxLocale and now there is a ")
                      wxS("mismatch between C/C++ and Windows locale.\n")
                      wxS("Things are going to break, please only change ")
                      wxS("locale by creating wxLocale objects to avoid this!") );


        // Return the hard coded values for C locale. This is really the right
        // thing to do as there is no LCID we can use in the code below in this
        // case, even LOCALE_INVARIANT is not quite the same as C locale (the
        // only difference is that it uses %Y instead of %y in the date format
        // but this difference is significant enough).

The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
However, I do not see the message building wxWidgets-3 by gcc-4.9.0.

Any ideas to avoid the message? Otherwise, is the above problem of complier?

******
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?

Regards

Tatsuro 

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

[Ethan A M. <sf...@us...>]

On Tuesday, 03 March, 2015 16:16:01 Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
> Some observations happened for both 64 bit and 32 bit build.
> 
> 
> Complier gcc-4.9.2-2 from MinGW-64 project
> 64 bit : exception:seh, thread:win32 
> 32 bit : exception:dwarf2, thread:win32 
> 
> Good point
> 
>  I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
> 
> 
> Troubles ?
> **********
> 64 bit
> **********
[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


 
> Regards
> 
> Tatsuro 

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

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

----- 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)
> 
>
> 
>On Tuesday, 03 March, 2015 16:16:01 Tatsuro MATSUOKA wrote:
>> Hello
>> 
>> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
>> Some observations happened for both 64 bit and 32 bit build.
>> 
>> 
>> Complier gcc-4.9.2-2 from MinGW-64 project
>> 64 bit : exception:seh, thread:win32 
>> 32 bit : exception:dwarf2, thread:win32 
>> 
>> Good point
>> 
>>  I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
>> 
>> 
>> Troubles ?
>> **********
>> 64 bit
>> **********
>[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
#2  0x0052b6bc in gp_cairo_enhanced_flush (plot=0x2a0e0f0)
    at ../../src/wxterminal/gp_cairo.c:1311
#3  0x00525eb9 in wxtPanel::wxt_cairo_exec_command (this=0x2a0df40,
    command=...) at ../../src/wxterminal/wxt_gui.cpp:2964
#4  0x005257a9 in wxtPanel::wxt_cairo_refresh (this=0x2a0df40)
    at ../../src/wxterminal/wxt_gui.cpp:2850
#5  0x00523e67 in wxt_text () at ../../src/wxterminal/wxt_gui.cpp:2047
#6  0x0045d368 in wxt_text_wrapper () at ../../term/wxt.trm:460
#7  0x0040e560 in term_end_plot () at ../../src/term.c:544
#8  0x004f2f8f in do_plot (plots=0x29f8520, pcount=1)
    at ../../src/graphics.c:912
#9  0x004c324e in eval_plots () at ../../src/plot2d.c:3333
#10 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
#11 0x004acb3d in plot_command () at ../../src/command.c:1535
#12 0x004aacb8 in command () at ../../src/command.c:621
#13 0x004aa58d in do_line () at ../../src/command.c:418
#14 0x004aa2cd in com_line () at ../../src/command.c:322
#15 0x004b1518 in gnu_main (argc=0, argv=0x29e5818) at ../../src/plot.c:660
#16 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
    lpszCmdLine=0xa959c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
#17 0x0057a31d in main ()


For pngcairo terminal
(gdb) bt
#0  0x6862318f in g_utf8_validate (str=0x28f596 "-1", max_len=-1,
    end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
#1  0x00529d21 in gp_cairo_convert (plot=0x6088c0 <plot>,
    string=0x28f596 "-1") at ../../src/wxterminal/gp_cairo.c:737
#2  0x00529fbd in gp_cairo_draw_text (plot=0x6088c0 <plot>, x1=1100, y1=8842,
    string=0x28f596 "-1", width=0x0, height=0x0)
    at ../../src/wxterminal/gp_cairo.c:850
#3  0x0045f1ab in cairotrm_put_text (x=1100, y=758, string=0x28f596 "-1")
    at ../../term/cairo.trm:989
#4  0x0040e9fc in write_multiline (x=1100, y=758, text=0x28f596 "-1",
    hor=RIGHT, vert=JUST_CENTRE, angle=0, font=0x0) at ../../src/term.c:781
#5  0x004fd5d5 in ytick2d_callback (axis=FIRST_Y_AXIS, place=-1,
    text=0x28f596 "-1", ticlevel=0, grid=..., userlabels=0x0)
    at ../../src/graphics.c:3446
#6  0x0047fb09 in gen_tics (axis=FIRST_Y_AXIS,
    callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1274
#7  0x00480603 in axis_output_tics (axis=FIRST_Y_AXIS,
    ticlabel_position=0x60bbac <ytic_x>, zeroaxis_basis=FIRST_X_AXIS,
    callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1484
#8  0x004f11c4 in place_grid () at ../../src/graphics.c:217
#9  0x004f21a1 in do_plot (plots=0xde86f0, pcount=1)
    at ../../src/graphics.c:551
#10 0x004c324e in eval_plots () at ../../src/plot2d.c:3333
#11 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
#12 0x004acb3d in plot_command () at ../../src/command.c:1535
#13 0x004aacb8 in command () at ../../src/command.c:621
#14 0x004aa58d in do_line () at ../../src/command.c:418
#15 0x004aa2cd in com_line () at ../../src/command.c:322
#16 0x004b1518 in gnu_main (argc=0, argv=0xdd5818) at ../../src/plot.c:660
#17 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
    lpszCmdLine=0x8a59c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
#18 0x0057a31d in main ()
(gdb)

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

[sfeam <sf...@us...>]

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)
> > 
> >
> > 
> >On Tuesday, 03 March, 2015 16:16:01 Tatsuro MATSUOKA wrote:
> >> Hello
> >> 
> >> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
> >> Some observations happened for both 64 bit and 32 bit build.
> >> 
> >> 
> >> Complier gcc-4.9.2-2 from MinGW-64 project
> >> 64 bit : exception:seh, thread:win32 
> >> 32 bit : exception:dwarf2, thread:win32 
> >> 
> >> Good point
> >> 
> >>  I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
> >> 
> >> 
> >> Troubles ?
> >> **********
> >> 64 bit
> >> **********
> >[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




> #2  0x0052b6bc in gp_cairo_enhanced_flush (plot=0x2a0e0f0)
>     at ../../src/wxterminal/gp_cairo.c:1311
> #3  0x00525eb9 in wxtPanel::wxt_cairo_exec_command (this=0x2a0df40,
>     command=...) at ../../src/wxterminal/wxt_gui.cpp:2964
> #4  0x005257a9 in wxtPanel::wxt_cairo_refresh (this=0x2a0df40)
>     at ../../src/wxterminal/wxt_gui.cpp:2850
> #5  0x00523e67 in wxt_text () at ../../src/wxterminal/wxt_gui.cpp:2047
> #6  0x0045d368 in wxt_text_wrapper () at ../../term/wxt.trm:460
> #7  0x0040e560 in term_end_plot () at ../../src/term.c:544
> #8  0x004f2f8f in do_plot (plots=0x29f8520, pcount=1)
>     at ../../src/graphics.c:912
> #9  0x004c324e in eval_plots () at ../../src/plot2d.c:3333
> #10 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
> #11 0x004acb3d in plot_command () at ../../src/command.c:1535
> #12 0x004aacb8 in command () at ../../src/command.c:621
> #13 0x004aa58d in do_line () at ../../src/command.c:418
> #14 0x004aa2cd in com_line () at ../../src/command.c:322
> #15 0x004b1518 in gnu_main (argc=0, argv=0x29e5818) at ../../src/plot.c:660
> #16 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
>     lpszCmdLine=0xa959c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
> #17 0x0057a31d in main ()
> 
> 
> For pngcairo terminal
> (gdb) bt
> #0  0x6862318f in g_utf8_validate (str=0x28f596 "-1", max_len=-1,
>     end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
> #1  0x00529d21 in gp_cairo_convert (plot=0x6088c0 <plot>,
>     string=0x28f596 "-1") at ../../src/wxterminal/gp_cairo.c:737
> #2  0x00529fbd in gp_cairo_draw_text (plot=0x6088c0 <plot>, x1=1100, y1=8842,
>     string=0x28f596 "-1", width=0x0, height=0x0)
>     at ../../src/wxterminal/gp_cairo.c:850
> #3  0x0045f1ab in cairotrm_put_text (x=1100, y=758, string=0x28f596 "-1")
>     at ../../term/cairo.trm:989
> #4  0x0040e9fc in write_multiline (x=1100, y=758, text=0x28f596 "-1",
>     hor=RIGHT, vert=JUST_CENTRE, angle=0, font=0x0) at ../../src/term.c:781
> #5  0x004fd5d5 in ytick2d_callback (axis=FIRST_Y_AXIS, place=-1,
>     text=0x28f596 "-1", ticlevel=0, grid=..., userlabels=0x0)
>     at ../../src/graphics.c:3446
> #6  0x0047fb09 in gen_tics (axis=FIRST_Y_AXIS,
>     callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1274
> #7  0x00480603 in axis_output_tics (axis=FIRST_Y_AXIS,
>     ticlabel_position=0x60bbac <ytic_x>, zeroaxis_basis=FIRST_X_AXIS,
>     callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1484
> #8  0x004f11c4 in place_grid () at ../../src/graphics.c:217
> #9  0x004f21a1 in do_plot (plots=0xde86f0, pcount=1)
>     at ../../src/graphics.c:551
> #10 0x004c324e in eval_plots () at ../../src/plot2d.c:3333
> #11 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
> #12 0x004acb3d in plot_command () at ../../src/command.c:1535
> #13 0x004aacb8 in command () at ../../src/command.c:621
> #14 0x004aa58d in do_line () at ../../src/command.c:418
> #15 0x004aa2cd in com_line () at ../../src/command.c:322
> #16 0x004b1518 in gnu_main (argc=0, argv=0xdd5818) at ../../src/plot.c:660
> #17 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
>     lpszCmdLine=0x8a59c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
> #18 0x0057a31d in main ()
> (gdb)
> 

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

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

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

----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: Merritt Ethan 
> Cc: gnuplot-beta
> Date: 2015/3/4, Wed 18:45
> Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> 
> 
> 
> 
> 
> ----- 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


I have executed a short test using nmh
https://github.com/shnya/nmh

Perhaps it is better to use ICU - International Components for Unicode but
I used nmh for rough test.

Applied changes:

--- gp_cairo.orig.c2014-12-14 08:42:38.000000000 +0900
+++ gp_cairo.c2015-03-06 10:04:45.142151900 +0900
@@ -76,6 +76,7 @@
 
 #include <pango/pangocairo.h>
 #include <glib.h>
+#include <nmh.h>
 
 #ifdef _MSC_VER
 #define rint(x) floor((x)+0.5L)
@@ -732,14 +733,21 @@
 gsize bytes_read;
 GError *error = NULL;
 const char *charset = NULL;
+const unsigned char *ucharset = NULL;
 gchar * string_utf8;
 
-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);
-}
+charset = gp_cairo_get_encoding(plot);
+ucharset = charset;
+fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
+       if (nmh_is_utf8(ucharset, strlen(ucharset))) { 
+fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
+   string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error); 
+fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
+   } else if (g_utf8_validate(string, -1, NULL)) { 
+            string_utf8 = g_strdup(string); 
+        } else { 
+            fprintf(stderr, "more serious error code or failure \n");
+        } 
 
 /* handle error case */
 if (error != NULL) {


float nmh_is_utf8(const unsigned char *str, int size);
   argument:  str  input strings
              size size of input strings without NULL character. (wequals to strlen(str))
   retern value: 
            value=> 0 possibility of utf-8 is high; 
            value=< 0 possibility of utf-8 is low;
            value=> 1 possibility of utf-8n is high;

*****************************************
The results are:

Terminal type set to 'wxt'
gnuplot> plot sin(x)
[New Thread 21120.0x52b4]
[New Thread 21120.0x5228]
[New Thread 21120.0x4c80]
[New Thread 21120.0x4bdc]
[New Thread 21120.0x5148]
[New Thread 21120.0x52f8]
[New Thread 21120.0x3088]
[New Thread 21120.0x4ef8]
0.500000
0.500000

Program received signal SIGSEGV, Segmentation fault.
0x75d608ca in strncpy () from C:\Windows\syswow64\msvcrt.dll
(gdb) bt
#0  0x75d608ca in strncpy () from C:\Windows\syswow64\msvcrt.dll
#1  0x009e67f0 in ?? ()
#2  0x00000038 in ?? ()
#3  0x00000000 in ?? ()
(gdb)
**********************************
The first and second fprintf(stderr) are excuted but third one are not executed.
Therefore the segmentation fault is related to :
string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error);


Regards

Tatsuro

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

[Allin C. <cot...@wf...>]

On Fri, 6 Mar 2015, Tatsuro MATSUOKA wrote:

> I have executed a short test using nmh
> https://github.com/shnya/nmh
>
> Perhaps it is better to use ICU - International Components for Unicode but
> I used nmh for rough test.
>
> Applied changes:
>
> --- gp_cairo.orig.c2014-12-14 08:42:38.000000000 +0900
> +++ gp_cairo.c2015-03-06 10:04:45.142151900 +0900
> @@ -76,6 +76,7 @@
>  
>  #include <pango/pangocairo.h>
>  #include <glib.h>
> +#include <nmh.h>
>  
>  #ifdef _MSC_VER
>  #define rint(x) floor((x)+0.5L)
> @@ -732,14 +733,21 @@
>  gsize bytes_read;
>  GError *error = NULL;
>  const char *charset = NULL;
> +const unsigned char *ucharset = NULL;
>  gchar * string_utf8;
>  
> -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);
> -}
> +charset = gp_cairo_get_encoding(plot);
> +ucharset = charset;
> +fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
> +       if (nmh_is_utf8(ucharset, strlen(ucharset))) { 
> +fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
> +   string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error); 

Bug right there: according to the documentation for g_convert, it's OK 
to pass NULL in place of the "bytes_read" pointer argument, but _not_
in place of the "bytes_written" (second to last) argument. So it's
to be expected that you get a segfault here.

(BTW, I don't see the point of the nmh test on the "ucharset" string: 
surely that's just the identifier of an encoding and will always be 
ASCII -- and hence also UTF-8.)

Allin Cottrell

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

[Allin C. <cot...@wf...>]

On Fri, 6 Mar 2015, Tatsuro MATSUOKA reported from gdb:

> 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;

I wonder if this is to do with a mix-up between C and C++ compilers.

The gnuplot code passes NULL as the last argument to g_utf8_validate. 
I gather that C++ compilers often represent NULL as all-bits-one -- 
hence, perhaps, the "0xffffffff" above? But apparently glib is not 
reading 0xffffffff as NULL (probably expects NULL = all-bits-zero).

When I build current gnuplot on Linux, gp_cairo.o is compiled by gcc, 
and then g++ is used as linker in making the gnuplot binary. Could it 
be that gp_cairo.o is being compiled by g++ in Tatsuro's case?

Allin Cottrell

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

[Allin C. <cot...@wf...>]

On Tue, 3 Mar 2015, sfeam wrote:

> On Wednesday, 04 March 2015 09:54:08 AM Tatsuro MATSUOKA wrote:
>> [...]
>> 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);
>        }

I think there must be more going on here than meets the eye. 
g_utf8_validate is a very basic glib function, I use it "all the time" 
in the same form as here (with -1 and NULL for the second and third 
arguments) and I've never seen it segfault on any platform or in any 
glib version up to 2.24.2.

Probably unrelated, but in looking at the gp_cairo.c code I noticed 
one definite bug: in an error-response path in gp_cairo_convert on 
line 750 the empty string "" is returned. Since the callers free the 
return from gp_cairo_convert this will surely cause a segfault if it's 
ever triggered. The return value here should either be NULL (if the 
callers are ready to handle that), or g_strdup("").

Allin Cottrell

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

[Ethan A M. <sf...@us...>]

On Friday, 06 March, 2015 10:54:23 Allin Cottrell wrote:
> Probably unrelated, but in looking at the gp_cairo.c code I noticed 
> one definite bug: in an error-response path in gp_cairo_convert on 
> line 750 the empty string "" is returned. Since the callers free the 
> return from gp_cairo_convert this will surely cause a segfault if it's 
> ever triggered. The return value here should either be NULL (if the 
> callers are ready to handle that), or g_strdup("").
> 
> Allin Cottrell


Good catch.
I run valgrind regularly to find such errors, but probably my
tests never execute locale-related error paths.

	Ethan