Version-Release number of selected component: nano-5.3-4.fc33 Additional info: reporter: libreport-2.15.2 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/vte-spawn-72db698b-7efb-48a8-bea0-170fa68fd54e.scope cmdline: nano /etc/pulse/default.pa crash_function: __vfprintf_internal executable: /usr/bin/nano journald_cursor: s=f9fc7f95aa72467dbda9a36e219664c8;i=142b;b=7c71deceda9845488e20b35967722d78;m=10af14148;t=5c59a47a4e466;x=9d6d99173def4fe9 kernel: 5.12.11-200.fc33.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 __vfprintf_internal at vfprintf-internal.c:1321 #1 buffered_vfprintf at vfprintf-internal.c:2295 #2 vfprintf at /usr/include/bits/stdio2.h:133 #3 die at ../../src/nano.c:366 #4 statusline at ../../src/winio.c:2085 #5 write_file at ../../src/files.c:1828 #6 emergency_save at ../../src/nano.c:328 #7 die at ../../src/nano.c:378 #8 statusline at ../../src/winio.c:2085 #9 write_file at ../../src/files.c:1828
Created attachment 1794601 [details] File: backtrace
Created attachment 1794602 [details] File: core_backtrace
Created attachment 1794603 [details] File: cpuinfo
Created attachment 1794604 [details] File: dso_list
Created attachment 1794605 [details] File: environ
Created attachment 1794606 [details] File: exploitable
Created attachment 1794607 [details] File: limits
Created attachment 1794608 [details] File: maps
Created attachment 1794609 [details] File: mountinfo
Created attachment 1794610 [details] File: open_fds
Created attachment 1794611 [details] File: proc_pid_status
nano-5.8-2.fc33 is going to Fedora stable repos: https://bodhi.fedoraproject.org/updates/FEDORA-2021-585020e53e Could you please check whether it fixes this bug?
Souptik, thanks for the report. Kamil, version 5.8 will not fix the issue. I will attach two patches that should improve things. The first one prevents the "die, write_file, statusline, die, write_file, statusline..." going round and round. The second patch will cause the "Too many errors from stdin" fault to get triggered much later, giving the user a chance to type something before that die() is called -- and typing something will probably/hopefully make wgetch() behave correctly again.
Created attachment 1795782 [details] don't die when the status bar is absent, just skip te message
Created attachment 1795783 [details] give the user a chance to purge the faulty input stream
For completeness: I rereported the issue as https://savannah.gnu.org/bugs/?60853.
Benno, thank you for watching Red Hat Bugzilla! I did not look closer because this was reported with a build of nano that was already obsolete. But you are right, this indeed looks like a stack overflow due to infinite recursion.
Hi Kamil, I wasn't watching Red Har Bugzilla -- I just happened to pass by from https://src.fedoraproject.org/rpms/nano, (after searching a replacement for https://apps.fedoraproject.org/packages/nano, which hasn't been working for something like a year). Any progress on this? Any reason why the patches in comments #14 and #15 aren't applied yet? (At least, I don't see any new versions in testing.) On https://retrace.fedoraproject.org/faf/reports/?component_names=nano&order_by=first_occurrence I see there are crashes every day, and I think the patches would prevent most of those. The patches will apply to 5.8 (and to 5.3 too with a little fuzz).
Sorry for the delay, there was a bank holiday in Czech Republic on July 5th and 6th. I have picked the commits from upstream: https://src.fedoraproject.org/rpms/nano/c/8a3a29a9
FEDORA-2021-a6fc75b1af has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a6fc75b1af
FEDORA-2021-3122d2b8d2 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3122d2b8d2
FEDORA-2021-3122d2b8d2 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3122d2b8d2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3122d2b8d2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a6fc75b1af has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a6fc75b1af` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a6fc75b1af See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-3122d2b8d2 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-a6fc75b1af has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
I have been wondering why we have seen so many crashes of nano since last January (https://retrace.fedoraproject.org/faf/reports/?component_names=nano&order_by=last_occurrence), and the other day I noticed the following line in the release notes of 'less': "Fix bug which could leave terminal in mouse-reporting mode after exiting less." Leaving the terminal in mouse reporting mode might be the cause for ncurses getch() returning many ERR results while touching the mouse or the touchpad while using nano, causing the old 123 limit to be reached and thus causing nano to die. That bug in less was introduced in version 551, which appeared in Fedora 33, and was fixed in version 590, which is not yet in Fedora. Maybe it would be a good idea to pull in less-590 into Fedora 34, to avoid problems with mouse events in other terminal apps? Or maybe just pull in the 21e0892e commit from less that fixes this issue?
Benno, thank you for letting us know! I have filed a separate bug for this: bug #1985466
It looks like the increased dying threshold that was put into place in nano has been effective in avoiding crashes: in the past three months there was only one crash [1] in nano-5.8-3 that /might/ be due to reaching the too-many-errors threshold, compared to four hundred crashes in half a year for earlier versions. So I am considering this fixed. Thanks again for reporting, Duttaroy. [1] https://retrace.fedoraproject.org/faf/reports/222605/