bugGNU Octave - Bugs: bug #55029, pause() with no arguments does not...

 
 

bug #55029: pause() with no arguments does not return like kbhit() with glibc 2.28

Submitter:  Michael Godfrey <godfrey>
Submitted:  Thu 15 Nov 2018 01:48:54 PM UTC
   
 
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Godfrey Open/Closed:  * Closed
Release:  * 5.1.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 23 Jul 2020 03:17:06 PM UTC, comment #70: 

So, actually I was using this behavior as a way to interact with octave-cli via stdin/out. That is, I wrote a vscode debugger for octave which communicates with the octave-cli process through stdin/out. Since the user sends keyboard events to vscode, these are translated to stdin sequences.

I just confirmed on windows that version 5.2.0 when using pause requires an keypress received directly by the octave-cli process to continue execution, while version 5.1.0 can be unlocked via stdin.

Maybe we can find a halfway where we can set octave to one of two modes. stdio mode (previous behavior) or a interactive mode (current behavior). That way I could select the mode via some bool, and everyone is happy. How does that sound?

hackdev
Mon 08 Apr 2019 02:37:23 AM UTC, comment #69: 

Thank you maintainer very much.

Anonymous
Sun 07 Apr 2019 03:29:37 AM UTC, comment #68: 

Correct, this bug is fixed on the Octave stable branch after 5.1.0 was already tagged, it will be part of version 5.2.0.

Mike Miller <mtmiller>
Group Member
Sun 07 Apr 2019 02:39:17 AM UTC, comment #67: 

Dear maintainers,

This bug still exists in Octave 5.1.0, with glibc 2.28.
Is the changeset in comment #64 on version 5.1.0, or on the incoming 5.2.0?
Should I open a new bug report, or just discuss in this bug report?

We run either "octave" or "octave --gui". At the beginning, the "kbhit()" works well.
However, once we run "kbhit(1)" or "pause()", then all of "kbhit(1)", "kbhit()", "pause()" would no longer work:
now, 1) both "kbhit(1)" and "kbhit()" always return immediately with [].
and, 2) "pause()" does not return even after we press many keys (unless we press Ctrl-C).

My environment is Debian GNU/Linux testing (buster), LXDE desktop,
with Octave packages (octave, octave-common, liboctave7, etc) 5.1.0-1 from Debian experimental.

octave:1>  ver
----------------------------------------------------------------------
GNU Octave Version: 5.1.0 (hg id: d05d6eebde10)
GNU Octave License: GNU General Public License
Operating System: Linux 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64
----------------------------------------------------------------------

$  /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Debian GLIBC 2.28-8) stable release version 2.28.
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 8.3.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

$  dpkg -l|grep octave
ii  liboctave7:amd64                       5.1.0-1                      amd64
ii  octave                                 5.1.0-1                      amd64
ii  octave-common                          5.1.0-1                      all
ii  octave-doc                             5.1.0-1                      all

Anonymous
Wed 03 Apr 2019 05:06:40 PM UTC, comment #66: 

@Pantxo do you want another bug report for the remaining raw mode improvement, or will you keep track of that yourself?

Mike Miller <mtmiller>
Group Member
Tue 02 Apr 2019 10:27:35 PM UTC, comment #65: 

Works for me on default, but without added item from #63

Thanks!

Michael Godfrey <godfrey>
Group Member
Tue 02 Apr 2019 09:03:21 PM UTC, comment #64: 

This is finally fixed on the stable branch now

https://hg.savannah.gnu.org/hgweb/octave/rev/c3716220d5b9

Mike Miller <mtmiller>
Group Member
Fri 29 Mar 2019 08:09:24 AM UTC, comment #63: 

Very good news Mike! Please push this to stable. I'll try and prepare a patch for default in order to fix the echoing of characters (using a timeout for the read so that most of the time is spent in raw mode).

Pantxo Diribarne <pantxo>
Group Member
Fri 29 Mar 2019 12:32:19 AM UTC, comment #62: 

This patch also works for me, and maybe is a bit clearer since it groups the 'std::cin' along with the 'clearerr (stdin)':


--- a/libinterp/corefcn/sysdep.cc
+++ b/libinterp/corefcn/sysdep.cc
@@ -617,7 +617,10 @@ namespace octave
     int c = std::cin.get ();

     if (std::cin.fail () || std::cin.eof ())
-      std::cin.clear ();
+      {
+        std::cin.clear ();
+        clearerr (stdin);
+      }

     // Restore it, enabling system call restarts (if possible).
     octave::set_interrupt_handler (saved_interrupt_handler, true);


Mike Miller <mtmiller>
Group Member
Fri 29 Mar 2019 12:11:23 AM UTC, comment #61: 

I have glibc 2.27, but for reference, I tried the patch and it doesn't cause any problems for me.  So no regressions, and maybe it fixes things for 2.28 users.

Rik <rik5>
Group administrator
Thu 28 Mar 2019 11:51:08 PM UTC, comment #60: 

@Pantxo The following quick and dirty patch fixes this issue completely for me.


--- a/libinterp/corefcn/sysdep.cc
+++ b/libinterp/corefcn/sysdep.cc
@@ -466,6 +466,7 @@ namespace octave
         }

       tcsetattr (tty_fd, wait ? TCSAFLUSH : TCSADRAIN, &s);
+      clearerr (stdin);
     }
 #elif defined (HAVE_TERMIO_H)
     {


I haven't tried putting it at different places in the process, or trying to see exactly where the EOF condition is triggered, but this particular call to 'clearerr' in the 'raw_mode' helper function fixes all problems for me.

Is this safe? Can we start from here and make something safer if needed?

Mike Miller <mtmiller>
Group Member
Thu 28 Mar 2019 10:58:38 PM UTC, comment #59: 

No, not a segfault, an EOF, as if I had typed Ctrl+D at the prompt and Octave exits cleanly because it's done with stdin. If I enable '__lexer_debug_flag__', I can see that the lexer receives EOF as soon as 'kbhit(1)' is executed. Again, this is only with --no-line-editing. Without that option, 'kbhit(1)' just returns immediately and breaks normal 'kbhit()' as explained earlier, probably because the EOF was seen on raw stdin by the first 'kbhit(1)'.

This still looks to me to be related to the glibc 2.28 change that I quoted back in comment #45, that once an EOF condition is seen on stdin, it persists until the application explicitly clears the condition. When we read from readline, this does not occur, possibly because readline is handling this correctly and insulating Octave from this low-level behavior. But when kbhit tries to read raw stdin, this bug is triggered.

It's helpful to know that this bug doesn't really have anything to do with 'pause' or with the interaction between 'pause' and processing graphics events, but rather it's completely due to a problem with the non-blocking 'kbhit(1)' implementation and the behavior of file streams in glibc 2.28.

Mike Miller <mtmiller>
Group Member
Thu 28 Mar 2019 10:44:09 PM UTC, comment #58: 

@Mike: "running octave --no-line-editing and calling 'kbhit(1)' causes Octave to exit immediately".  You mean, it segfaults?  Ugh.


Rik <rik5>
Group administrator
Thu 28 Mar 2019 10:26:43 PM UTC, comment #57: 

Thanks for taking the effort to bring up a system to test this! You have already helped narrow this down even further, I had forgotten about the difference between the blocking 'kbhit ()' and the non-blocking 'kbhit (1)'. So I can confirm that 'kbhit (1)' causes 'kbhit ()' to stop waiting for input. But the first one does return a character if input is already waiting on stdin. I can reproduce this in earlier versions of Octave.

Also, running octave --no-line-editing and calling 'kbhit(1)' causes Octave to exit immediately.

Mike Miller <mtmiller>
Group Member
Thu 28 Mar 2019 09:48:22 PM UTC, comment #56: 

I have setup a virtual box with Fedora 29 (this took me hours) and couldn't find anything to make kbhit work as expected (this took me hours also :-)).

As Mike has shown, "kbhit (0)" works once and then returns immediately afterwards. The first times, std::cin.get() manages to retrieve a charater but std::cin's error flags (fail and eof) are set. Even after clearing those flags and doing a seekg(0), we can never get the terminal to returns into actual raw_mode and std::cin.get() always returns -1.

This is strange: why should the failbit be set when the read succeeded?

Also when using a timeout (VTIME > 0 and VMIN = 0) the observed behavior with glibc 2.28 does not match termios doc:

>> ... read(2) returns either when at least one byte of data is available, or when the timer expires. [1]


I setup a 2s timeout (using the patch from comment #49) and saw that the first call to "pause ()", when it seemingly works, does not exactly do that: std::cin.get() returns the character after the timeout, even though the character has been typed well before.

I am lost.

[1] http://man7.org/linux/man-pages/man3/termios.3.html

Pantxo Diribarne <pantxo>
Group Member
Mon 21 Jan 2019 10:55:26 PM UTC, comment #55: 

No, this patch still doesn't work. The 'pause' call still does not return with any number of chars.

It is not always the first character that is not echoed, any character may be randomly echoed or hidden.

Mike Miller <mtmiller>
Group Member
Mon 21 Jan 2019 02:01:09 PM UTC, comment #54: 

And sorry for not having the courage to setup a system with glibc2.29 myself.

Pantxo Diribarne <pantxo>
Group Member
Mon 21 Jan 2019 12:46:12 AM UTC, comment #53: 

 @Mike: The fact that the first character is not echoed is due to the "raw mode" configuration with non null VTIME. The idea is to have kbhit return either when a character has been typed or when a timeout is reached. The first character is actually read but not returned by cin.get... I attached an updated patch as per your suggestion.

(file #46053)

Pantxo Diribarne <pantxo>
Group Member
Sun 20 Jan 2019 11:20:15 PM UTC, comment #52: 

Michael - like I said earlier (comment #44), I now have glibc 2.28. I was unable to reproduce back in November when Debian still used glibc 2.27.

Pantxo - I don't know for sure, but I think calling std::cin.clear may only affect the error flags at the C++ streams level, not at the C FILE streams level?

Maybe something like 'std::cin.seekg (0, std::ios::cur)' would work, since that is documented to call 'fseek' on the underlying C stream, which should also clear the C-level state of the stdin stream.

Mike Miller <mtmiller>
Group Member
Sun 20 Jan 2019 10:15:41 PM UTC, comment #51: 

@Mike,

What glibc do you have?

Michael Godfrey <godfrey>
Group Member
Sun 20 Jan 2019 07:28:16 PM UTC, comment #50: 

No, this patch only makes things worse on my system.

On stable (ada14ef3067f), I still have the original behavior described here.

With this patch applied, pause now seems to swallow characters randomly and still does not return on the first or any key press, only on Ctrl+C.

If I run 'pause' with no args and then enter 'asdf' followed by Ctrl+C, first without the patch:


>> pause
asdf^C
>> kbhit
ans =
>>


And with the patch applied:


>> pause
sd
>> kbhit
ans =


It now sometimes requires 2 or more Ctrl+C to break out of pause, the first one is sometimes discarded/ignored.

Mike Miller <mtmiller>
Group Member
Sat 19 Jan 2019 11:06:04 PM UTC, comment #49: 

Does the attached patch, that clears error flags in std::cin prior to trying reading, improve anything?

(file #46029)

Pantxo Diribarne <pantxo>
Group Member
Fri 18 Jan 2019 05:16:45 PM UTC, comment #48: 

As mentioned below in #46 this appears to be due to an incompatibility
between glibc 2.27 and 2.28.

Thus a fix is required for glibc 2.28 (and presumably above)
in order to clear the entry in

https://wiki.octave.org/wiki/index_php?title=Bug_Fix_List_-_5.0_Release

Bugs marked as regressions

Since glibc 2.28 is the current release on Fedora 29
this bug should be resolved before the Octave 5.0 release.

Michael Godfrey <godfrey>
Group Member
Thu 10 Jan 2019 03:24:52 AM UTC, comment #47: 

Another observation, the kbtest.m script works repeatedly as long as the character is entered during the pause. But if kbhit(0) is called ever without anything in the stdin input buffer, all subsequent calls to kbhit return nothing. So this agrees with what I observed with the debugger, that pause is stuck in the loop where it calls octave::kbhit, and the return value continues to be -1, it never sees any more input on stdin. So this may have something to do with the glibc change mentioned in the release notes, that an error state at some layer needs to be reset by the application.

Mike Miller <mtmiller>
Group Member
Thu 10 Jan 2019 03:03:20 AM UTC, comment #46: 

I just built the stable branch (rev 67724e9f6661) on Debian testing and in a Flatpak build environment on the same system, with all optional dependencies disabled in the build.

Running on the Debian testing host, with glibc 2.28, pause with no arguments hangs indefinitely as reported in this bug. Ctrl+C in pause returns and then kbhit returns an empty string indefinitely after that.

Running in the Flatpak container environment, with glibc 2.27, pause with no arguments returns immediately on a key press, the expected behavior.

Mike Miller <mtmiller>
Group Member
Thu 10 Jan 2019 12:24:26 AM UTC, comment #45: 

Has anyone else with Debian testing or with Ubuntu 18.10 (both with glibc 2.28) tried this yet?

Just glancing at the glibc 2.28 NEWS, I have no idea if this is related, but:


* All stdio functions now treat end-of-file as a sticky condition.  If you
  read from a file until EOF, and then the file is enlarged by another
  process, you must call clearerr or another function with the same effect
  (e.g. fseek, rewind) before you can read the additional data.  This
  corrects a longstanding C99 conformance bug.  It is most likely to affect
  programs that use stdio to read interactive input from a terminal.
  (Bug #1190.)


maybe?

Fedora 28 has glibc 2.27 and Fedora 29 (released October 2018) has glibc 2.28.

Mike Miller <mtmiller>
Group Member
Wed 09 Jan 2019 11:33:53 PM UTC, comment #44: 

I can now reproduce this issue on Debian with Octave 5.0.1. This may correspond to the recent glibc transition from 2.27 to 2.28, because I was previously unable to reproduce this back in November, when Debian testing still had glibc 2.27.

With Pantxo's kbtest script, the character that was typed is returned correctly. But after calling pause once and Ctrl+C to break out of it, kbtest says "Caught ''".

Mike Miller <mtmiller>
Group Member
Wed 09 Jan 2019 11:42:38 AM UTC, comment #43: 

@Michael, Dmitri: My intent was to show that what you are seeing is a regression in Fedora, not in Octave, since the kbhit function (on which "pause" now relies) did not change in between and still works in Debian.
From your comments, I see that you did not run the snippet from comment #37 as a script and this may be corrupting the results. Could you please run the attached script in both versions of Fedora and report back?

What I observe in Debian stretch is that the character I type (e.g. "a" in the example bellow) is echoed and then caught by kbhit.


octave:6> kbtest
Type a character and wait until the function returns
a
Caught 'a'
octave:7>



(file #45912)

Pantxo Diribarne <pantxo>
Group Member
Fri 23 Nov 2018 04:39:16 PM UTC, comment #42: 

On Fedora 28 it is kind of hit-and-miss:


octave:11> disp ("Type a character")
Type a character
octave:12> pause (5)
aoctave:13> c = kbhit (0)
c = a
octave:14> disp ("Type a character")
Type a character
octave:15> pause (5)
aoctave:16> c = kbhit (0)
c =
octave:17> disp ("Type a character")
Type a character
octave:18> pause (5)
aoctave:19> c = kbhit (0)
c = a
octave:20> disp ("Type a character")
Type a character
octave:21> pause (5)
aoctave:22> c = kbhit (0)
c =


Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Fri 23 Nov 2018 04:03:45 PM UTC, comment #41: 

All my tests are on fc29. That is all I have right now.

Michael Godfrey <godfrey>
Group Member
Fri 23 Nov 2018 04:02:05 PM UTC, comment #40: 

I think that what I got is consistent with Dmitri:

I also tried:
octave:19> disp ("Type a character")
Type a character
octave:20> pause (15)
c=kbhit(0)
a
octave:21> c=kbhit(0)
c =

==================
I extended the time to 15sec so that I could enter
c=kbhit(0)
a
before time ran out.

Michael Godfrey <godfrey>
Group Member
Fri 23 Nov 2018 03:35:43 PM UTC, comment #39: 

Or if I wait to type c = kbhit (0) until octave's prompt returns:



octave:5> disp ("Type a character")
Type a character
octave:6> pause (5)
aoctave:7> a
error: 'a' undefined near line 1 column 1
octave:7> c = kbhit (0)
c =
octave:8>


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 23 Nov 2018 03:29:32 PM UTC, comment #38: 

This is what I get with the current dev:


octave:3> disp ("Type a character")
Type a character
octave:4> pause (5)
aoctave:5> c = kbhit (0)a
parse error:

  syntax error

>>> c = kbhit (0)a
                 ^


(On Fedora 29)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 23 Nov 2018 02:21:35 PM UTC, comment #37: 

@Michael: could you run the following snippet (as a script or including the last newline) in F28 and F29. You will be prompted to type a character and you'll have 5 seconds to do so.


disp ("Type a character")
pause (5)
c = kbhit (0)


For me kbhit always returns the character I have typed.


octave:5> disp ("Type a character")
Type a character
octave:6> pause (5)
aoctave:7> c = kbhit (0)
c = a
octave:8>


Pantxo Diribarne <pantxo>
Group Member
Thu 22 Nov 2018 10:29:13 PM UTC, comment #36: 

John,

Since you are the author of sysdep.cc which containd
kbhit (), do you have an idea of why it is broken in
Fedora 29?

Michael Godfrey <godfrey>
Group Member
Sat 17 Nov 2018 07:30:26 PM UTC, comment #35: 

Right. pause breaks kbhit.
But only, it appears, on FC29!

Michael Godfrey <godfrey>
Group Member
Fri 16 Nov 2018 09:09:18 PM UTC, comment #34: 

I also observe the following on Fedora 29. When Octave starts, the 'kbhit' function behaves correctly. However, after calling 'pause' with no arguments, and breaking out of it with Ctrl+C, the 'kbhit' function now returns an empty string immediately for the remainder of the Octave session. This agrees with the change that Dmitri bisected to, which uses 'octave::kbhit' inside of an infinite loop. The 'octave::kbhit' function continues to return -1 inside that loop, no matter how many keys are pressed, so the loop is never broken until the user issues an interrupt.

Mike Miller <mtmiller>
Group Member
Fri 16 Nov 2018 08:51:24 PM UTC, comment #33: 

I booted a Fedora 28 VM, compiled the default version of Octave, then upgraded the VM to Fedora 29 and ran the same compiled Octave without rebuilding anything. I can confirm that the pause function returns immediately on a key press on Fedora 28, but the upgrade to Fedora 29 breaks it. The character corresponding to the key pressed is shown in both cases, that doesn't seem to be related to the pause function not returning at all.

Mike Miller <mtmiller>
Group Member
Fri 16 Nov 2018 08:39:07 PM UTC, comment #32: 

https://hg.savannah.gnu.org/hgweb/octave/rev/f7b205562f1d

Looks like the bad revision.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 07:58:39 PM UTC, comment #31: 

So far I braketed the problem between
HG ID  "553278e5aac7" (good)
and
HG ID "f881d3e271d2" (bad)

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 07:14:45 PM UTC, comment #30: 

I can also confirm that hg id 1c6dd836bca9
(pre 511295347a27) still has a problem on my (Fedora 29) computer.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 06:17:22 PM UTC, comment #29: 

Thanks, so this does affect the default branch only, but is only reproducible on Fedora 29.

Mike Miller <mtmiller>
Group Member
Fri 16 Nov 2018 06:14:43 PM UTC, comment #28: 

To clarify my statement:
I still have a coputer with Fedora 28 on it. i just built
a current dev tip and it does not show the problem.

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 06:10:37 PM UTC, comment #27: 

Dimitri said:
BTW -- I tried on Fedora 28 computer and I do not see this bug there. I doubt
Fedora changed terminal interface between those
two versions.

Dmitri.

The problem could have been present in FC28. I only needed
pause in my code when I found that plots executed from
a file were causing seg fault and needed pause to prevent
this  (this is an old problem solved quite a long time ago
but reintroduced recently (bug #55028)).

Michael Godfrey <godfrey>
Group Member
Fri 16 Nov 2018 05:49:03 PM UTC, comment #26: 

No -- by mistake i was applying to stable branch that is why the patch was rejected. When i applied to dev, instead of fix I got even worse behaviour.

BTW -- I tried on Fedora 28 computer and I do not see this bug there. I doubt Fedora changed terminal interface between those
two versions.

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 05:44:05 PM UTC, comment #25: 

Dmitri - are you implying that this bug affects the stable branch for you as well? Does it affect the 4.4.1 tagged release also? If so, is it possible this is a bug in a Fedora library since the latest distro update to F29 and not a bug in Octave?

Mike Miller <mtmiller>
Group Member
Fri 16 Nov 2018 05:40:48 PM UTC, comment #24: 

hg update -r 511295347a27^  did not fix the problem.
Sorry.

Michael Godfrey <godfrey>
Group Member
Fri 16 Nov 2018 05:31:10 PM UTC, comment #23: 

Sorry -- I was applying the patch to stable...
It applied fine to dev, but behaviour got even worse,
now the typed chars only show up on the second try (i.e.
typing "x" after pause would not show up anything, typing
"x" again would show up "x" etc... Ctrl-C returns to
octave prompt).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 05:10:45 PM UTC, comment #22: 

I attached an updated version of the patch, with a log and an implementation for Windows also. As for sgtty terminal interface, the "raw_mode" function was already incomplete and I don't expect modern platforms to not have termios or termio at least.

@Dmitri: That is strange, I can't imagine why a patch could be entirely rejected...

(file #45455)

Pantxo Diribarne <pantxo>
Group Member
Fri 16 Nov 2018 05:09:42 PM UTC, comment #21: 

Rik's suggestion is did not crash, but it backed out about 90
patches so it is taking a while to compile. And, this
will add to the problem of isolating the error.

More when compile completes.

Michael Godfrey <godfrey>
Group Member
Fri 16 Nov 2018 05:01:54 PM UTC, comment #20: 

Patch failed for me:

patch -p1 < ~/Downloads/pause_timeout.patch
patching file libinterp/corefcn/sysdep.cc
Hunk #1 FAILED at 358.
Hunk #2 FAILED at 405.
Hunk #3 FAILED at 448.
Hunk #4 FAILED at 540.
Hunk #5 FAILED at 549.
5 out of 5 hunks FAILED -- saving rejects to file libinterp/corefcn/sysdep.cc.rej
patching file libinterp/corefcn/sysdep.h
Hunk #1 FAILED at 40.
1 out of 1 hunk FAILED -- saving rejects to file libinterp/corefcn/sysdep.h.rej
patching file libinterp/corefcn/utils.cc
Hunk #1 FAILED at 1287.
1 out of 1 hunk FAILED -- saving rejects to file libinterp/corefcn/utils.cc.rej

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 04:38:52 PM UTC, comment #19: 

I attached a patch that fixes the echoed character for me, but it is incomplete: it won't work on BSD platforms which use sgtty terminal interface and for which I couldn't find a way to add a timeout to the raw mode.

(file #45453)

Pantxo Diribarne <pantxo>
Group Member
Fri 16 Nov 2018 04:31:30 PM UTC, comment #18: 

I assume you have a Mercurial clone of the development branch.  Try updating to the parent of the problem changeset.


hg update -r 511295347a27^


The '^' asks Mercurial for the parent of the named revision.

Once there, build as usual, run-octave, try pause() and see if it hangs.

--Rik

Rik <rik5>
Group administrator
Fri 16 Nov 2018 04:19:51 PM UTC, comment #17: 

@Pantxo Can this be tested by just backing out cset 511295347a27?
Any other changes neeeded? If not please tell where to find the cset and how to do the backout. I have done this before, but
not recently.

Thanks, Michael

Michael Godfrey <godfrey>
Group Member
Fri 16 Nov 2018 08:12:59 AM UTC, comment #16: 

I'd bet the bisection is not necessary, I'm 99% sure it's due to cset 511295347a27. As for the system dependent behavior, we use a "raw_mode" function to capture keyboard entries and the implementation depends on the kind of terminal interface in use (termio, termios or stty).
If someone can confirm that cset 511295347a27 is at fault, I'll try to rework this.

Pantxo Diribarne <pantxo>
Group Member
Fri 16 Nov 2018 12:45:46 AM UTC, comment #15: 

Like Mike, I'm also using readline 7.0 and it works for me.  I'm running Kubuntu 18.04 which is based off Debian, so relatively similar platforms.

Rik <rik5>
Group administrator
Fri 16 Nov 2018 12:24:30 AM UTC, comment #14: 

@Dimitri

I tried compared ./run-octave with ./run-octave -cli?

They behave the same.


Michael Godfrey <godfrey>
Group Member
Fri 16 Nov 2018 12:17:37 AM UTC, comment #13: 



./run-octave -cli -f -q
octave:1> pause
x
y
z
^C
octave:1>


I also noticed that now in my history I have (hitting arrow up):


octave:1> ��
parse error:

  invalid character '�' (ASCII 254)

>>> ��
    ^


Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Nov 2018 12:07:48 AM UTC, comment #12: 

I am not able to reproduce this on Debian with readline 7.0. I tested both with libreadline7 provided by Debian (currently at 7.0 patchlevel 3) and with my own self-built readline from git (currently at 7.0 patchlevel 5).

Are the only users affected by this on Fedora 29?

Has anyone affected by this compared ./run-octave with ./run-octave -cli?

Mike Miller <mtmiller>
Group Member
Thu 15 Nov 2018 11:27:51 PM UTC, comment #11: 

One item might help: Those who have some version of this
problem could report what their system is...

Michael Godfrey <godfrey>
Group Member
Thu 15 Nov 2018 11:26:09 PM UTC, comment #10: 

@Rik,

I get:
[godfrey@pbdsl4 ~]$ octave -f -q --no-line-editing
octave:1> pause
aaaa^C
octave:1>

As you said, I also get

>>without readline, octave quits on Ctrl-C (rather than returning to interpreter).

Michael Godfrey <godfrey>
Group Member
Thu 15 Nov 2018 11:03:08 PM UTC, comment #9: 

Okay, someone who has this problem will have to try bisection.

Rik <rik5>
Group administrator
Thu 15 Nov 2018 11:00:25 PM UTC, comment #8: 

without readline, octave quits on Ctrl-C (rather than returning to interpreter). Pause still ignores keybord input.

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Thu 15 Nov 2018 10:54:32 PM UTC, comment #7: 

@Michael: Maybe try disabling readline entirely?


run-octave -f -q --no-line-editing
pause


Otherwise, you might have to try using hg bisect to figure out where this was introduced.

Works fine for me though with current tip (32d4ee071348).  As soon as I type the first key ('x') Octave returns to the prompt.


~/wip/Projects_Mine/octave-dev: run-octave -fq
octave:1> pause
xoctave:2>



Rik <rik5>
Group administrator
Thu 15 Nov 2018 10:50:12 PM UTC, comment #6: 

Just to keep up-to-date, I am now testing with:
octave:1>  _octave_config_info_ ("hg_id")
ans = 8b6f1731474b

Michael Godfrey <godfrey>
Group Member
Thu 15 Nov 2018 10:42:08 PM UTC, comment #5: 

@Rik: about:
You might also want to move your .inputrc file to a new name in case Readline
is causing the issue.

I did check that. No .inputrc or .octaverc are in my
home dir. (Remember the trouble with that before...)

Michael Godfrey <godfrey>
Group Member
Thu 15 Nov 2018 10:37:02 PM UTC, comment #4: 

@Dimitri  That is exactly what I reported.

and:

>>@Michael: Maybe try starting with '-f' to avoid reading any configuration files in case it is something with your personal .octaverc or with the OS' base configuration.


Tried that:
octave:1> pause
xxx^C
octave:1>

No change in behavior.

Michael Godfrey <godfrey>
Group Member
Thu 15 Nov 2018 10:30:48 PM UTC, comment #3: 

I can (kind of) reproduce the problem.

After pause octave suspends, and I need to hit Ctrl-C to return to
octave prompt.

./run-octave -qf
octave:1> pause
x
y
z
^C
octave:1> __octave_config_info__ ("hg_id")
ans = 32d4ee071348




Version 4.4.1

__octave_config_info__ ("hg_id")
ans = 658153e1976d

 works fine on the same computer.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Thu 15 Nov 2018 10:10:55 PM UTC, comment #2: 

There might be something else going on.  pause with no argument works for me.  I tried both CLI and GUI versions of Octave.

@Michael: Maybe try starting with '-f' to avoid reading any configuration files in case it is something with your personal .octaverc or with the OS' base configuration.

You might also want to move your .inputrc file to a new name in case Readline is causing the issue.

Rik <rik5>
Group administrator
Thu 15 Nov 2018 07:23:12 PM UTC, comment #1: 

This is most probably due to the changes for bug #53729, which is still marked "Ready for test". Can you add a comment there?

Pantxo Diribarne <pantxo>
Group Member
Thu 15 Nov 2018 01:48:54 PM UTC, original submission:  

As of HG 1861e2ea0a4b pause
with no argument hangs Octave.
Typing any character or CR only echos the text.
^C is required to exit Octave.

Again this is using FC29 current update.

Michael Godfrey <godfrey>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #46053:  clear_cin2.patch added by pantxo (5KiB - text/x-patch)
file #46029:  clear_cin.patch added by pantxo (4KiB - text/x-patch)
file #45912:  kbtest.m added by pantxo (110B - text/x-objcsrc)
file #45455:  pause_timeout2.patch added by pantxo (4KiB - text/x-patch)
file #45453:  pause_timeout.patch added by pantxo (3KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hackdev (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by godfrey (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.

    Only group members can vote.

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-02 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2019-03-27 mtmiller Summarypause causes hang with glibc 2.28 pause() with no arguments does not return like kbhit() with glibc 2.28
    2019-02-26 mtmiller Severity5 - Blocker 4 - Important
        Release5.0.90 5.1.0
        Summarypause causes hang pause causes hang with glibc 2.28
    2019-02-01 mtmiller Release5.0.1 5.0.90
    2019-01-21 pantxo Attached File- Added clear_cin2.patch, #46053
    2019-01-19 pantxo Attached File- Added clear_cin.patch, #46029
        StatusWorks For Me Confirmed
    2019-01-09 pantxo Attached File- Added kbtest.m, #45912
    2019-01-07 godfrey Severity3 - Normal 5 - Blocker
        Releasedev 5.0.1
    2018-11-16 pantxo Attached File- Added pause_timeout2.patch, #45455
    2018-11-16 pantxo Attached File- Added pause_timeout.patch, #45453
    2018-11-15 rik5 StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code