invalid read of freed memory when parsing malformed input

[GoogleCodeExporter]

What steps will reproduce the problem?
1. compile test-yaml.cpp
2. run valgrind ./test-yaml < input.txt
3. program works fine, but valgrind complains about invalid read of freed block 
(see valgrind.log)

What is the expected output? What do you see instead?

same as now but without valgrind errors

What version of the product are you using? On what operating system?

yaml-cpp 0.3.0 and also tried previous version, os is FreeBSD xxx.xx 
8.2-RELEASE FreeBSD 8.2-RELEASE #0: Tue Mar 15 14:02:04 MSK 2011 ... amd64

Please provide any additional information below.

input.txt is malformed, because i used = instead of : in the end of input

Original issue reported on code.google.com by svirshch...@gmail.com on 23 Jan 2012 at 4:47

Attachments:

• input.txt
• test-yaml.cpp
• valgrind.log

[GoogleCodeExporter]

It seems that this is due to throwing an std::runtime_error. For example, see

http://stackoverflow.com/questions/4161401/leak-in-exception-code-c

In particular, if you run:

{{{
#include <stdexcept>
#include <iostream>

int main ()
{
  try {
    throw std::runtime_error("What");
  } catch(const std::exception& e) {
    std::cout << "exception: " << e.what () << "\n";
  }
}
}}}

This will give exactly the same leak of

{{{
at 0xB823: malloc (vg_replace_malloc.c:266)
0x620CF: __cxa_get_globals (in /usr/lib/libstdc++.6.0.9.dylib)
by 0x61DCD: __cxa_allocate_exception (in /usr/lib/libstdc++.6.0.9.dylib)
}}}

(e.g.)

Notice, however, that this leak will only appear once, even if you throw many 
exceptions (and catch them all).

So it appears that as long as we use `std::runtime_error` as the base class for 
`YAML::Exception`, valgrind will find this leak.

Sorry :(

Original comment by jbe...@gmail.com on 23 Jan 2012 at 6:08

• Changed state: WontFix

[GoogleCodeExporter]

I agree, one-time memory leak is not a big issue. However "blocks definitely 
lost" and "invalid read" are completely different matters. The first one is 
frequently a false positive while the second one is almost always an error.

Also you said, that it depends on exception but really it does not. I tried to 
shorten input but after that valgrind errors disappeared while exception is 
still thrown.

For me it is pretty clear, that you use delete node of deque, or maybe .front 
() on empty dequeue or a pointer to deleted node.

Anyway i didn't mean bothering you, just hoped it would be an easy fix. And 
also thanks for great library, i like it and it is very handy (i really dont 
plan to parse malformed data all the time)

Original comment by svirshch...@gmail.com on 23 Jan 2012 at 7:50

[GoogleCodeExporter]

btw i dont see any leak, i see "invalid read of size 8". One-time leak when 
throwing is probably a linux feature, while i run test on FreeBSD.

Original comment by svirshch...@gmail.com on 23 Jan 2012 at 8:24

[GoogleCodeExporter]

I see, I'm sorry, you're right. I didn't read it carefully enough, and I got 
bogged down in hunting for that leak, not the invalid read. I'll check this out 
tomorrow.

Thanks!

Original comment by jbe...@gmail.com on 23 Jan 2012 at 8:49

• Changed state: Accepted

[GoogleCodeExporter]

Fixed, r0316abdc76a8.

Finally! :)

Original comment by jbe...@gmail.com on 15 May 2012 at 4:10

• Changed state: Fixed