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 on 2009-11-02
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nano (Debian)
Fix Released
nano (Ubuntu)
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
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
 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
 ?? ()
 ?? ()
 ?? ()
 ?? ()
 ?? ()
Title: nano crashed with SIGSEGV
Uname: Linux 2.6.31-14-generic x86_64
UserGroups: adm admin cdrom dialout fuse lpadmin plugdev sambashare

ski (skibrianski) wrote :
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) on 2009-11-02
visibility: private → public
ski (skibrianski) wrote :

Here's an strace (attached)

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.

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)

Changed in nano (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
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.

ski (skibrianski) wrote :

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

ski (skibrianski) wrote :

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

description: updated
ski (skibrianski) wrote :

Applied upstream in nano 2.2 --

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
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

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

Other bug subscribers