Document that it is unsafe to call `curses.initscr` after `curses.setupterm`

[YuanchengJiang]

Bug report

Bug description:

import curses
import sys
import os

# Ensure TERM is set so setupterm doesn't fail
if not os.environ.get('TERM'):
    os.environ['TERM'] = 'xterm'

# 1. First allocation (from TestCurses.setUpClass)
# This allocates the first 'struct term' and assigns it to the global cur_term.
try:
    curses.setupterm(fd=sys.stdout.fileno())
except curses.error:
    # If setupterm fails (e.g. no terminal info), we can't reproduce the leak.
    sys.exit(0)

# 2. Second allocation (from TestCurses.setUp -> curses.initscr)
# initscr() internally calls newterm(), which allocates a NEW 'struct term'.
# This overwrites the global cur_term pointer, leaking the memory from step 1.
stdscr = curses.initscr()

# Cleanup (standard curses exit, though the leak has already happened)
curses.endwin()

=================================================================
==149149==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 760 byte(s) in 1 object(s) allocated from:
    #0 0x5f83747a0189 in calloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x386189) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160ed819 in _nc_setupterm (/lib/x86_64-linux-gnu/libtinfo.so.6+0x1b819) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

Indirect leak of 4106 byte(s) in 3 object(s) allocated from:
    #0 0x5f83747a03ac in realloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x3863ac) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160e26cc in _nc_doalloc (/lib/x86_64-linux-gnu/libtinfo.so.6+0x106cc) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

Indirect leak of 3904 byte(s) in 1 object(s) allocated from:
    #0 0x5f837479ffb4 in malloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x385fb4) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160e1fff  (/lib/x86_64-linux-gnu/libtinfo.so.6+0xffff) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

Indirect leak of 1614 byte(s) in 1 object(s) allocated from:
    #0 0x5f837479ffb4 in malloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x385fb4) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160ecacd in _nc_read_termtype (/lib/x86_64-linux-gnu/libtinfo.so.6+0x1aacd) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)
    #2 0x726574780610019c  (<unknown module>)

Indirect leak of 940 byte(s) in 1 object(s) allocated from:
    #0 0x5f837479ffb4 in malloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x385fb4) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160ed287 in _nc_read_termtype (/lib/x86_64-linux-gnu/libtinfo.so.6+0x1b287) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)
    #2 0x726574780610019c  (<unknown module>)

Indirect leak of 608 byte(s) in 1 object(s) allocated from:
    #0 0x5f837479ffb4 in malloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x385fb4) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160e2119  (/lib/x86_64-linux-gnu/libtinfo.so.6+0x10119) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

Indirect leak of 608 byte(s) in 1 object(s) allocated from:
    #0 0x5f83747a0189 in calloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x386189) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160ed37e in _nc_read_termtype (/lib/x86_64-linux-gnu/libtinfo.so.6+0x1b37e) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

Indirect leak of 78 byte(s) in 1 object(s) allocated from:
    #0 0x5f837479ffb4 in malloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x385fb4) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160e204b  (/lib/x86_64-linux-gnu/libtinfo.so.6+0x1004b) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

Indirect leak of 46 byte(s) in 1 object(s) allocated from:
    #0 0x5f837479ffb4 in malloc (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x385fb4) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160e1fde  (/lib/x86_64-linux-gnu/libtinfo.so.6+0xffde) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

Indirect leak of 6 byte(s) in 1 object(s) allocated from:
    #0 0x5f83747864fa in strdup (/home/fuzz/WorkSpace/FusionFuzzLoop/projects/cpython/cpython/build/python+0x36c4fa) (BuildId: 066bbf729257aedd916af3db6dae04834cf3a8ba)
    #1 0x7691160ed8ae in _nc_setupterm (/lib/x86_64-linux-gnu/libtinfo.so.6+0x1b8ae) (BuildId: e22ba7829a55a0dec2201a0b6dac7ba236118561)

SUMMARY: AddressSanitizer: 12670 byte(s) leaked in 12 allocation(s).

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-144067: Fix memory leak when initscr() follows setupterm() #144076
• gh-144067: Document terminal leak when initscr() follows setupterm() #152624
• [3.15] gh-144067: Document terminal leak when initscr() follows setupterm() (GH-152624) #152894
• [3.13] gh-144067: Document terminal leak when initscr() follows setupterm() (GH-152624) (GH-152894) #152898
• [3.14] gh-144067: Document terminal leak when initscr() follows setupterm() (GH-152624) (GH-152894) #152899

[picnixz]

Two possible solutions:

• Forbid initscr() after setupterm() though I need to check if curses allows me this restriction.
• Find another way to deallocate the current terminal. The problem is that we do not know whether cur_term is being used elsewhere and this may be annoying.

I will investigate when I am back home, that is, this week-end.

[picnixz]

So I didn't have time to investigate. If someone wants to help here, we need a solution that is not deterimental and that could still work with the capsule API (my major concern). I don't know if forbidding initscr() after setupterm() makes sense (it would be the easiest approach...). Or just document that we shouldn't do it because we can't reliably find a way to deallocate the terminal.

[serhiy-storchaka]

Suggest documenting rather than fixing in code.

This is standard ncurses single-cur_term behaviour -- initscr()/newterm() allocates a new terminal and abandons the one setupterm() made; C leaks the same. del_curterm() isn't safe to call automatically (capsule API + live terminfo queries -- hence gh-144076 stalled), and forbidding the sequence would break our own test suite's setUpClass/setUp pattern. It's a one-time libtinfo leak, so a note on setupterm() should do:

Note: Calling initscr() or newterm() after setupterm() leaks the terminal setupterm() allocated: the curses library keeps a single current terminal and does not free the previous one.