[Gambas-user] [Gambas Bug Tracker] Bug #1329: Reading stdin

[bugtracker at gambaswiki.org]

http://gambaswiki.org/bugtracker/edit?object=BUG.1329&from=L21haW4-

Tobias BOEGE reported a new bug.

Summary
-------

Reading stdin

Type             : Bug
Priority         : Medium
Gambas version   : Master
Product          : Unknown


Description
-----------

I'm reporting some possibly related problems here. Consider this code template:

  Public Sub Application_Read()
    Dim s As String
    s = Read XYZ
    Debug s
  End

where I'm looking at varying expressions in place of XYZ when I call the program
using `$ gbx3 <<<"test"`.

(0) XYZ = -4096 which I remember seeing often. This works totally fine when you
know you want to read at most 4KiB. ✓

(1) XYZ = 10, which is strictly more than the 5 bytes I send.

  Main.Application_Read.9: #39: End of file
  Main.Application_Read.9
  Segmentation fault (core dumped)

I would expect an EOF error but not a segfault. It doesn't always crash and instead just
terminates with exit code 1 from the error. The segfault happens often enough on my system
to look reproducible. Alas, it seems to be one of those crashes that never happen under
gdb or valgrind.

(2) XYZ = Lof(File.In)

  Main.Application_Read.9: #39: End of file
  Main.Application_Read.9
  Segmentation fault (core dumped)

For some reason Lof(File.In) returns 10, even though I piped in "test\n", so this
is actually the same as above. Why is Lof equal to 10, though?

(3) XYZ = 4

  Main.Application_Read.14: test
  Main.Application_Read.12: #39: End of file
  Main.Application_Read.12
  Segmentation fault (core dumped)

Reads not all data the first time around and I get an expected EOF the second time the Read
event is raised, and a segfault again. Here, the program halts under gdb and I get the
following trace, which is probably the same thing as what happens with XYZ = 10:

  (gdb) r <input.txt
  Starting program: /usr/bin/gbx3 <input.txt
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/usr/lib/libthread_db.so.1".
  Main.Application_Read.14: test
  Main.Application_Read.12: #39: End of file
  Main.Application_Read.12
  ^C
  Program received signal SIGINT, Interrupt.
  0x0000555555572f8a in my_free (alloc=0x5555557e0ec8) at ../share/gb_alloc_temp.h:405
  405             pool = (size / SIZE_INC) - 1;
  (gdb) bt
  #0  0x0000555555572f8a in my_free (alloc=0x5555557e0ec8) at ../share/gb_alloc_temp.h:405
  #1  0x000055555558ef78 in clear_pool () at gbx_string.c:294
  #2  STRING_clear_cache () at gbx_string.c:399
  #3  0x000055555558ef91 in STRING_exit () at gbx_string.c:405
  #4  0x000055555558dd3f in main_exit (silent=1 '\001') at gbx.c:159
  #5  0x0000555555571c12 in main (argc=<optimized out>, argv=<optimized out>) at gbx.c:460

(4) XYZ = 5

  Main.Application_Read.14: test

This is good enough, but a feature request: in this case, all data is read and stdin is
closed by the shell (Eof(File.In) knows this) but the program doesn't stop. Can something
be done about this? In a way, there is no open fd to be watched anymore.

PS: Don't mind the changing line numbers in the Debug outputs. I kept adding these cases
to the test project, which increased the line number of the Debug statement between runs.


System information
------------------

3.10.90 4eec81132 (master)
Freshly compiled and installed for these tests.