bugGNU Octave - Bugs: bug #33330, fgets hangs octave when reading...


bug #33330: fgets hangs octave when reading newline

Submitter:  Carnë Draug <carandraug>
Submitted:  Tue 17 May 2011 02:24:03 PM UTC
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.2.4 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Mon 29 Jul 2013 05:02:05 AM UTC, comment #8: 

Check Matlab's own documentation on this (http://www.mathworks.com/help/matlab/import_export/import-text-data-files-with-low-level-io.html?#br4ssin).

In particular, I see:

"After each read operation, fgetl and fgets check the next character in the file for the end-of-file marker. Therefore, these functions sometimes set the end-of-file indicator before they return a value of -1."


"This behavior does not conform to the ANSI specifications for the related C language functions"

So, I think we have to keep it.  We could restrict this only to files, rather than sockets, if there is an easy way to tell that

Rik <rik5>
Group administrator
Sat 27 Jul 2013 10:06:56 PM UTC, comment #7: 

This bug is still open, so what needs to be done to verify if the hack listed in comment #1 is still needed for Matlab compatibility?

Mike Miller <mtmiller>
Group Member
Wed 18 May 2011 11:14:51 AM UTC, comment #6: 

Thank you so much Rik! For both the code and the explanation on how it works. I tried the code and now does exactly what I wanted.

I learn so much when using octave, really enjoy it and all thanks to people like you who take their time to explain this stuff and of corse to write octave as well. Thanks again

Carnë Draug <carandraug>
Group Member
Wed 18 May 2011 04:04:21 AM UTC, comment #5: 

The 'hang' is not really a hang.  When you do a read on a socket and there is nothing available the operating system has two choices.  The default is blocking I/O which means the process stops and waits for input.  For example, when you call zenity from a bash command line it stops and waits for you to do something with the graphical object.  It doesn't just return to the prompt and allow you to continue typing.  Octave is operating the same way.  If you must, you can tell the operating system that you want non-blocking I/O in which case any call to read something from the socket will return immediately if there is nothing there.  However, you shouldn't build this into a tight polling loop.  Don't try something like the loop below.

while (isempty (fscanf (fid, '%s', 'C')))
  sleep (1);

If you do need to change to non-blocking mode you can use the fcntl() function like so

fcntl (fid, F_SETFL, O_NONBLOCK);

in which case a read on an empty socket will return [] immediately.

Rik <rik5>
Group administrator
Wed 18 May 2011 12:50:38 AM UTC, comment #4: 

Thanks. This will at least read the last selected value (instead of the one before) but still hangs if the last selected value has already been read.

octave-3.2.3:26> fid = popen("zenity --scale --print-partial", "r");
## zenity scale dialog shows up
## move the  bar
octave-3.2.3:27> str = fscanf (fid, "%s", 'C')
str =27
octave-3.2.3:28> str = fscanf (fid, "%s", 'C')
## octave hangs. Does not return empty matrix
## move the bar
str = 46
## close dialog (press OK)
octave-3.2.3:29> str = fscanf (fid, "%s", 'C')
str = 46
## this is expected since the selected should be printed to the pipe again after pressing OK

Thanks in advance

Carnë Draug <carandraug>
Group Member
Tue 17 May 2011 11:48:01 PM UTC, comment #3: 

Try the following

str = fscanf (fid, "%s", 'C');

It works for me with the zenity example you posted.  Beware that you'll no longer get -1 on a closed dialog, but rather the empty matrix [].

Rik <rik5>
Group administrator
Tue 17 May 2011 11:04:53 PM UTC, comment #2: 


thanks for looking into this so quickly. I appreciate it immensely.

Building from a modified source is not an option for me since this is code for the zenity package on octave-forge. Is there any other workaround that I can do on my code? The current implementation of zenity_scale is pretty useless without being able to read the values.

If this is a bug on Matlab, shouldn't octave fix it before Matlab instead of trying to mimic the defective behavior of them until they fix it?

Carnë Draug <carandraug>
Group Member
Tue 17 May 2011 08:17:37 PM UTC, comment #1: 

Confirmed.  The problem seems to be an attempt to mimic Matlab's behavior exactly.  In this case it forces a kludge which works with files, which are non-blocking I/O, but fails with pipes where the process blocks and waits for new input.

If you are building from source, the solution is to comment out the kludge which begins at line 988 of the file oct-stream.cc and encompasses this stanza

if (! is.eof () && char_count > 0)
    // GAGME.  Matlab seems to check for EOF even if the last
    // character in a file is a newline character.  This is NOT
    // what the corresponding C-library functions do.
    int disgusting_compatibility_hack = is.get ();
    if (! is.eof ())
      is.putback (disgusting_compatibility_hack);

I'll also post something to the octave-maintainers mailing list.  It may be that Matlab has changed and we can ditch this hack entirely.

Rik <rik5>
Group administrator
Tue 17 May 2011 02:24:03 PM UTC, original submission:  

Bug report for Octave 3.2.4 configured for i486-pc-linux-gnu

If my understanding is correct, octave should return -1 when there's nothing else to read. When using fgets with at least zenity, it seems to hang. The problem seems to be on the last character (n) as can be shown by reading one character at a time.

## this will open a dialog box with a progress bar that can be
## moved. Every time the bar is moved the value where it stops
## should be printed
octave-3.2.4 > fid = popen("zenity --scale --print-partial", "r")
## adjust bar to value 16
## adjust bar to value 24
octave-3.2.4 > fgets(fid)
ans = 16

octave-3.2.4 > fgets(fid)
## octave hangs here
## adjust bar to value 46
ans = 24

octave-3.2.4 > fgets(fid)
## octave hangs here
## press OK on the zenity dialog
ans = 46

This example shows the problem being on the last character of the
value by using fgets to read one character at a time

octave-3.2.4 > fid = popen("zenity --scale --print-partial", "r")
## adjust bar to value 16
octave-3.2.4 > fgets(fid,1)
ans = 1
octave-3.2.4 > fgets(fid,1)
ans = 6
octave-3.2.4 > fgets(fid,1)
## octave hangs here instead of returning -1

This shows that zenity works fine in bash
$ zenity --scale --print-partial
## move bar to 16

## move bar to 27

## move bar to 54

## press ok

Configuration (please do not edit this section):

uname output:     Linux altar 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 GNU/Linux
configure opts:   '--build=i486-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=i486-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2'
Fortran compiler: gfortran
FFLAGS:           -O2 -g
FLIBS:            -lgfortranbegin -lgfortran
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.4.5 (Debian 4.4.5-5)
CFLAGS:           -O2 -g
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.4.5
CXXFLAGS:         -O2 -g
LD_CXX:           g++
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.2.4
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lhdf5 -lz -lm
SED:              /bin/sed

  -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _
  -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1

User-preferences (please do not edit this section):

  EDITOR = emacs
  EXEC_PATH = /usr/lib/octave/3.2.4/site/exec/i486-pc-linux-gnu:/usr/lib/octave/api-v37/site/exec/i486-pc-linux-gnu:/usr/lib/octave/site/exec/i486-pc-linux-gnu:/usr/lib/octave/3.2.4/exec/i486-pc-linux-gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
  IMAGE_PATH = .:/usr/share/octave/3.2.4/imagelib
  PAGER = pager
  PS1 = s:#>
  PS2 = >
  PS4 = +
  beep_on_error = 0
  completion_append_char = 
  crash_dumps_octave_core = 1
  echo_executing_commands = 0
  fixed_point_format = 0
  gnuplot_binary = gnuplot
# gnuplot_command_end = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/carandraug/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /usr/share/info/octave3.2.info
  info_program = info
  makeinfo_program = makeinfo
  max_recursion_depth = 256
  output_max_field_width = 5
  output_precision = 5
  page_output_immediately = 0
  page_screen_output = 1
# print_answer_id_name = <no value or error in displaying it>
  print_empty_dimensions = 1
  save_precision = 16
  saving_history = 1
  sighup_dumps_octave_core = 1
  sigterm_dumps_octave_core = 1
  silent_functions = 0
  split_long_rows = 1
  string_fill_char = 
  struct_levels_to_print = 2
  suppress_verbose_help_message = 0

Carnë Draug <carandraug>
Group Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by carandraug (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-07-29 rik5 StatusConfirmed Wont Fix
        Open/ClosedOpen Closed
    2013-07-27 mtmiller CategoryNone Libraries
        Item GroupNone Matlab Compatibility
    2011-05-17 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code