Skip to content

Segfault during Reader::parse() #1195

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bveldhoen opened this issue Jun 18, 2020 · 5 comments
Closed

Segfault during Reader::parse() #1195

bveldhoen opened this issue Jun 18, 2020 · 5 comments

Comments

@bveldhoen
Copy link

bveldhoen commented Jun 18, 2020

Describe the bug
After upgrading our Fedora 31 buildslaves, I'm experiencing a segfault in our unit tests. Any help will be much appreciated!

Segfault during Reader::parse:

#0  0x00007f84c21fa7b0 in free () from /lib64/libc.so.6
#1  0x00000000004a3d71 in __gnu_cxx::new_allocator<char>::deallocate (this=0xff3ed8, __p=<optimized out>) at /usr/include/c++/9/ext/new_allocator.h:119
#2  std::allocator_traits<std::allocator<char> >::deallocate (__a=..., __n=<optimized out>, __p=<optimized out>) at /usr/include/c++/9/bits/alloc_traits.h:470
#3  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy (__size=<optimized out>, this=0xff3ed8) at /usr/include/c++/9/bits/basic_string.h:237
#4  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose (this=0xff3ed8) at /usr/include/c++/9/bits/basic_string.h:232
#5  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0xff3ed8, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/basic_string.h:658
#6  Json::Reader::ErrorInfo::~ErrorInfo (this=0xff3ec0, __in_chrg=<optimized out>) at /usr/include/json/reader.h:187
#7  std::_Destroy<Json::Reader::ErrorInfo> (__pointer=0xff3ec0) at /usr/include/c++/9/bits/stl_construct.h:98
#8  std::_Destroy_aux<false>::__destroy<Json::Reader::ErrorInfo*> (__last=<optimized out>, __first=0xff3ec0) at /usr/include/c++/9/bits/stl_construct.h:108
#9  std::_Destroy<Json::Reader::ErrorInfo*> (__last=<optimized out>, __first=<optimized out>) at /usr/include/c++/9/bits/stl_construct.h:137
#10 std::_Destroy<Json::Reader::ErrorInfo*, Json::Reader::ErrorInfo> (__last=0x6f436863616c7369, __first=<optimized out>) at /usr/include/c++/9/bits/stl_construct.h:206
#11 std::deque<Json::Reader::ErrorInfo, std::allocator<Json::Reader::ErrorInfo> >::_M_destroy_data_aux (this=<optimized out>, __first=
  {token_ = {type_ = Json::Reader::tokenEndOfStream, start_ = 0xfd0010 "\004", end_ = 0x524f465f4553555f <error: Cannot access memory at address 0x524f465f4553555f>}, message_ = "", extra_ = 0x0}, 
    __last=non-dereferenceable iterator for std::deque) at /usr/include/c++/9/bits/deque.tcc:864
#12 0x00007f84c30fdf14 in Json::Reader::parse(char const*, char const*, Json::Value&, bool) () from /lib64/libjsoncpp.so.21
#13 0x00007f84c30fe208 in Json::Reader::parse(std::istream&, Json::Value&, bool) () from /lib64/libjsoncpp.so.21

To Reproduce
Steps to reproduce the behavior:

  1. Use an invalid json document (although it may also have happened with a valid json).

Expected behavior
No segfault :).

Desktop (please complete the following information):

  • OS: [e.g. iOS] Fedora 31
  • Meson version N/a
  • Ninja version N/A

Additional context
We run unit tests which fail with a segfault, when compiled with g++. When running locally, I could reproduce the segfault using clang++ (not with g++).

$ g++ --version
g++ (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang++ --version
clang version 9.0.1 (Fedora 9.0.1-2.fc31)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /bin

I noticed the ErrorInfo has no implementation of the default ctor (in the .cpp file), and the member variables aren't initialized explicitly. I also noticed when running with valgrind that there were errors w.r.t. jumps depending on uninitialized variables, see the attached log file.
vg.log

jsoncpp Package info

Name         : jsoncpp
Version      : 1.9.1
Release      : 1.fc31
Architecture : x86_64
Size         : 278 k
Source       : jsoncpp-1.9.1-1.fc31.src.rpm
Repository   : @System
From repo    : fedora
Summary      : JSON library implemented in C++
URL          : https://github.com/open-source-parsers/jsoncpp
License      : Public Domain or MIT
Description  : jsoncpp is an implementation of a JSON (http://json.org) reader and writer in
             : C++. JSON (JavaScript Object Notation) is a lightweight data-interchange format.
             : It is easy for humans to read and write. It is easy for machines to parse and
             : generate.
@bveldhoen
Copy link
Author

bveldhoen commented Jun 29, 2020

I noticed that when I checkout tag 1.9.1, the built binary has version 1.9.0, as specified in the CMakeLists.txt file. The fedora source rpm contains a patch that updates the version to 1.9.1.

@dota17
Copy link
Member

dota17 commented Jun 29, 2020

I noticed that when I checkout tag 1.9.1, the built binary has version 1.9.0, as specified in the CMakeLists.txt file.

The problem is that the version value is not correct in CMakeLists.txt in tag 1.9.1
It seems that baylesj forgot to change the value when he make a release.

@bveldhoen
Copy link
Author

The problem does not seem to reproduce when I use the locally rebuilt package from the source package.

@bveldhoen
Copy link
Author

I missed the fact that the Json::Reader constructors (and therefore, also the other methods, including Reader::parse) were deprecated. We've solved our issues by using the suggested alternatives.

@dota17
Copy link
Member

dota17 commented Jul 30, 2020

Ok, that sounds good, so then I will to close this issue. Thanks for your feedback!

@dota17 dota17 closed this as completed Jul 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants