I didn't put version in summary because this seems occurred in all versions. In my installation, elogv failed to start lately, with the following traceback: Traceback (most recent call last): File "/usr/bin/elogv", line 561, in <module> curses.wrapper(ElogViewer) File "/usr/lib64/python2.7/curses/wrapper.py", line 43, in wrapper return func(stdscr, *args, **kwds) File "/usr/bin/elogv", line 117, in __init__ self.init_screen() File "/usr/bin/elogv", line 254, in init_screen self.fill_file_pad() File "/usr/bin/elogv", line 371, in fill_file_pad self.file_pad = curses.newpad(len(self.packages),self.width) _curses.error: curses function returned NULL A little investigation shows that, this will happen when there are more than 32767 log messages, I just reached that limit a few months ago (I have messages dated back in 2008 in this particular gentoo box) Reproducible: Always Steps to Reproduce: 1.have more than 32767 log messages 2.run elogv Actual Results: traceback as above Expected Results: should run normally `man newpad` shows that the first argument is of int type (int nlines), in 32-bit environment (c compiler/runtime), 32767 (2^15 -1) is a common value for INT_MAX, I guess this limitation might be relevant to the bug. I used the word `guess` because in fact, INT_MAX on my 64-bit installation is 2147483647, which is the correct value for 64-bit signed int, maybe that limitation was imposed by python binding of ncurses. Hope this helps.
I'm afraid the best we could do is either * not show some of those logs or * fail with a better error message.
Hi all, it seems that I also reach this limitation today, so thanks for the report cause it prevents me from investing more time into it. My error message: elogv Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/elogv", line 692, in <module> curses.wrapper(ElogViewer) File "/usr/lib64/python2.7/curses/wrapper.py", line 43, in wrapper return func(stdscr, *args, **kwds) File "/usr/lib/python-exec/python2.7/elogv", line 228, in __init__ self.init_screen() File "/usr/lib/python-exec/python2.7/elogv", line 365, in init_screen self.fill_file_pad() File "/usr/lib/python-exec/python2.7/elogv", line 499, in fill_file_pad self.file_pad = curses.newpad(len(self.packages),self.width) _curses.error: curses function returned NULL
So I guess we would need to truncate the list of entries upfront to prevent breakage? Does anyone have some time time make a pull request for https://github.com/gentoo/elogv/pulls?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=afa99806777a02073acd31dbd8d92c8627aa42f1 commit afa99806777a02073acd31dbd8d92c8627aa42f1 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2018-07-08 16:34:58 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2018-07-08 16:35:51 +0000 app-portage/elogv: 0.7.8 Closes: https://bugs.gentoo.org/479966 Package-Manager: Portage-2.3.40, Repoman-2.3.9 app-portage/elogv/Manifest | 1 + app-portage/elogv/elogv-0.7.8.ebuild | 52 ++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+)
