bugGNU nano - Bugs: bug #44907, opening a file that waits for...

 
 

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

bug #44907: opening a file that waits for input hangs

Submitted by:  Sworddragon <sworddragon>
Submitted on:  Thu 23 Apr 2015 01:48:08 PM UTC  
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Closed

( Jump to the original submission)

Wed 19 Jun 2019 06:26:33 AM UTC, comment #19: 

Released in nano-4.3.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Tue 28 May 2019 11:43:34 AM UTC, comment #18: 

I hadn't tested it, but commenting out the sigaction() that installs the new handler does not seem to adversely affect the second sigaction() -- afterward a ^C still shows the cursor position.

An unpleasant effect of a failing first sigaction() is that ^C during the reading of a large file aborts nano, returning to the prompt without any message and without a visible cursor.  :|

But really, sigaction() cannot fail because we provide it with a valid signal and valid memory locations.  According to POSIX it cannot fail on anything else.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Mon 27 May 2019 06:13:45 AM UTC, comment #17: 

Hi Benno,

Have you tested the case where the call to "sigaction(SIGINT, &newaction, &oldaction);" fails? What would happen when you try to restore the old handler using "sigaction(SIGINT, &oldaction, NULL);"?

Other than that the patch looks good to me.

Martin van Zijl <martinvanzijl>
Sun 26 May 2019 12:22:07 PM UTC, comment #16: 

Fixed in git, commit ea117095.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 24 May 2019 05:58:18 PM UTC, comment #15: 

Hi Martin,

Attached is a condensed version of your patch, updated for the current state of git.  What do you think?  Okay to apply?

(file #46968)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Mon 26 Feb 2018 09:35:58 PM UTC, comment #14: 

I debugged it and found when reading /proc/ksmg, the ^C causes this loop in "read_file" to exit:

while ((input_int = getc(f)) != EOF) {

i.e. getc(f) returns an EOF. But this doesn't happen when reading huge (normal) files.

I modified the patch to stop the reading of a huge file as well, in case you're interested (attached v3).

(file #43402)

Martin van Zijl <martinvanzijl>
Wed 21 Feb 2018 11:36:25 AM UTC, comment #13: 

Thanks.  That patch works.  But... I'm surprised that ^C doesn't stop the reading when nano is reading in a huge file.  How does that work?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Mon 19 Feb 2018 09:50:24 PM UTC, comment #12: 

I used an old git version. I just tried with the latest git and made some updates. It seems to be working now (updated version attached).

(file #43365)

Martin van Zijl <martinvanzijl>
Fri 16 Feb 2018 11:27:22 AM UTC, comment #11: 

I run Xubuntu 17.10.  But I applied your patch against nano git, whereas you made the patch against a specific version.  What version of nano did you patch?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Thu 15 Feb 2018 08:18:53 PM UTC, comment #10: 

Thanks, that makes sense.

With the patch applied, the normal ^C still works for me on Ubuntu. What O/S did you test it on?

Martin van Zijl <martinvanzijl>
Tue 13 Feb 2018 07:00:47 PM UTC, comment #9: 

Thanks for the patch.  (I've updated it for current git, where the whitespace has changed.  See attached.)

However, with the patch applied, the normal ^C (Cursor position, or Cancel) does not work anymore.  The patch will have to restore the handler that was set before the reading started.

(I'm probably not going to apply the patch, as I think it is too small an issue to bother about.  If it were a two-line fix, okay, but a thirty-line patch...)

(file #43275)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 11 Feb 2018 11:08:53 PM UTC, comment #8: 

I've attached a patch which works for me (on Ubuntu 14.04).

Now if I do

    ./src/nano /proc/kmsg

then ^C cancels the reading and goes into normal editing mode.

(file #43256)

Martin van Zijl <martinvanzijl>
Sat 02 Jul 2016 04:41:03 PM UTC, comment #7: 

Emacs one can stop by typing first ^G and then ^X^C.  Experienced emacs users will know this, but for me... brrr.  Gedit is even nicer: it will start up and then show an empty tab with a turning busy indicator.  One can simply close the tab with ^W or quit with ^Q.

On the other hand, Geany and joe and dex will just hang on the command line -- which is a very weak indication of being busy reading the file, but it's better than mped who will startup and then hang in a blank window.

Meanwhile, nano has gotten a little better: when not using file locking, it will display "[ Reading File ]" when opening an endless file (a file without an EOF).  So at least you know nano has started and is trying to read in stuff.

What we probably should do is: if a thousand reads (or a whole second of reads) have produced zero bytes, look at the keyboard for a ^C.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 26 Apr 2015 01:08:56 PM UTC, comment #6: 

Correction: what I meant, of course, was: 'nano /proc/kmsg'.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 25 Apr 2015 05:52:53 PM UTC, comment #5: 

Okay, yes, 'nano /proc/kmesg' hangs.  But so does opening that file with 'vim' or 'emacs -nw'.  Vim is somewhat better, because it initializes part of the screen, so you kind of know it is stuck on the file listed on the bottom line.  Emacs is totally frustrating -- it seems to have initialized, but doesn't react to any keyboard input.

Pico is nice: it initializes the screen and then hangs saying "[Reading File]".  Very nice.  It is completely clear what is happening.  Nano should do something like that.  And then... it would be nice if it allowed the reading to be cancelled with ^C.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 24 Apr 2015 07:07:46 PM UTC, comment #4: 

> I don't have scite. Please give me a simpler recipe.


Opening /proc/kmsg with nano as root causes this behavior on my system too.

> And that file, by the way, doesn't look like something you should want to be editing.


Yes, but this can happen by accident. Normally I would either expect that nano refuses to open such files (or opens an empty file) or that the main controls would not hang (for example by using an extra thread on handling documents) so that nano can be still closed without terminating it.

> But if you do, do other editors, like vim or emacs or gedit, have no problems?


I have tested several applications on my system that can open files (not only text editors) and the most of them are handling this fine (either by not opening the file/giving an error message or by reading/waiting for it in a non-blocking way so that the application does not hang).

Sworddragon <sworddragon>
Fri 24 Apr 2015 07:28:48 AM UTC, comment #3: 

I don't have scite.  Please give me a simpler recipe.

And that file, by the way, doesn't look like something you should want to be editing.  But if you do, do other editors, like vim or emacs or gedit, have no problems?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Thu 23 Apr 2015 10:20:58 PM UTC, comment #2: 

I have tested this with the file /tmp/SciTE._pid_.in that the text editor SciTE creates while it is running.

Sworddragon <sworddragon>
Thu 23 Apr 2015 06:40:03 PM UTC, comment #1: 

Cannot reproduce.  I've tried with 'cat - >waiting', typing something, and then running 'nano waiting' in another terminal.  It opens fine, and closes fine.

Can you give a simple, reproducing recipe?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Thu 23 Apr 2015 01:48:08 PM UTC, original submission:  

I'm using nano 2.2.6 and if I'm opening a file that waits for input nano hangs. In this state it is also not possible to close nano anymore without terminating it.

Sworddragon <sworddragon>

 

Attached Files
file #43256:  fix-for-issue-44907.patch added by martinvanzijl (2KiB - text/x-patch - Proposed patch.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-06-19 bens Open/ClosedOpen => Closed
    2019-05-26 bens StatusIn Progress => Fixed
    2019-05-24 bens Attached File- => Added control-C-aborts-reading.patch, #46968
        StatusNone => In Progress
        Assigned toNone => bens
    2018-02-26 martinvanzijl Attached File- => Added allow-to-interrupt-reading-v3-huge-files-also.patch, #43402
    2018-02-19 martinvanzijl Attached File- => Added allow-to-interrupt-reading-v2.patch, #43365
    2018-02-16 bens Severity3 - Normal => 2 - Minor
    2018-02-13 bens Attached File- => Added allow-to-interrupt-reading.patch, #43275
    2018-02-11 martinvanzijl Attached File- => Added fix-for-issue-44907.patch, #43256
    2015-04-25 bens SummaryOpening a file that waits for input does hang => opening a file that waits for input hangs

    Back to the top


    Powered by Savane 3.5