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

Heap corruption with Vector's as function arguments #3

Closed
ghost opened this issue Jun 28, 2019 · 4 comments
Closed

Heap corruption with Vector's as function arguments #3

ghost opened this issue Jun 28, 2019 · 4 comments
Labels
question Further information is requested

Comments

@ghost
Copy link

ghost commented Jun 28, 2019

I'm getting heap corruption when passing Vector arguments to functions called by simpleRPC.

Setting Vector.destroy = false in function void _read(Vector *data) in read.tcc appears to fix the problem, although this may (will?) result in a memory leak.

Test code (snippet):

Vector<uint8_t> send_Vector(Vector<uint8_t> data) {
    ESP_LOGD("esp_connect", "send_Vector %d", data.size);
    return data[1];
}

interface(send_Vector, F("send_Vector"));
@jfjlaros
Copy link
Owner

This is probably because the vector is made (and should be destroyed) outside of the function send_Vector(). By passing the vector as is, the destructor is called when the function ends, the calling function will additionally call the destructor, which leads to undefined behaviour.

My guess is that by passing the vector by reference solves the problem, i.e.,

Vector <uint8_t>send_Vector(Vector <uint8_t>&data) { ... }

Does this help?

@jfjlaros
Copy link
Owner

By the way, your return type (Vector) does not seem to match the type of the value you return (uint8_t).

There are some examples on complex data structures in the online example. Perhaps that helps.

@ghost
Copy link
Author

ghost commented Jun 28, 2019

Yes, passing a reference solved this problem. Many thanks!

Other than that I had no issues - with simpleRPC, that is ...

@ghost ghost closed this as completed Jun 28, 2019
@jfjlaros
Copy link
Owner

Thanks for the feedback.

@jfjlaros jfjlaros added the question Further information is requested label May 16, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant