Description of problem: Installation crashes after entering a too long device number (more than 4 characters) when adding a new DASD device via GUI: Anaconda received signal 11!. /usr/lib64/python3.5/site-packages/pyanaconda/_isys.so(+0x1382)[0x3ffb1781382] [0x3fff8f77386] /lib64/libglib-2.0.so.0(g_strnfill+0x26)[0x3ffb1d7448e] /lib64/libbd_s390.so.0(bd_s390_sanitize_dev_input+0x74)[0x3ffae7018a4] /lib64/libffi.so.6(ffi_call_SYSV+0x98)[0x3ffb1c85a00] /lib64/libffi.so.6(ffi_call+0x78)[0x3ffb1c86178] /usr/lib64/python3.5/site-packages/gi/_gi.cpython-35m-s390x-linux-gnu.so(+0x3608c)[0x3ffb20b608c] /usr/lib64/python3.5/site-packages/gi/_gi.cpython-35m-s390x-linux-gnu.so(+0x37ffa)[0x3ffb20b7ffa] /usr/lib64/python3.5/site-packages/gi/_gi.cpython-35m-s390x-linux-gnu.so(+0x36912)[0x3ffb20b6912] /lib64/libpython3.5m.so.1.0(PyObject_Call+0x7a)[0x3ffb9e70d52] /lib64/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x1784)[0x3ffb9f4ffcc] /lib64/libpython3.5m.so.1.0(+0x15a58e)[0x3ffb9f5a58e] /lib64/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x81f6)[0x3ffb9f56a3e] /lib64/libpython3.5m.so.1.0(+0x15a58e)[0x3ffb9f5a58e] /lib64/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x6a)[0x3ffb9f5a6f2] /lib64/libpython3.5m.so.1.0(+0xa486a)[0x3ffb9ea486a] /lib64/libpython3.5m.so.1.0(PyObject_Call+0x7a)[0x3ffb9e70d52] /lib64/libpython3.5m.so.1.0(+0x8bf14)[0x3ffb9e8bf14] /lib64/libpython3.5m.so.1.0(PyObject_Call+0x7a)[0x3ffb9e70d52] /lib64/libpython3.5m.so.1.0(PyEval_CallObjectWithKeywords+0x62)[0x3ffb9f4e44a] [New LWP 1680] [New LWP 1681] [New LWP 1731] [New LWP 1732] [New LWP 1757] [New LWP 1809] [New LWP 1835] [New LWP 1838] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x000003ffb9d9282c in waitpid () from /lib64/libpthread.so.0 Saved corefile /tmp/anaconda.core.1641 From the core file, I can see that the problem is in bd_s390_sanitize_dev_input: (gdb) bt #0 0x000003ffb9d9282c in __waitpid (pid=<optimized out>, stat_loc=stat_loc@entry=0x3fff8f77024, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29 #1 0x000003ffb1781446 in sync_signal_handler (signum=<optimized out>) at isys.c:143 #2 <signal handler called> #3 0x000003ffb1d7448e in memset (__len=18446744073709551615, __ch=48, __dest=0x0) at /usr/include/bits/string3.h:90 #4 g_strnfill (length=18446744073709551615, fill_char=fill_char@entry=48 '0') at gstrfuncs.c:452 #5 0x000003ffae7018a4 in bd_s390_sanitize_dev_input (dev=<optimized out>, error=0x3fff8f77878) at s390.c:286 ... Here is the piece of code: [jstodola@unused-4-196 plugins]$ cat -n s390.c | grep -B8 ^\ *286 278 if (tok) { 279 tmptok = tok + 1; /* want to ignore the delimiter char */ 280 } 281 else { 282 tmptok = lcdev; 283 } 284 285 /* calculate if/how much to pad tok with */ 286 prepend = g_strnfill((4 - strlen(tmptok)), '0'); [jstodola@unused-4-196 plugins]$ So, there should be a check if the length of the device number is valid. Version-Release number of selected component (if applicable): libblockdev-1.5-1.fc24 anaconda-24.13.4-1.fc24 python-blivet-1.20.1-1.fc24 How reproducible: always Steps to Reproduce: 1. proceed to the Installation Destination spoke 2. click "Add a disk..." 3. click "Add ECKD DASD..." 4. enter a too long device number, for example "12345" 5. click "Start Discovery" Actual results: installation crashes Expected results: a warning/error message, user should be able to continue with the installation
Created attachment 1156102 [details] backtrace
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.