›

terminate called after throwing an instance of 'std::out_of_range'

mvela1mvela1
edited February 2019 in Python

I'm running a script that logs both accelerometer and gyro data using the data fuser method and downloads them after sleeping for a couple of seconds which seems to work just fine. The problem is after running the script a couple of times I get this error:

terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)
Aborted (core dumped)

The error seems to occur when trying to connect to the board. After getting this error I also get it again for any other example script that I run. What could be the possible cause of this error and how can I fix it?

Edit: It seems to have something to do with the auto generated json file in .metawear. Removing the json file seems to temporarily fix it until it is overwritten by one that causes the error.

Comments

  • EricEric

    Huh..weird..Upload one each of the json files that works and throws the exception.

    You can pass in deserialize=False to the MetaWear constructor to not load the json file.

  • mvela1mvela1

    Sure, had to upload them as .txt files because .json is not supported. For more context that script was looping to start, stop, and download the log. I am no longer doing that because I found out that you can download while logging.

  • EricEric
    edited February 2019

    I'm not running into any issue with the exception json file with the example scripts. Can you post a minimal script that consistently exhibits this behavior?

  • mvela1mvela1

    This problem occurs for me no matter what script I run when the exception file is in .metawear. I attached a very minimal script where it also occurs. Also, could you please double check that the exception.json file was correctly renamed to the MAC address of your device when it is in .metawear.

  • LauraLaura
    edited February 2019

    @mvela1,

    I went ahead and was able to reproduce your error but Eric's suggested fix worked for me. Here were my steps:

    1. I downloaded your files and put them in the right folder. First I first got this error:

    I fixed this by removing the voidp import.

    1. I ran this again and got the error you are seeing:

    Then I updated your script using Eric's suggested fix and it worked once again:

    1. I ran the new script:

    That being said, I wasn't surprised seeing the error because I am using a rev2 MMC and your file was for a rev3 MMR.

    So then I went ahead and deleted the .json file and started running your script over and over again.

    1. After running about 10 times, I was never able to reproduce the issue and everything worked fine:

    I was not able to reproduce your issue with my own .json.

    I ran your exception.json file through a checker: https://jsonformatter.curiousconcept.com/
    It said your file was fine.
    I also checked permissions but it looked fine as well.

    Are you seeing this issues with different hardware?
    Do you have another board you can experiment with?
    Are you getting this after a firmware update?

  • mvela1mvela1

    Yes, Eric's fix worked for me as well. The create_voidp import comes from here. I did try it on two MetaMotionR boards and both ended up generating a json that caused an exception eventually. The issue might have arose from the initial script I used to have, because I have been running a lot of other scripts and haven't ran into this issue again.

  • LauraLaura

    @mvela1,
    Thanks for the update.

  • EricEric

    The> @mvela1 said:

    This problem occurs for me no matter what script I run when the exception file is in .metawear. I attached a very minimal script where it also occurs. Also, could you please double check that the exception.json file was correctly renamed to the MAC address of your device when it is in .metawear.

    I must have misnamed the json file when I tested. I can reproduce the exception and have identified where the problem is (logger.cpp:529 if you're curious).

    It would seem like the serialization code does not properly persist a fused data logger. I'll have to investigate further.

  • EricEric

    After running some tests, the specific serialized state that was causing this exception is created when the actual board state disagrees with what the C++ SDK thinks the board state is.

    To avoid this desync, don't serialize the state if you are expecting to modify the board state before using it again with the same host device.

Sign In or Register to comment.