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 leak when sinking a lot of output #1853

Closed
kdrag0n opened this issue Jun 9, 2024 · 5 comments
Closed

Memory leak when sinking a lot of output #1853

kdrag0n opened this issue Jun 9, 2024 · 5 comments
Labels
needs-confirmation A reproduction has been reported, but the bug hasn't been confirmed or reproduced by a maintainer.

Comments

@kdrag0n
Copy link
Contributor

kdrag0n commented Jun 9, 2024

I saw #254 and #1379, but I think there's still a memory leak somewhere.

Repro for output sinking:

  • Run xxd /dev/zero
  • Watch memory usage increase steadily in Activity Monitor (~40-50 MB/sec for me)
  • Close the window and observe that most of the memory isn't released
@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 9, 2024

This suggests that it's likely pages being leaked, at least in my real-world case:

const backing = try posix.mmap(

@mitchellh
Copy link
Contributor

mitchellh commented Jun 9, 2024

I'm unable to reproduce the "output sinking" leak. My memory stabilizes and then is freed to prior values when I close the window. macOS as well.

I notice you're looking at "Memory" but that includes virtual memory which the OS is unlikely to reclaim until it actually needs it. It's not a good measure of application memory usage (for anything). Have you checked "Real Memory" instead? That value is more important and the one I see resetting for me.

Virtual memory doesn't drop for me, but that's to be expected.

EDIT: I'm not disregarding that there are leaks, but I'm not seeing anything extreme so at most it's minor in the output sinking case, as far as I can confirm so far.

@mitchellh mitchellh added the needs-confirmation A reproduction has been reported, but the bug hasn't been confirmed or reproduced by a maintainer. label Jun 9, 2024
@kdrag0n kdrag0n changed the title Memory leak when sinking a lot of output and resizing Memory leak when sinking a lot of output Jun 10, 2024
@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 10, 2024

Ok, looks like the leak I'm running into in real-world usage is caused by resizing and it seems to be a different issue, so I've split it off to #1857. Will see if I can get more details for this one.

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 10, 2024

As far as I know, Activity Monitor's "Real Memory" is RSS, and "Memory" is phys_footprint. RSS drops a lot because it doesn't include swapped or compressed pages, so in general "Memory" does seem to be a better indicator of real memory footprint than RSS.

The Page mmap regions are tame in this case: no more than ~1 GB. Closing the window frees the mmap regions as expected, but a lot of malloced objects remain:

======================================================================
ghostty [90801]: 64-bit    Footprint: 6438 MB (16384 bytes per page)
======================================================================

  Dirty      Clean  Reclaimable    Regions    Category
    ---        ---          ---        ---    ---
2539 MB        0 B       112 KB         40    MALLOC_NANO
2215 MB        0 B        33 MB         27    MALLOC_MEDIUM
1253 MB        0 B          0 B       1280    MALLOC_TINY
 298 MB        0 B      2288 KB         73    IOAccelerator (graphics)
  59 MB        0 B          0 B         17    MALLOC_SMALL
  22 MB        0 B          0 B          4    IOSurface
  16 MB        0 B          0 B          2    IOAccelerator
  13 MB        0 B          0 B          1    page table
4151 KB     544 KB          0 B        259    __DATA
2944 KB        0 B          0 B         46    Owned physical footprint (unmapped)
2033 KB        0 B          0 B        229    __AUTH_CONST
1552 KB        0 B          0 B         17    untagged ("VM_ALLOCATE")
1520 KB        0 B          0 B         10    CoreUI image data
1395 KB        0 B          0 B        272    unused dyld shared cache area
1270 KB     288 KB          0 B        152    __DATA_CONST
 878 KB        0 B          0 B        131    __DATA_DIRTY
 858 KB        0 B          0 B        157    __AUTH
 720 KB        0 B          0 B         10    CG image
 720 KB        0 B          0 B         44    MALLOC metadata
 640 KB        0 B        48 KB         39    CoreAnimation
 496 KB        0 B          0 B         18    stack
 480 KB        0 B          0 B          4    dyld private memory
 480 KB        0 B          0 B         27    ColorSync
 368 KB        0 B          0 B          5    performance tool data
 128 KB        0 B          0 B          1    Accelerate image backing stores
  48 KB        0 B          0 B          1    Activity Tracing
  39 KB        0 B          0 B          1    __OBJC_RW
  32 KB        0 B          0 B          2    IOKit
  16 KB        0 B       512 KB          2    MALLOC_LARGE
  16 KB        0 B        16 KB          2    Foundation
  16 KB    4992 KB          0 B         13    __TEXT
  16 KB        0 B          0 B          1    os_alloc_once
  16 KB        0 B          0 B          1    CoreGraphics
    0 B        0 B        16 KB          1    ImageIO
    0 B     496 KB          0 B          6    mapped file
    0 B     464 KB          0 B         11    __LINKEDIT
    0 B     384 KB          0 B         12    untagged ("VM_ALLOCATE") (graphics)
    ---        ---          ---        ---    ---
6437 MB    7168 KB        36 MB       2920    TOTAL

macOS malloc tends to call madvise(MADV_FREE_REUSABLE) pretty quickly, which subtracts from phys_footprint and adds to the Reclaimable column reported by footprint, so I don't think the objects were freed at all.

Here's my config in case it helps:

font-family = "Twilio Sans Mono"
font-family = "Cascadia Code"
font-style-bold = Semibold
font-style-bold-italic = "Semibold Italic"
font-size = 14

#adjust-cell-height = 5%

# 100 chars * 10 million
scrollback-limit = 1000000000
adjust-cursor-thickness = 200%
cursor-style-blink = false

mouse-hide-while-typing = true
mouse-scroll-multiplier = 1.5

keybind = super+f=write_scrollback_file

window-padding-x = 6
window-padding-y = 6

window-save-state = always

copy-on-select = clipboard

#macos-titlebar-tabs = true
unfocused-split-opacity = 0.8

term = xterm-256color

minimum-contrast = 1.1
#bold-is-bright = true

config-file = theme
window-theme = system

Same window size as #1857, but with no resizing. I just left xxd /dev/zero running for a while.

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 10, 2024

Ah, the malloc leak only seems to occur when running under Xcode's debugger. Only #1857 shows up in real-world usage. Sorry for the false alarm.

@kdrag0n kdrag0n closed this as completed Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-confirmation A reproduction has been reported, but the bug hasn't been confirmed or reproduced by a maintainer.
Projects
None yet
Development

No branches or pull requests

2 participants