Skip to content
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

Segfault on direct initializing json object #973

Closed
dns13 opened this issue Feb 14, 2018 · 10 comments
Closed

Segfault on direct initializing json object #973

dns13 opened this issue Feb 14, 2018 · 10 comments
Labels
platform: arm related to ARM architecture state: help needed the issue needs help to proceed

Comments

@dns13
Copy link
Contributor

dns13 commented Feb 14, 2018

I'm currently updating from 2.x to 3.1.1: Now my default initialisation of json objects is causing a SEGFAULT:

Example:

json root = {
    {"command", "request_token"},
    {"payload", {
        {"token", child_info.token}
    }}
};

This code is working fine:

json root;
root = {
    {"command", "request_token"},
    {"payload", {
        {"token", child_info.token}
    }}
};

I'm experiencing this in only one single way to call the containing function:
I'm using a command string parsed from an json object, and a std::map to map that string to an enumeration object, which I pass to a switch statement to determine which function to be called.

If I skip the switch statement, and determine the calling of the function by directly comparing the command string, it won't crash.

I'm using gcc 4.9.2 with cross compiling to armv7.

Heres a backtrace after crashing:

#0  0x0003e32c in nlohmann::basic_json<std::map, std::vector, std::string, bool, long long, unsigned long long, double, std::allocator, nlohmann::adl_serializer>::json_value::destroy(nlohmann::detail::value_t) ()
#1  0x0002cef4 in int (anonymous namespace)::command_expr_request_token<0, 0>(nlohmann::basic_json<std::map, std::vector, std::string, bool, long long, unsigned long long, double, std::allocator, nlohmann::adl_serializer> const&, conn_info_t&, bio_st*, int, bool) [clone .isra.1043] ()
#2  0x00044b38 in parseCommand(nlohmann::basic_json<std::map, std::vector, std::string, bool, long long, unsigned long long, double, std::allocator, nlohmann::adl_serializer> const&, conn_info_t&, bio_st*) ()
#3  0x0006e4b4 in (anonymous namespace)::thread_child(bio_st*) ()
#4  0x4b2c7f68 in ?? () from /usr/lib/libstdc++.so.6
#5  0x4b146068 in ?? () from /lib/libpthread.so.0
@pboettch
Copy link
Contributor

What happens if you replace child_info.token by, let's say, 1? What is the type of child_info.token.

@dns13
Copy link
Contributor Author

dns13 commented Feb 14, 2018

It's of type string; same behaviour when replaced with constant string (or other type or completely removed).

I made further tests with various initialisations:

json root_0 = {}; // working
json root_1 = {true}; // working
json root_2 = {10}; // working
json root_3 = {true, 10}; // working
json root_4 = {true, true}; // working
json root_5 = {11, 12}; // working
json root_6 = "{\"command\":\"test\"}"_json; // working
json root_7 = R"({"command": "test"})"_json; // working
json root_8 = {{13, 14}}; // not working
json root_9 = {"command"}; // not working
json root_10 = {"command", "test"}; // not working
json root_11 = {{"command", true}}; // not working
json root_12 = {{"command", 10}}; // not working
json root_13 = {{"command", "test"}}; // not working
json root_14 = json({{"command", "test"}}); // not working

Seems to be a problem with non basic types passed without parsing.

@nlohmann nlohmann added the platform: arm related to ARM architecture label Feb 14, 2018
@nlohmann
Copy link
Owner

What is function parseCommand in your stack trace?

@nlohmann
Copy link
Owner

Do you know a cross compiler for macOS so I could try to reproduce the issue? The code in #973 (comment) runs without issues on my machine...

@dns13
Copy link
Contributor Author

dns13 commented Feb 15, 2018

It's a server application which listens for json commands on tcp. The parseCommand function decides - dependand on an "command": "string" object in the request json - which function is called to answer this request. Implementation with std::map, an enum and switch is a bit hacky to avoid huge if blocks.

All command dependand functions have a similiar design, request_token is only the first command in the login chain, so the first to crash. All similiar functions show the same behavior.

I'm using arm-poky-linux-gnueabi-g++ out of my poky sdk; don't know if it will run on macOS.

My tests (not very good ones as it shows) are working on both systems. Will try to compile my program for amd64 to see if the problem is platform or design dependand. Edit: no problem on amd64, but code is not 1:1 due to missing hardware when not running on embedded system

I will also try to create small example code recreating my call chain to hopefully reproduce this crash.

@dns13
Copy link
Contributor Author

dns13 commented Feb 15, 2018

Unforunately I can't reproduce this in any other application. Only in my server application inside this specific type of function called inside a switch statement.

When I replace all occurencies of json root = {...} with json root; root = {...} everything is working fine. But there seems to be another underlying issue with my code.

@nlohmann nlohmann added the state: help needed the issue needs help to proceed label Feb 25, 2018
@nlohmann
Copy link
Owner

I have no idea how to continue here.

@dns13
Copy link
Contributor Author

dns13 commented Feb 26, 2018

I will head back if I can contribute more information. I'm currently busy with other projects, when I have some time debugging, I dig deeper into it.

@dns13
Copy link
Contributor Author

dns13 commented Mar 5, 2018

Made some structural changes in my callchain, now the problem is gone:

My switch statement is no longer directly calling the corresponding function, it now returns a std::function which is then called afterwards.

Still no clue if my problem is related to this library or some other problem with my code. Seems to be a combination - since it worked in v2. But feel free to close this issue.

@nlohmann
Copy link
Owner

nlohmann commented Mar 5, 2018

Thanks for checking back! I shall close the issue.

@nlohmann nlohmann closed this as completed Mar 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: arm related to ARM architecture state: help needed the issue needs help to proceed
Projects
None yet
Development

No branches or pull requests

3 participants