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

[SDK] Memory allocation error using the Python bindings of MasterBoardInterface #37

Open
sduminy opened this issue Jan 22, 2020 · 5 comments

Comments

@sduminy
Copy link

sduminy commented Jan 22, 2020

Hello all,
I am using the Python bindings of the MasterBoardInterface in a Python script to test some P_controller on the robot. The experimentation runs well but when arriving at the line MasterBoardInterface(name_interface).Stop(), I get errors such as Error in 'python3' : double free or corruption (out) or Error in 'python3' : free() : invalid pointer as well as Segmentation fault, which make me think that there is an issue with the allocation memory in the C++ file.
Could someone solve this problem ?
Thanks,

@nim65s
Copy link
Contributor

nim65s commented Jan 22, 2020

I could investigate, if no one with more experience with the code has enough time.

@paLeziart
Copy link
Collaborator

When I did my tests of example.py with Python 2.7 I had no such issue.

When you say that the error happens at the line MasterBoardInterface(name_interface).Stop(), is MasterBoardInterface(name_interface).Stop() exactly your line?

If yes then the issue is likely because you are creating a masterboard interface (MasterBoardInterface(name_interface) is the constructor) then immediately stopping it with .Stop() without it being initialized with .Init().

Here is an example of creation, initialization and stop:

robot_if = mbs.MasterBoardInterface(name_interface)
robot_if.Init()  # Initialization of the interface between the computer and the master board
[... CODE ... ]
robot_if.Stop()  # Shut down the interface between the computer and the master board

When you call Init() that happens:

link_handler_ = new ETHERNET_manager(if_name_, my_mac_, dest_mac_);
link_handler_->set_recv_callback(this);
link_handler_->start();

And when you call Stop():

((ESPNOW_manager *)link_handler_)->unset_filter();
link_handler_->stop();
return 0;

So if you call Stop() without calling Init() then link_handler_->stop(); wants to free the link_handler_ pointer which has not been initialized. There is just LINK_manager *link_handler_; in the master_board_interface.h and it is assigned something with link_handler_ = new ETHERNET_manager(if_name_, my_mac_, dest_mac_); in Init(). It would explain these error messages (trying to free a non-assigned pointer).

@sduminy
Copy link
Author

sduminy commented Jan 28, 2020

When you say that the error happens at the line MasterBoardInterface(name_interface).Stop(), is MasterBoardInterface(name_interface).Stop() exactly your line?

Yes, I used some print() to locate the error to this line.

If yes then the issue is likely because you are creating a masterboard interface (MasterBoardInterface(name_interface) is the constructor) then immediately stopping it with .Stop() without it being initialized with .Init().

I think the line .Stop() was at the same indentation as .Init() so the problem should not come from that...

I think, the better way to solve this would be to run the example.py programm with Python3 on the RT computer in salle Bauzil.

@thomasfla
Copy link
Member

I tested the current master branch on adaRT with python3 and did not get any error. I will close this issue for now, fell free to reopen it if the bug persist.

@thomasfla thomasfla reopened this Feb 6, 2020
@thomasfla
Copy link
Member

After more testing, this issue still persist !

@thomasfla thomasfla changed the title Memory allocation error using the Python bindings of MasterBoardInterface [SDK] Memory allocation error using the Python bindings of MasterBoardInterface Jun 2, 2021
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

4 participants