[rrd-developers] "rrdtool restore" error handling and implementation

Terje Bless link at pobox.com
Thu Feb 21 18:42:27 CET 2008

Hash: SHA1

Hi, cf. the thread on rrdtool-users at 
(«Segfault on rrdtool restore...»).

The summary is: while attempting to add a DS to a RRD I'd 
flubbed my editing of the XML dump file and "rrdtool restore" 
segfaulted as a result.

Now segfaulting on bad input — particularly on input that is 
well formed but logically wrong — is not an optimal failure 
mode. It suggests to me that the code there needs more 
sanitizing of input and saner error handling (so it'll bail with 
a descriptive error message).

But rooting around in the code I notice that rrdtool seems to 
have implemented its own XML parser[0]. I'm quite surprised at 
this given the ubiquity of XML parsing libraries (expat and 
libxml, to name two), the usefulness of enabling processing with 
general XML tools, and the pitfalls inherent in “rolling one's 
own” when dealing with XML.

At first I speculated that this was a kind of optimization, but 
the “restore” code doesn't seem particularly performance 
critical. And in terms of dependencies, real XML parsers are 
much more widely available than some of rrdtool's other 
dependencies (and expat is even quite embedable, if that's a concern).

Perhaps it would be prudent to reevaluate how the dump/restore 
functions implement their parsing and serialization?

[0] — “Faux XML Parser” I should probably say; it doesn't 
seem to try to
       be an “XML Processor” as defined in the spec, just 
generically parse
       simple XML-like syntax.
- -- 
>Did you notice the three words "hurricane relief work" in there?
I think we've just discovered a new corollary to Godwin's Law.

                               - Rich Siegel <siegel at barebones.com>

Version: PGP SDK 3.10


More information about the rrd-developers mailing list