bugGNU nano - Bugs: bug #60902, "Out of curses" message...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #60902: "Out of curses" message when killing multiple nanos

Submitter:  Julian Rosen <jules183>
Submitted:  Sat 10 Jul 2021 03:52:04 AM UTC
   
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Thu 07 Oct 2021 07:31:37 AM UTC, comment #10: 

The fixes were released in nano-5.9.  Thanks for reporting.

Benno Schulenberg <bens>
Group administrator
Wed 14 Jul 2021 08:47:21 AM UTC, comment #9: 

The problem of trying to write to the same file is addressed in git, commit e3ef7787, by including nano's PID in the name of the dump file when the buffer is nameless: nano.<pid>.save.

Benno Schulenberg <bens>
Group administrator
Tue 13 Jul 2021 07:29:15 AM UTC, comment #8: 

Thanks for figuring it out and for explaining.  Indeed, I kept overlooking that when during write_file() an error occurs ("File exists"), that then the call of statusline() causes a second call of die() ("Out of curses"), which means that get_next_filename() gets called again and now finds a filename that does not conflict, and so the second write_file() succeeds.

In current git, the die("Out of curses") no longer exists, so of two or more nanos with a nameless buffer getting killed at the same time only one would succeed in dumping its buffer.  That's not good (even when it's an unlikely scenario).  Waiting a random number of milliseconds isn't a watertight solution, and would unnecessarily slow things down.  Better would be to include the PID of each nano in the filename: nano#PID.save.x, where PID gets replaced with the actual process ID, and .x is the normal serial suffix in case such a file already exists.

Benno Schulenberg <bens>
Group administrator
Mon 12 Jul 2021 05:28:33 PM UTC, comment #7: 

I don't fully understand what's happening, but here's my partial understanding.

After getting the signal from killall, the die function calls emergency_save, which get an unused filename with get_next_filename then tries to write the buffer with write_file. If that file gets written by a different instance of nano between the get_next_filename and write_file calls, then write_file encounters a write error and attempts to show the error using statusline. statusline checks isendwin(), which seems to return true here, so statusline calls die("Out of curses"). This displays the "Out of curses..." message, and die invokes emergency_save a second time. The second pass of emergency_save finds a new filename, and writes the buffer to that.

With the patch, the message gets displayed with fprintf instead of a call to die, so emergency_save doesn't get called a second time.

Julian Rosen <jules183>
Mon 12 Jul 2021 03:41:03 PM UTC, comment #6: 

Nevermind.  On the machine with the spinning disk I can now consistently reproduce your original report, with nano-5.4 and without the patch: both nanos say they received a SIGHUP or SIGTERM, one says "Out of curses", and both successfully save the buffer to different dump files.  It perplexes me: where does the "Out of curses" come from?

Even stranger: for the first few runs without the patch, the nano that said "Out of curses" did not report the "SIGHUP or SIGTERM".  This ought not be possible.

And when I apply the patch, one of the nanos always says "File exists" and then reports not having saved the buffer.  As expected.

On my regular laptop, only after the eleventh, twelfth, and thirteenth try did I get nano to report "Out of curses" (and both buffers getting saved, like always).  Again on the twentieth try, and again several times around the thirtieth try...  It is erratic, it seems to depend on the state of some random piece of memory...

Benno Schulenberg <bens>
Group administrator
Mon 12 Jul 2021 08:08:32 AM UTC, comment #5: 

Hm!  If you undo the patch (with -R), recompile, and then try the recipe with src/nano again, do you then see the "Out of curses" message and the "File exists" message?  Or do you see just one "Out of curses" message and both buffers are written?  I wonder, because I don't see how the latter could be possible: if there is an "Out of curses" message, then there was some error; if there is some error, then write_file() returns FALSE, and "buffer not written" plus the error message will be reported.

Benno Schulenberg <bens>
Group administrator
Sun 11 Jul 2021 05:12:22 PM UTC, comment #4: 

Repeating the experiment with the version built using your patch: one instance of nano writes its buffer, but the other says
    Received SIGHUP or SIGTERM
    Error writing nano.save: File exists

    Buffer not written to nano.save: File exists

I repeated the trial many times, sometimes with system load and sometimes without. The result was the same almost every time, but maybe 5% of the time it happened that both buffers were written to disk (with no error messages).

Julian Rosen <jules183>
Sun 11 Jul 2021 08:15:50 AM UTC, comment #3: 

Hm, okay.  Both nanos successfully dump the buffer, but one of them additionally says "Out of curses".  Then I am really curious what that message is that would have been shown on the status bar.  Can you build nano from source?  If yes, then please download the 5.4 tarball [1] and apply the attached patch (with -p1), configure and compile, and then run your recipe while using src/nano.

[1] https://ftpmirror.gnu.org/gnu/nano/nano-5.4.tar.xz

With the patch applied, only on the tenth try did I get an error message: "Error writing nano.save.20: File exists" (after making sure my machine was under some load by running 'grep -r paspas /' in a fourth terminal).

(file #51660)

Benno Schulenberg <bens>
Group administrator
Sat 10 Jul 2021 04:19:01 PM UTC, comment #2: 

I do not see a "File exists" message from either nano. Both nanos say "Buffer written...", and afterwards nano.save and nano.save.1 both exist with the correct text. So apart from the out of curses message, everything seems to be working as expected.

Regarding the drive speed, my computer has an NVMe SSD.

Julian Rosen <jules183>
Sat 10 Jul 2021 09:01:52 AM UTC, comment #1: 

Thanks for reporting, Julian.

On my day-to-day laptop (which has an eMMC "disk"), I cannot reproduce this.  On an older laptop (with a real, spinning disk), I can reproduce it, with nano 4.8 (on Ubuntu 20.04) and 5.4 and 5.8.  However, every time that I see the "Out of curses" message, nano then says: "Buffer not written to ...: File exists".

Apparently, when the machine has a slower disk, there is a race condition: both nanos (that received the kill signal) determine which is the next non-existent .save file, both reach the same conclusion, and then both try to open that same file exclusively.  The nano that tries first will succeed, and the nano that comes second will fail.  Can you confirm that you actually see "File exists" for one of the killed nanos?

I can also reproduce that with 'killall --verbose nano' the "Out of curses" does not appear.  Apparently the --verbose slows down the sending of the kill signal to the second nano enough for the first nano to open the .save file before the second nano determines which is the next available free one.

In current git this "Out of curses" message will no longer occur, as the message was removed in commit fc01c5a1  (https://git.savannah.gnu.org/cgit/nano.git/commit/?id=fc01c5a1).  So the symptom you are reporting will no longer appear.

But the problem of both nanos finding the same number for the next available .save file is still there.  Maybe each nano should be made to wait a random number of milliseconds when it dies, to reduce the chances of such a "collision"?

Benno Schulenberg <bens>
Group administrator
Sat 10 Jul 2021 03:52:04 AM UTC, original submission:  

Running Nano 5.4 under Ubuntu 21.04. In certain cases nano returns the message "Out of curses -- please report a bug". To get this error, I open three terminal windows. In the first two, I navigate to the same directory, open nano (blank new document), and type some text. Then in the third terminal, I run +killall nano+. Both nano instances die. The first instance gives a message
    Received SIGHUP or SIGTERM

    Buffer written to nano.save
The second instance gives a message
    Received SIGHUP or SIGTERM
    Out of curses -- please report a bug

    Buffer written to nano.save.1
Curiously, if I kill the processes using +killall --verbose nano+, the error does not happen.

I could not reproduce this error on Raspberry Pi OS.

Julian Rosen <jules183>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by jules183 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-10-07 bens Open/ClosedOpen Closed
    2021-07-14 bens StatusNone Fixed
    2021-07-11 bens Attached File- Added 0001-feedback-print-the-message-on-standard-error-when-th.patch, #51660
    2021-07-10 bens Severity3 - Normal 2 - Minor
        Assigned toNone bens
        SummaryOut of curses "Out of curses" message when killing multiple nanos

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code