Skip to content

catch error when http init fails from bad url to avoid barf. #48

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

Merged
merged 1 commit into from
Jun 17, 2025

Conversation

tavdog
Copy link
Member

@tavdog tavdog commented Jun 17, 2025

fixes #45

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary of Changes

Hello @tavdog, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request primarily enhances the robustness of network communication by implementing crucial error handling for HTTP client initialization failures. It ensures that the application can gracefully manage scenarios where invalid URLs or other issues prevent the HTTP client from being set up correctly, preventing crashes and improving overall stability. Additionally, a minor code style improvement was applied to a WiFi-related function.

Highlights

  • Error Handling for HTTP Client Initialization: Implemented a null check for the esp_http_client_handle_t returned by esp_http_client_init in remote_get. This prevents potential crashes by logging an error, freeing allocated resources (state.buf), and returning an error code if the HTTP client fails to initialize, particularly when an invalid URL is provided.
  • Code Style Improvement: A minor formatting adjustment was made to the wifi_initialize function signature in src/wifi.c for better readability and conciseness.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request primarily addresses an error handling scenario in src/remote.c by adding a check for failures during HTTP client initialization (esp_http_client_init). This prevents potential issues, such as crashes, when an invalid URL is used. The change includes logging the error, freeing an associated buffer, and returning an error code. Additionally, a minor stylistic formatting change is made in src/wifi.c for function signature readability.

Comment on lines +162 to +166
if (http == NULL) {
ESP_LOGE(TAG, "HTTP client initialization failed for URL: %s", url);
free(state.buf);
return 1;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The addition of the null check for the http client handle is a crucial improvement for robustness, preventing potential crashes if esp_http_client_init fails (e.g., due to a malformed URL).

Regarding the free(state.buf); call on line 164:
For this operation to be safe and correct, state.buf must satisfy one of the following conditions at this point:

  1. It is NULL. Calling free(NULL) is a safe no-operation. This is typically the case if the state struct instance (which state.buf is a member of) was zero-initialized (e.g., http_state_t state = {0};) and state.buf has not yet been allocated by the HTTP event handler (which wouldn't have run if init failed).
  2. It is a valid pointer to heap-allocated memory that was provisioned before esp_http_client_init was called and now needs to be explicitly freed in this error path to prevent a memory leak.

If state.buf could hold an uninitialized garbage value (e.g., if the state struct was a stack variable that wasn't initialized), calling free() on it would result in undefined behavior.

Please ensure that the state variable is managed such that state.buf is always in a valid state (either NULL or a valid heap pointer) before this free() call. If state.buf is expected to be NULL here because it's only allocated within the event handler, the free() call is benignly redundant but safe if state was zero-initialized.

@tavdog tavdog merged commit 877bbb6 into main Jun 17, 2025
1 check passed
@tavdog tavdog deleted the catch_bad_url_in_http branch June 29, 2025 22:06
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

Successfully merging this pull request may close these issues.

Need to detect malformed url before attempting to use it or device crashes (eg. gggghhhh)
1 participant