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

z_declare_publisher and then z_undeclare_publisher results in memory leak (zenoh-c and Rust) #1518

Open
smnrgrs opened this issue Oct 8, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@smnrgrs
Copy link

smnrgrs commented Oct 8, 2024

Describe the bug

The memory allocated by calling z_declare_publisher is not released when z_undeclare_publisher or z_publisher_drop is called.
I have an application which has high numbers of objects, each with a high number of updates. Publishers being created and destroyed over time results in the application memory growing and never being returned.

To reproduce

To reproduce:
Loop calling z_declare_publisher and z_undeclare_publisher with a changing keyexpr every iteration. Monitor memory used which will increase by more than 2KB per iteration.

Example main from z_pub.c:

int main(int argc, char** argv) {
    zc_init_log_from_env_or("error");

    z_owned_config_t config;
    struct args_t args = parse_args(argc, argv, &config);

    printf("Opening session...\n");
    z_owned_session_t s;
    if (z_open(&s, z_move(config), NULL) < 0) {
        printf("Unable to open session!\n");
        exit(-1);
    }

    for (int idx = 0; 1; ++idx)
    {
        z_sleep_ms(10);

        z_owned_publisher_t pub;
        z_view_keyexpr_t ke;

        // Add idx to key expr
        char theKeyExp[100] = {0};
        sprintf(theKeyExp, "%s%d", args.keyexpr, idx);
        z_view_keyexpr_from_str(&ke, theKeyExp);

        if (idx%1000 == 0)
            printf("Declaring Publisher on '%s'...\n", theKeyExp);

        if (z_declare_publisher(&pub, z_loan(s), z_loan(ke), NULL) < 0) {
            printf("Unable to declare Publisher for key expression!\n");
            exit(-1);
        }
        z_sleep_ms(10);
        z_undeclare_publisher(z_move(pub));
    }
    z_close(z_move(s), NULL);
    return 0;
}

System info

Platform: Intel i7 Windows 10 VS2019
Zenoh-c tag: 1.0.0.10
Reproduced in Zenoh Rust 1.0.0-beta4 on Ubuntu 22

@smnrgrs smnrgrs added the bug Something isn't working label Oct 8, 2024
@smnrgrs smnrgrs changed the title z_declare_publisher and then z_undeclare_publisher results in memory leak (zenoh-c) z_declare_publisher and then z_undeclare_publisher results in memory leak (zenoh-c and Rust) Oct 8, 2024
@gabrik
Copy link
Contributor

gabrik commented Oct 23, 2024

Hi @smnrgrs, can you please provide an MVP for this bug and/or some valgrind logs?
That would help us reproduce and understand from where it comes from.

@smnrgrs
Copy link
Author

smnrgrs commented Nov 1, 2024

Hi @gabrik, I've done some more analysis. Running under Valgrind on Linux showed no memory leak.
Using test code above (tweaked to update it for release 1.0.0) I've found the following:

  • Every iteration of declaring a publisher results in a couple of KB of memory being used.
  • This memory is not released when z_undeclare_publisher or z_drop(z_move(pub)) is called
  • This memory is released when z_drop(z_move(session)) is called before the application shuts down.

So it's not a memory leak as such, but I would expect this memory to be released when the publisher is undeclared, rather than when the session is shut down.

Use case:
Every time a car enters our traffic management area we declare a unique publisher for it, and keep publishing updates using that publisher (for 10 minutes or so) until the car is out of the area. This issue means that our application memory grows and grows, so we can't run for very long.

The issue should be retitled as:
Memory allocated by z_declare_publisher isn't released until the session is dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants