nano segfaults as root after upgrade to 15.10

Status changed to 'Confirmed' because the bug affects multiple users.

I'm getting this too. When I tried to nano my ~/bashrc file (just as me, not as root), the first two times it segfaulted. The third (and any later) times, now it displays "Couldn't determine hostname for lock file: File name too long" for ANY file I try to open or create. Upgraded from Ubuntu 15.04 to 15.10 two days ago. Attached is the crash log that apport created when nano segmentation faulted the first two times.

I forgot to mention, now I get "Couldn't determine hostname for lock file: File name too long" when I try to run nano as both me AND root.

Can you attach a strace of a run of 'nano --ignore' (without a filename)? Is your computer part of some network, does it need to ask the network about its hostname? What is the output of 'env | grep MALLOC'?

I suggest you to try Long Path Tool.

Sorry, that was a silly request. What is needed of course is a strace of: 'nano --ignore --locking filename'.

How does the long path tool help? It worked before on 15.04 (and before), but broke upgrading to 15.10... It shouldn't segfault!

env | grep MALLOC returns nothing

nano --ignore works fine...

`strace -o nano.txt nano --ignore` is http://p.defau.lt/?ggvjOCTok9EfbnKi_XNNBA

My computer is a vm from Bytemark over on their bigv platform https://www.bigv.io/ - I don't think it needs to ask the network about its hostname... How would I even verify this?

Thanks

`strace -o nano2.txt nano --ignore --locking filename.txt` is http://p.defau.lt/?T04ctRlETH_GkL6kEuqSLA

But yeah, nano --ignore works via sudo or as root

> It worked before on 15.04 (and before), but broke upgrading to 15.10...

Well, on 15.04 (nano-2.2.6), nano didn't have any file locking.

> env | grep MALLOC returns nothing

Good.

> nano --ignore works fine...

It should, because it ignores the 'set locking' that uou have in your .nanorc. As a temporary measure you can comment out that setting.

> My computer is a vm from Bytemark over on their bigv platform

Well, when it's a virtual machine, then it's not really a computer. :) And yes, then it's likely that it gets its hostname over the network. But it doesn't matter. If you can compile from source, please try the attached patch.

Neither root, nor my user have a .nanorc file, but it is in the /etc/nanorc file

Thought I'd just use `apt-get source nano` on wily, but seems that's a few revisions behind the svn repo, as free_and_fail doesn't seem to be defined (else something else is out of date/out of sync)

.deps/files.Tpo -c -o files.o files.c
files.c: In function ‘write_lockfile’:
files.c:149:6: error: label ‘free_and_fail’ used but not defined
      goto free_and_fail;
      ^

Will try getting the svn sources and try that

Thanks!

Yay, rabbit holes...

Checked out from svn, extra packages installed, run autogen, then ./configure is giving

./configure: line 8316: syntax error near unexpected token `NCURSESW,'
./configure: line 8316: ` PKG_CHECK_MODULES(NCURSESW, ncursesw,'
root@ko-kra:~/nano# dpkg -l | grep ncurses
ii libncurses5:amd64 5.9+20150516-2ubuntu1 amd64 shared libraries for terminal handling
ii libncurses5-dev:amd64 5.9+20150516-2ubuntu1 amd64 developer's libraries for ncurses
ii libncursesw5:amd64 5.9+20150516-2ubuntu1 amd64 shared libraries for terminal handling (wide character support)
ii libncursesw5-dev:amd64 5.9+20150516-2ubuntu1 amd64 developer's libraries for ncursesw
ii mtr-tiny 0.85-3 amd64 Full screen ncurses traceroute tool
ii ncurses-base 5.9+20150516-2ubuntu1 all basic terminal type definitions
ii ncurses-bin 5.9+20150516-2ubuntu1 amd64 terminal-related programs and man pages
ii ncurses-term 5.9+20150516-2ubuntu1 all additional terminal type definitions
root@ko-kra:~/nano#

The attachment "trims an overlong hostname instead of complaining" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

> but it is in the /etc/nanorc file

Ubuntu sets 'locking' by default? What's the output of 'grep locking /etc/nanorc'?

> files.c: In function ‘write_lockfile’:
> files.c:149:6: error: label ‘free_and_fail’ used but not defined
> goto free_and_fail;

Ah. But then applying the patch should have failed. Did you edit the file by hand?

Nevermind. See the updated patch for version 2.4.2. (Yes, sorry, SVN is far ahead of 2.4.2 -- there should have been a 2.4.3 two months ago.)

> ./configure: line 8316: syntax error near unexpected token `NCURSESW,'
> ./configure: line 8316: ` PKG_CHECK_MODULES(NCURSESW, ncursesw,'

Oh dear, autoconf stuff. Could you post your ./configure to nano-devel -- this error not directly related to this bug, so let's take it elsewhere. On that list (https://lists.gnu.org/mailman/listinfo/nano-devel) there will be people who understand autoconf.

Yup, 15.10 seems to. I have never edited the /etc/nanorc file, so I guess it was just updated to the default package maintainers version as per the usual. So the grep gives the obvious output:

reedy@ko-kra:~$ grep locking /etc/nanorc
set locking
reedy@ko-kra:~$

Yeah, I ended up applying the patch by hand. I guess debugging tired (on unfamiliar source code). I should have really noticed what the issue was!

Will try the patch again on the source from the 15.10 apt repo

Will post the ./configure stuff to nano-devel; that's fine by me. Certainly no config on my part, rather than just installing the necessary packages (libncurses dev packages, dh-autoconf etc)

The patch works!

Got a little confused by caching of the paths, which was returning /usr/local/bin/nano, but without the qualified path, it was using /bin/nano. Easily fixed

What happens next? I noticed your thread over at https://lists.gnu.org/archive/html/nano-devel/2015-11/msg00000.html - I guess a patch to their svn, and then something related in debian/ubuntu repo? Then poking someone to get a new package built and distributed?

Thanks!

Post sent to nano-devel too

> The patch works!

Thanks for testing. The patch will go into SVN soon, it will be in 2.4.3. But this newer version will not make it into Wily, so some Ubuntu maintainer will have to apply the attached patch to 2.4.2 and release an updated ubuntu version of nano-2.4.2.

Hello !
I've got the same error.
Could you please provide patch's URL and how-to install ?

Thanks.

> I've got the same error.

Then please click at the top of this page that you are affected too.

> Could you please provide patch's URL

You can find the patch somewhere on the right. But this is the direct URL:

https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1509081/+attachment/4513318/+files/trim-an-overlong-hostname.patch

> and how-to install ?

No. You will have to google how to get the source, apply the patch, compile, and install. Or wait for Ubuntu to apply the patch and push it out. Or change your hostname to something shorter. Or comment out the "set locking" in your /etc/nanorc file.

Wow, thanks for reply.

I've pressed affect link :)

And "comment out the "set locking" in your /etc/nanorc file." - had helped me :)

Thanks again !

Benno, thanks for the patch! I've uploaded it to xenial, which will be 16.04.

Any chance we could get it backported to 15.10 too please?

This bug was fixed in the package nano - 2.4.2-1ubuntu1

---------------
nano (2.4.2-1ubuntu1) xenial; urgency=medium

  [ Benno Schulenberg ]
  * d/p/trim-long-hostname.patch:
    - Cherry pick upstream fix for a hostname that is longer than expected,
      fixing crash (LP: #1509081). Can be dropped with 2.4.3.

 -- Michael Terry <email address hidden> Mon, 07 Dec 2015 16:28:36 -0500

Uploaded same fix to Wily for processing by the SRU team.

Hello reedy, or anyone else affected,

Accepted nano into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nano/2.4.2-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Unpacking nano (2.4.2-1ubuntu0.1) over (2.4.2-1) ...

Re-enabled locking and now nano doesn't segfault (in default config) on the target machine

Tag updated :)

Thankyou!

This bug was fixed in the package nano - 2.4.2-1ubuntu0.1

---------------
nano (2.4.2-1ubuntu0.1) wily; urgency=medium

  * d/p/trim-long-hostname.patch:
    - Cherry pick upstream fix for a hostname that is longer than expected,
      fixing crash (LP: #1509081).

 -- Marc Deslauriers <email address hidden> Tue, 08 Dec 2015 10:10:10 -0500

The verification of the Stable Release Update for nano has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.