[rrd-developers] Re: calling rrd_create directly in librrd.so

[Tobias Oetiker]

Yesterday Ashok wrote:

 |
 | Hi,
 |
 | This happens with the first rrd_xxx call itself. I made sure that optind and opterr
 | were set to zero before making this call, but it still doesn't work. The other
 | solution I implemented was to fork a  rrdtool process with "-" argument (so that it
 | will not exit after each command, but waits for the next command) and write to the
 | stdin of this process through a pipe from my application process. This works, but
 | it is difficult to determine if there were any errors unless I read the stdout and
 | search for the "ERROR" string.
 |
 | The solution with calling "rrd_xxx" functions within the librrd.so would be nice if
 | it worked. The interesting thing is calling rrd_fetch_fn() directly(instead of
 | rrd_fetch())  works. (which again raises the suspicion on the getopt_long() calls.)

could it be that you are not preparing the argv,arc  stuff
properly?

take a look at the perl bindings, or also at rrd_tool.c

its all there

tobi
 |
 | Thanks.
 | Ashok.
 |
 |
 | paulw at oninit.com wrote:
 |
 | > Does this happen on the first rrd call or subsequent ones?  If it's
 | > subsquent you need to be resetting optind and opterr.  I've just been
 | > through this loop.  The worrying thing is I've found it faster (10%)
 | > to build a system call and run it than it was to link in the libraries.
 | >
 | > Ashok Mandala wrote:
 | > >
 | > > Hi,
 | > >
 | > > I am trying to use the "C" API  for the rrd functionality to
 | > > create/update rrd files. I have created the proper argument list that
 | > > rrd_create expects, but I get a segmentation fault from rrd_create when
 | > > I try to use it. I have stepped through the code using gdb and have
 | > > followed it to the point in rrd_create.c where it calls getopt_long() -
 | > > there it issues a segmentation fault when I try to step into it. I saw
 | > > some code for getopt_long() definition in getopt1.c included with
 | > > rrdtool - so this call should have gone to that getopt_long() and the
 | > > source should have opened up. Is the call binding to the libc
 | > > getopt_long() ? Has anyone faced this same problem before ?
 | > >
 | > > Thanks.
 | > > Ashok.
 | > >
 | > > --
 | > > Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
 | > > Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
 | > > Archive     http://www.ee.ethz.ch/~slist/rrd-developers
 | > > WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi
 | >
 | > --
 | > Paul Watson             #
 | > Oninit Ltd              # You are only young once
 | > Tel: +44 1436 672201    # but you can be immature
 | > Fax: +44 1436 678693    # for ever
 | > www.oninit.com          #
 | >
 | > --
 | > Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
 | > Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
 | > Archive     http://www.ee.ethz.ch/~slist/rrd-developers
 | > WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi
 |
 |
 | --
 | Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
 | Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
 | Archive     http://www.ee.ethz.ch/~slist/rrd-developers
 | WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi
 |
 |

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker, ETZ J97, ETH, 8092 Zurich, Switzerland
 / // _ \/ _ \/ / phoneto:+41(0)1-632-5286  faxto:+41(0)1-632-1517
/_/ \.__/_.__/_/ mailto:oetiker at ee.ethz.ch http://people.ee.ethz.ch/~oetiker


--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi