reproducible crash in nano on trying to save to a file different than the one specified on the command line

Bug #471568 reported by ski
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nano (Debian)
Fix Released
Undecided
Unassigned
nano (Ubuntu)
Fix Released
Medium
ski
Nominated for Lucid by ski

Bug Description

Binary package hint: nano

Steps to reproduce:
1) Put some content into a file, e.g. echo f >f
2) open nano without arguments, or with a filename argument different from the above
3) ^O to save your work into the file 'f' (if you started nano with no arguments, you can also trigger the bug via ^X)
4) Watch nano segfault.

This happens every time. Since nano is the default editor, this is critical. I don't know how other people use nano but I like to be able to save important work with a different filename, and a segfault is unacceptable here.

ProblemType: Crash
Architecture: amd64
Date: Mon Nov 2 14:48:14 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /bin/nano
Package: nano 2.0.9-2
ProcCmdline: nano
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SegvAnalysis:
 Segfault happened at: 0x40900a: cmp %rcx,0x58(%rax)
 PC (0x0040900a) ok
 source "%rcx" ok
 destination "0x58(%rax)" (0x00000058) not located in a known VMA region (needed writable region)!
SegvReason: writing NULL VMA
Signal: 11
SourcePackage: nano
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? ()
 ?? ()
Title: nano crashed with SIGSEGV
Uname: Linux 2.6.31-14-generic x86_64
UserGroups: adm admin cdrom dialout fuse lpadmin plugdev sambashare

Revision history for this message
ski (skibrianski) wrote :
Revision history for this message
ski (skibrianski) wrote :

Probably not relevant, but just in case it is, this is on a machine that was upgraded from jaunty via apt-get dist-upgrade.

ski (skibrianski)
visibility: private → public
Revision history for this message
ski (skibrianski) wrote :

Here's an strace (attached)

Revision history for this message
ski (skibrianski) wrote :

Update: Upon testing on some other machines this is present on hardy and jaunty as well as etch and lenny, and must be a very old bug, dating at least back to etch/2.0.2. The reason other folks haven't noticed is that it only happens when "set backup" is enabled in .nanorc AND you save the file to a location not specified on the command line.

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt (retraced)

StacktraceTop:write_file (name=0x13f03f0 "foo", f_open=0x0,
do_writeout (exiting=false)
do_writeout_void () at ../../src/files.c:2033
do_input (meta_key=0x7fff12cd9bdf,
main (argc=1, argv=0x7fff12cd9cf8)

Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt (retraced)
Changed in nano (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Revision history for this message
ski (skibrianski) wrote :

I'm guessing the problem is that nano is confused as to whether you have a filename there or not.

When you launch data, the data structure containing the output filename is not yet initialized, but after you input the filename, nano stats file and sees that it is there (prompting you to overwrite).

My bet is that what happens next is that nano goto's a place where it has assumed the filename is non-NULL and tries to strcat NUL and ~ .

Hopefully I'll have a chance to investigate this further and upload a patch soon.

Revision history for this message
ski (skibrianski) wrote :

Mostly a note to self: be sure to use configure --enable-nanorc when trying to reproduce this bug from source.

Revision history for this message
ski (skibrianski) wrote :

The attached patch fixes the problem and should be applied upstream.

description: updated
Revision history for this message
ski (skibrianski) wrote :

Applied upstream in nano 2.2 -- http://savannah.gnu.org/patch/?7025

What are the chances we can fix this bug by either apply the above patch or move to nano 2.2 before lucid?

Changed in nano (Ubuntu):
assignee: nobody → ski (ski-ubuntu)
status: New → Fix Committed
Revision history for this message
Anders Kaseorg (andersk) wrote :

nano 2.2.1-1 is in Lucid and this seems to be fixed. If you need a fix in previous releases, see
https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
https://help.ubuntu.com/community/UbuntuBackports#request-new-packages

Changed in nano (Ubuntu):
status: Fix Committed → Fix Released
Anders Kaseorg (andersk)
Changed in nano (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.