Re: gnuplot c++ interface segfaulting

[Mojca M. <moj...@gm...>]

On Tue, Mar 4, 2008 at 1:45 AM, Ethan Merritt wrote:
> On Monday 03 March 2008 16:30, Mojca Miklavec wrote:
>  >
>  > A minimal example includes downloading this code:
>  >      http://cheminfo.informatics.indiana.edu/~rguha/code/cc++/gnuplot_i++.tgz
>  > (from http://jijo.cjb.net/)
>  > and unzipping, making it and running an example
>  >
>  > > cd gnuplot_i++
>  > /tmp/gnuplot_i++> make
>  > g++ -c -ggdb -DDEBUGGA  example.cc
>  > g++ -c -ggdb -DDEBUGGA  gnuplot_i.cc
>  > g++ -o example -ggdb example.o gnuplot_i.o -lstdc++
>  > /tmp/gnuplot_i++> ./example
>
>  I may be missing something, but what makes you think this fault
>  involves gnuplot?  It's the example.cc program that is faulting, isn't it?

Yes, but that "example" calls gnuplot. It's probably the communication
that causes problems. I do not say that there are problem in gnuplot
itself (the library could/should be improved/fixed, I guess), but it's
weird that it works for others and not for me.

I have sent this message to both the author and gnuplot list - in the
hope that either will be able to find some solution.

>  > *** example of gnuplot control through C++ ***
>  >
>  > Segmentation fault
>  >
>  > ------
>  >
>  > If I run gdb, then I get a problem in fputs reported:
>  >
>  > Program received signal EXC_BAD_ACCESS, Could not access memory.
>  > Reason: KERN_INVALID_ADDRESS at address: 0x2f706dac
>  > 0x9002990c in fputs ()
>
>  That's not nearly enough information.
>  Do one or both of the following:
>
>  1) Make sure the program is compiled with the -g option
>    Run under gdb as before
>    When is faults, type   "where"   and inspect the resulting call chain

(gdb) where
#0  0x9002990c in fputs ()
#1  0x00007230 in Gnuplot::cmd (this=0xbfffefb0, cmdstr=@0xbffef00c)
at gnuplot_i.cc:1186
#2  0x00007bcb in Gnuplot::set_title (this=0xbfffefb0,
title=@0xbfffefd4) at gnuplot_i.cc:569
#3  0x0000235a in main (argc=1, argv=0xbffff2bc) at example.cc:48

I have seen that place in the source before, but it really seems to be
the communication problem (fputs, or maybe just an unproperly
initialized stream to writo to). I don't know how to interpret these
C++ debug messages.

1186        fputs( (cmdstr+"\n").c_str(), this->gnucmd );
(gdb) step
std::operator+<char, std::char_traits<char>, std::allocator<char> >
(__lhs=@0xbffef00c, __rhs=0xd580 "\n") at basic_string.h:2083
2083          basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
(gdb)
2084          __str.append(__rhs);
(gdb)
0x0000e6b4      2085          return __str;
(gdb) p __str
$1 = {
  static npos = 4294967295,
  _M_dataplus = {
    <std::allocator<char>> = {
      <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
    members of std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::_Alloc_hider:
    _M_p = 0xbffeeefe "??\f???????(????"
  }
}
(gdb) step

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x2f706dac
0x9002990c in fputs ()


On someone else's machine (also Mac OS X Tiger) the same sequence of
commands results in:

(gdb) b Gnuplot::cmd
Breakpoint 1 at 0x7711: file gnuplot_i.cc, line 1178.
(gdb) r
Starting program: /Users/arthur/mojca/gnuplot/test/gnuplot_i++/example
Reading symbols for shared libraries . done
*** example of gnuplot control through C++ ***


Breakpoint 1, Gnuplot::cmd (this=0xbffff1a0, cmdstr=@0xbffef1fc) at
gnuplot_i.cc:1178
1178        if( !(this->valid) )
(gdb) n
1186        fputs( (cmdstr+"\n").c_str(), this->gnucmd );
(gdb) step
std::operator+<char, std::char_traits<char>, std::allocator<char> >
(__lhs=@0xbffef1fc, __rhs=0xe274 "\n") at
/usr/include/c++/4.0.0/bits/basic_string.h:2083
2083          basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
(gdb) p __str
$1 = (basic_string<char,std::char_traits<char>,std::allocator<char> >
&) @0xbffef10c: {
 static npos = 4294967295,
 _M_dataplus = {
   <allocator<char>> = {
     <new_allocator<char>> = {<No data fields>}, <No data fields>},
   members of basic_string<char,std::char_traits<char>,std::allocator<char>
>::_Alloc_hider:
   _M_p = 0x622f7773 <Address 0x622f7773 out of bounds>
 }
}
(gdb) step
2084          __str.append(__rhs);
(gdb) p __str
$2 = (basic_string<char,std::char_traits<char>,std::allocator<char> >
&) @0xbffef10c: {
 static npos = 4294967295,
 _M_dataplus = {
   <allocator<char>> = {
     <new_allocator<char>> = {<No data fields>}, <No data fields>},
   members of basic_string<char,std::char_traits<char>,std::allocator<char>
>::_Alloc_hider:
   _M_p = 0x30035c "set title \"Slopes\""
 }
}
(gdb) continue
Continuing.
*** plotting slopes
y = x

Breakpoint 1, Gnuplot::cmd (this=0xbffff1a0, cmdstr=@0xbffef1fc) at
gnuplot_i.cc:1178
1178        if( !(this->valid) )
(gdb) quit

>  2) Run the program under valgrind:
>    valgrind --tool=memcheck --leak-check=yes --num-callers=20 --leak-resolution=med --log-file=valgrind your-normal-command-line-goes-here
>    and inspect the resulting valgrind log file

valgrind doesn't seem to exist for mac, although it's currently the
highest on their priority list.

Mojca