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

Crashing on json::at #2062

Closed
IreliaNina opened this issue Apr 24, 2020 · 6 comments
Closed

Crashing on json::at #2062

IreliaNina opened this issue Apr 24, 2020 · 6 comments
Labels
solution: invalid the issue is not related to the library state: needs more info the author of the issue needs to provide more details

Comments

@IreliaNina
Copy link

IreliaNina commented Apr 24, 2020

Hello, I'm trying to parse json objects sent from the client to my server. I completely undertsand that the client at times might not send valid json data in case of packet manipulation but I assume if I try catch json parse and json.at then I shouldn't have any issues. But it seems when I try to catch json::at get an out of range exception.

The client is sending non valid empty json like this
{}

This is the code for checking the valid json

    message[length] = 0;
    const std::string payload(message);
    
    json packet;
    try {
        packet = json::parse(payload);
    } catch (json::parse_error& e) {
        std::cerr << e.what() << std::endl;
        return ;
    }
    uint32_t packetid = 0;
    try {
        packetid = packet.at("id");
    } catch (std::exception& e) {
        std::cerr << e.what() << std::endl;
        return ;
    }
    std::cout << payload << std::endl;

When I send an invalid json the code should return but instead it just crashes.
This is where it seems to be crashing.

#1 0x000000010003bfb5 in std::__1::__throw_out_of_range(char const*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdexcept:262

this std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>, std::__1::less<void>, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer> > > > * 0x000000010082ea10 size=0 0x000000010082ea10

    0x10003bf15 <+37>: mov    rax, qword ptr [rbp - 0x20]
    0x10003bf19 <+41>: cmp    qword ptr [rax], 0x0
    0x10003bf1d <+45>: jne    0x10003bf2f               ; <+63> at map:1544:40
    0x10003bf23 <+51>: lea    rdi, [rip + 0x16e620]     ; "map::at:  key not found"
    0x10003bf2a <+58>: call   0x10003bf50               ; std::__1::__throw_out_of_range at stdexcept:260
->  0x10003bf2f <+63>: mov    rax, qword ptr [rbp - 0x20]

I'm not sure if this is a bug with the source code or I'm doing something wrong but the way I see it, in case of an invalid json the code shouldn't continue. And if it does continue then catching std::exception should prevent the crash.

@OmnipotentEntity
Copy link
Contributor

OmnipotentEntity commented Apr 24, 2020

As far as I can tell, the code you work ought to work, as a json::out_of_range derives from json::exception which derives from std::exception.

It seems like the first part of your code directly catches a json::parse_error, and because you didn't mention that it doesn't work, I assume it does. So does the second try block work if you try to catch a json::out_of_range exception directly?

If so, you might have an issue where you have multiple definitions of std::exception floating about, and the two types (std::exception at your try block and the std::exception that the compiler finds when parsing exceptions.hpp) might be different?

@IreliaNina
Copy link
Author

IreliaNina commented Apr 25, 2020

Hello. Thank you for the reply. I can try catching out_of_range exception directly sure. And yes to answer your question, the json::parse_error does seem to work. Although it's strange because json::parse doesn't throw an exception even in the case of an invalid json.. It's the json::at throwing the exception. I'm confused about what you mean right here though.

If so, you might have an issue where you have multiple definitions of std::exception floating about,

Is it not good to try catch std::exception in several different locations?

Edit: Trying to catch json out of range or std out of range still results in a crash. So I'm confused.

Edit2: I'm pretty sure this is an error with my code because when I isolate the issue in a separate project..I don't crash. I just have no idea why calling it in the current project results in a crash.

@nlohmann
Copy link
Owner

In order to asses your issue, we need the following information:

  • Please describe the steps to reproduce the issue. Can you provide a small but working code example?

  • Which compiler and operating system are you using? Is it a supported compiler?

  • Did you use a released version of the library or the version from the develop branch?

@nlohmann nlohmann added the state: needs more info the author of the issue needs to provide more details label Apr 25, 2020
@IreliaNina
Copy link
Author

In order to asses your issue, we need the following information:

  • Please describe the steps to reproduce the issue. Can you provide a small but working code example?
  • Which compiler and operating system are you using? Is it a supported compiler?
  • Did you use a released version of the library or the version from the develop branch?

I apologise, the crashing was my fault. It's not a bug in your code. This thread can be closed.

@nlohmann
Copy link
Owner

Thanks for checking back!

@nlohmann nlohmann added solution: invalid the issue is not related to the library and removed kind: bug labels Apr 25, 2020
@herzoni
Copy link

herzoni commented Apr 19, 2021

Hi IreliaNina,
I am also getting the same issue with no obvious problem in my code. Can you please share your experience how was it solved?
Thanks in advance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
solution: invalid the issue is not related to the library state: needs more info the author of the issue needs to provide more details
Projects
None yet
Development

No branches or pull requests

4 participants