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. | | | [EMAIL PROTECTED] 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:[EMAIL PROTECTED] | > > Help mailto:[EMAIL PROTECTED] | > > 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:[EMAIL PROTECTED] | > Help mailto:[EMAIL PROTECTED] | > Archive http://www.ee.ethz.ch/~slist/rrd-developers | > WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi | | | -- | Unsubscribe mailto:[EMAIL PROTECTED] | Help mailto:[EMAIL PROTECTED] | 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:[EMAIL PROTECTED] http://people.ee.ethz.ch/~oetiker -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
