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

Replace new with malloc for non-class calls #7868

Merged
merged 2 commits into from
Dec 13, 2023

Conversation

mrengineer7777
Copy link
Collaborator

@mrengineer7777 mrengineer7777 commented Feb 20, 2023

Description of Change

This PR resolves potential crashing issues when allocating memory using new keyword. Will be replacing with malloc for non-class calls. Targeting 3.0.x branch.

Tests scenarios

arduino-esp32 core v2.0.7 with Adafruit Feather ESP32.

Related links

Please provide links to related issue, PRs etc.

Started by issue #7558. PR #8065 will fix the issue on 2.x branch.

@me-no-dev
Copy link
Member

Given that all places that need changing are byte buffers, why not switch to malloc and free instead?

@mrengineer7777
Copy link
Collaborator Author

Given that all places that need changing are byte buffers, why not switch to malloc and free instead?

I had the same thought. This PR will likely switch those lines to malloc but also resolve other potential new issues. This PR will take a lot of research and also a test project to demonstrate that it DOES resolve potential crashes.

@mrengineer7777
Copy link
Collaborator Author

I've decided to limit the scope of this PR to just replacing new with malloc in cases where a class constructor isn't called. This will limit conflicts with ongoing refactoring work. I'm not aware of any crashes related to missing nothrow, and from what I understand a class should have a nothrow variant to guarantee it won't crash.

@mrengineer7777 mrengineer7777 changed the title Use new(std::nothrow) to prevent crashes Replace new with malloc for non-class calls Feb 28, 2023
@mrengineer7777 mrengineer7777 force-pushed the new_nothrow branch 2 times, most recently from 8ad0335 to e346d55 Compare February 28, 2023 16:51
@mrengineer7777
Copy link
Collaborator Author

Help needed: std::unique_ptr<uint8_t[]> buf(new uint8_t[bufSize]);

std::unique_ptr<uint8_t[]> buf(new uint8_t[bufSize]);

Why did this use unique_ptr?

Reworked here: e20bcfa
Needs review!

@me-no-dev me-no-dev added this to the 3.0.0 milestone Apr 10, 2023
@mrengineer7777 mrengineer7777 marked this pull request as ready for review April 10, 2023 21:14
@me-no-dev
Copy link
Member

Help needed: std::unique_ptr<uint8_t[]> buf(new uint8_t[bufSize]);

std::unique_ptr<uint8_t[]> buf(new uint8_t[bufSize]);

Why did this use unique_ptr?

std::unique_ptr is a smart pointer that owns and manages another object through a pointer and disposes of that object when the unique_ptr goes out of scope. More or less it will automatically free the buffer on function exit

@VojtechBartoska VojtechBartoska added the Status: Awaiting triage Issue is waiting for triage label Nov 28, 2023
@VojtechBartoska
Copy link
Collaborator

@me-no-dev What about this PR? Is it still valid?

Resolved possible crash in EspClass::getSketchMD5().
@mrengineer7777
Copy link
Collaborator Author

Rebased PR on latest master. No conflicts. I'm open to suggestions on what parts of this PR you guys want to keep.

We should at least include the crash fix from #8065 to WiFiUDP.cpp. In fact, why didn't the fix on the 2.x branch get added to 3.x? Is it because we were going to merge this PR instead?

@me-no-dev
Copy link
Member

Is it because we were going to merge this PR instead?

Yes :)

@me-no-dev me-no-dev merged commit 02b384a into espressif:master Dec 13, 2023
38 checks passed
@VojtechBartoska VojtechBartoska modified the milestones: 3.0.0, 3.0.0-RC1 Dec 13, 2023
@mrengineer7777 mrengineer7777 deleted the new_nothrow branch December 13, 2023 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting triage Issue is waiting for triage
Projects
Development

Successfully merging this pull request may close these issues.

3 participants