There is a segfault when calling dump() on an nlohmann::json node containing an int64_t value set to std::numeric_limits<int64_t>::min(). Any other int64_t value (for example, the minimum value + 1, or the maximum value) seems to work fine. Other int or double values (uint64_t, for example) also seem to have no issues.
For this example, the the entire nlohmann JSON repo is included in the folder json.
main.cpp:
#include <stdio.h>
#include <string>
#include <limits>
#include "json/single_include/nlohmann/json.hpp"
int main(int argc, char *argv[])
{
nlohmann::json node_integer_limits = {{"int64_min", std::numeric_limits<int64_t>::min()}};
std::string test_comp1 = std::to_string(std::numeric_limits<int64_t>::min());
std::string test_comp2 = node_integer_limits["int64_min"].dump();
printf("String difference: %d\n", test_comp1.compare(test_comp2));
std::string test_node = node_integer_limits.dump();
printf("Finished!\n");
}
Makefile:
OBJECTS = main.o
CPPFLAGS := -std=gnu++14 -O2 -g
$(OBJECTS): CPPFLAGS := $(CPPFLAGS)
tests: $(OBJECTS)
g++ $(CPPFLAGS) -o tests $(OBJECTS)
main.o: main.cpp json/single_include/nlohmann/json.hpp
g++ $(CPPFLAGS) -c main.cpp
.PHONY: clean
clean:
rm -rf tests $(OBJECTS)
Calling dump() returns a string version of the value.
See above. The error code is:
Segmentation fault (core dumped)
In gdb:
(gdb) run
Starting program: /<full path removed>/tests
Program received signal SIGSEGV, Segmentation fault.
nlohmann::detail::serializer<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> >::dump_integer<unsigned long, 0> (
x=<optimized out>, this=<optimized out>) at json/single_include/nlohmann/json.hpp:14306
14306 o->write_characters(number_buffer.data(), n_chars);
(gdb) bt
#0 nlohmann::detail::serializer<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> >::dump_integer<unsigned long, 0> (
x=<optimized out>, this=<optimized out>) at json/single_include/nlohmann/json.hpp:14306
#1 nlohmann::detail::serializer<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> >::dump (
this=this@entry=0x7fffffffde40, val=..., pretty_print=pretty_print@entry=false, ensure_ascii=<optimized out>, indent_step=indent_step@entry=0, current_indent=<optimized out>) at json/single_include/nlohmann/json.hpp:13894
#2 0x0000000000407c14 in nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer>::dump (this=0x61fd20,
indent=indent@entry=-1, indent_char=indent_char@entry=32 ' ', ensure_ascii=ensure_ascii@entry=false, error_handler=error_handler@entry=nlohmann::detail::error_handler_t::strict) at json/single_include/nlohmann/json.hpp:16390
#3 0x000000000040188f in main (argc=<optimized out>, argv=<optimized out>) at main.cpp:12
The expected output is:
String difference: 0
Finished!
All of this is on the same Ubuntu 16.04 machine. The issue occurs when compiling g++-5 ((Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010) for C++11, C++14, or C++17. The issue only occurs when compiling with -O2 or higher. Both g++-6 ((Ubuntu 6.5.0-2ubuntu1~16.04) 6.5.0 20181026) and g++-7 ((Ubuntu 7.4.0-1ubuntu1~16.04~ppa1) 7.4.0) compile and run with no issues across all optimization levels.
develop branch?Tried with the develop branch as well as versions 3.6.1 and 3.7.0. The behavior was the same in all cases.
There were no compilation errors. All tests passed.
The issue might be caused by line 14267 of json.hpp on the develop branch (https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp#L14267).
Oh dear...

I'll have a look.
Most helpful comment
Oh dear...
I'll have a look.