Inside a MIPS O32 chroot, based on uclibc-ng-1.0.32, if python-27 or python-3.7 are built against ncurses-6.2, then after compilation, there is a crash in the '_curses' module.  Specific to Python-3.7, the crash is in Modules/_cursesmodule.c:3482, PyInit__curses():

3477:    {
3478:        int key;
3479:        char *key_n;
3480:        char *key_n2;
3481:        for (key=KEY_MIN;key < KEY_MAX; key++) {
3482:            key_n = (char *)keyname(key);
3483:            if (key_n == NULL || strcmp(key_n,"UNKNOWN KEY")==0)
3484:                continue;
3485:            if (strncmp(key_n,"KEY_F(",6)==0) {
3486:                char *p1, *p2;

It looks like keyname() is casting to a NULL pointer and crashing when 'key' is 257.  The issue is reproducible by running python and trying to import the curses modules:

# python
Python 3.7.6 (default, Feb 29 2020, 22:51:27)
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
Segmentation fault

Or:
# python -m curses
Segmentation fault

dmesg shows this on the main host:
[99297.243445] do_page_fault(): sending SIGSEGV to python for invalid read access from 0000000000000000
[99297.243459] epc = 0000000000000000 in python3.7m[400000+10000]
[99297.243483] ra  = 0000000076a68c6c in _curses.cpython-37m-mips-linux-gnu.so[76a50000+20000]

I've been able to work out that the fault has something to do with ncurses itself.  There is no issue if built against ncurses-6.1, and even the later datestamped patches appear to be okay.  It seems like any ncurses AFTER 20190609 will exhibit the problem.  ncurses-6.2 was recently released, and it, too, causes this issue.

However, I am unable to get gdb to trace through any of the ncurses libraries.  The faulting code is in Python itself, so I assume it's something to do with a macro definition or an include provided by ncurses-6.2 that introduces the breakage.

This issue also only happens in a uclibc-ng-based root.  I have had zero issues building python-3.7 in multiple glibc-based roots and even a musl-1.1.24-based root works fine.  So I am not completely sure if the fault is truly with Python itself, or the combination of uclibc-ng, ncurses-6.2, and Python.

As far as I know, the issue may also be specific to MIPS hardware, but I do not have a similar chroot on any other architecture to verify this with.  I'll attach to this bug a gdb backtrace of Python built with -O0 and -gddb3.  I have a core file available if that will help, but will probably need to e-mail that as I'll have to include the malfunctioning python binary and the separate debug symbol files generated from my build.

Python 3.7 is no longer maintained. Please create a new issue if you are seeing this problem on a current (>= 3.9) version.