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

Memory leaks when using if var := some_map[type] {...} #19454

Open
larpon opened this issue Sep 27, 2023 · 0 comments
Open

Memory leaks when using if var := some_map[type] {...} #19454

larpon opened this issue Sep 27, 2023 · 0 comments
Assignees
Labels
Bug This tag is applied to issues which reports bugs. Option Type Bugs/feature requests, that are related to `?Type`. Result Type Bugs/feature requests, that are related to `!Type`. Unit: cgen Bugs/feature requests, that are related to the default C generating backend. Unit: Compiler Bugs/feature requests, that are related to the V compiler in general. Unit: Memory Management Bugs/feature requests, that are related to the memory management of the compiler.

Comments

@larpon
Copy link
Contributor

larpon commented Sep 27, 2023

Describe the bug

Initial message and more info in this Discord thread: https://discord.com/channels/592103645835821068/592114487759470596/1156587254429536389

Running the following code with: v -gc none run ./bug.v, produces a memory leak:

import time

enum KeyCode {
    a
    b
    c
}

[heap]
struct Keyboard {
mut:
    keys map[int]bool
}

pub fn (k Keyboard) is_key_down(keycode KeyCode) bool {
    if key_state := k.keys[int(keycode)] { // using `-trace-calls` looks like something around here leaks memory?!
        return key_state
    }
    return false
}

fn main() {
    keyboard := &Keyboard{}
    // Immitate game loop
    for {
        if keyboard.is_key_down(.b) {}
        time.sleep(2 * time.millisecond)
    }
}

Running this example with v -gc none run ./bug.v while observing memory usage, you'll notice that memory grows slowly.
Compiling with v -trace-calls -gc none run ./bug.v > /tmp/bug_trace.txt 2>&1 and examining the output after a few seconds reveals calls like like this:

> trace    22615  2255163      920 main main.Keyboard.is_key_down/2
> trace    22615  2257548     1032 builtin &map.get_check/2
> trace    22615  2259696     1128 builtin &map.key_to_index/2
> trace    22615  2261816     1176 builtin map_hash_int_4/1
> trace    22615  2264436     1048 builtin error/1
> trace    22615  2266475     1112 builtin memdup/2
> trace    22615  2268336     1416 builtin malloc/1
> trace    22615  2270560      488 time time.sleep/1
> trace    22615  4366266      984 builtin memdup/2
> trace    22615  4372384     1288 builtin malloc/1

My guess is that the error / option / result leaks memory behind the scenes?

Reproduction Steps

bug.v:

import time

enum KeyCode {
    a
    b
    c
}

[heap]
struct Keyboard {
mut:
    keys map[int]bool
}

pub fn (k Keyboard) is_key_down(keycode KeyCode) bool {
    if key_state := k.keys[int(keycode)] { // using `-trace-calls` looks like something around here leaks memory?!
        return key_state
    }
    return false
}

fn main() {
    keyboard := &Keyboard{}
    // Immitate game loop
    for {
        if keyboard.is_key_down(.b) {}
        time.sleep(2 * time.millisecond)
    }
}

Run with v -gc none run ./bug.v and observe how memory grows steadily.

Expected Behavior

No memory leak

Current Behavior

Memory leaks

Possible Solution

In this case @spytheman noted on Discord that changing the function is_key_down(keycode KeyCode) bool to the following code stops the leak:

pub fn (k &Keyboard) is_key_down(keycode KeyCode) bool {
    key_state := k.keys[int(keycode)]
    return key_state
}

This is not a general solution, though

Additional Information/Context

Initial message and more info in this Discord thread: https://discord.com/channels/592103645835821068/592114487759470596/1156587254429536389

V version

V 0.4.1 12ee3fa

Environment details (OS name and version, etc.)

EndeavourOS (Arch based / rolling) distro

Note

You can vote for this issue using the 👍 reaction. More votes increase the issue's priority
for developers.

Take into account that only the 👍 reaction counts as a vote.
Only reactions to the issue itself will be counted as votes, not comments.

@larpon larpon added Bug This tag is applied to issues which reports bugs. Unit: Memory Management Bugs/feature requests, that are related to the memory management of the compiler. Option Type Bugs/feature requests, that are related to `?Type`. Result Type Bugs/feature requests, that are related to `!Type`. labels Sep 27, 2023
@spytheman spytheman added Unit: cgen Bugs/feature requests, that are related to the default C generating backend. Unit: Compiler Bugs/feature requests, that are related to the V compiler in general. labels Sep 27, 2023
@spytheman spytheman self-assigned this Sep 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs. Option Type Bugs/feature requests, that are related to `?Type`. Result Type Bugs/feature requests, that are related to `!Type`. Unit: cgen Bugs/feature requests, that are related to the default C generating backend. Unit: Compiler Bugs/feature requests, that are related to the V compiler in general. Unit: Memory Management Bugs/feature requests, that are related to the memory management of the compiler.
Projects
None yet
Development

No branches or pull requests

2 participants