This just really just a tracking bug for an bug I opened with Python upstream (issue 39819) for a crash in Python-3.7 inside a uclibc-ng-1.0.32 chroot on MIPS hardware. When built against sys-libs/ncurses-6.2, the 'curses' module will segfault when imported in Python: # 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 # python -m curses Segmentation fault dmesg: [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] gdb bt (snippet): # gdb /usr/lib/python-exec/python3.7/python python37_ncurses62c.core Core was generated by `/usr/lib/python-exec/python3.7/python'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x77458c6c in PyInit__curses () at /var/tmp/portage/dev-lang/python-3.7.6/work/Python-3.7.6/Modules/_cursesmodule.c:3482 Affected code in PyInit__curses() around line 3482 in Modules/_cursesmodule.c: 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; When 'key' is '257', the 'keyname' function will return a NULL pointer (as far as I can tell), which causes a crash when cast to a char *: (gdb) up #1 0x77458c6c in PyInit__curses () at /var/tmp/portage/dev-lang/python-3.7.6/work/Python-3.7.6/Modules/_cursesmodule.c:3482 3482 key_n = (char *)keyname(key); (gdb) info locals key = 257 key_n = 0x779dad70 <PyUnicode_AsUTF8+64> "\217\334" key_n2 = 0xa284e768 <error: Cannot access memory at address 0xa284e768> m = 0x775f1db0 d = 0x775f1de0 v = 0x775d5710 c_api_object = 0x775d57a0 PyCurses_API = {0x7746c1a0 <PyCursesWindow_Type>, 0x77443dd8 <func_PyCursesSetupTermCalled>, 0x77443e60 <func_PyCursesInitialised>, 0x77443ee8 <func_PyCursesInitialisedColor>} For now, in a uclibc-ng chroot on MIPS hardware, one has to stick with ncurses-6.1-r3, which works fine. One of the later 6.1 datestamp versions also worked okay, but the latest 20190609 I believe also fails, so it's obviously a change in ncurses code added during 2019 that created the problem (macro or include I'm guessing), but the faulting code is itself in Python. Core dump is available to anyone at the Gentoo level that wants to take a crack at debugging it. Assigning to the Python team for now, but CC'ing MIPS and embedded as the primary users of uclibc-ng. Also including base-system, since I suspect any fix may have to go towards ncurses, but let's see what Python upstream says first.
I have abandoned uclibc-ng stages for MIPS right now. Currently only building for glibc and musl/o32. I may attempt uclibc-ng again at some point, but it will require scrapping a seed filesystem together from scratch or using a base like an OpenADK build, so it's going to be a while before that happens.
