Discussion:
[perl #61290] [BIG] can't peek on stdin
(too old to reply)
François PERRAD
2008-12-11 14:14:36 UTC
Permalink
# New Ticket Created by François PERRAD
# Please include the string: [perl #61290]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=61290 >


Since the merge of the branch ppd22io, the mode of the stdin stream has changed.
Currently, it isn't possible to peek on stdin.

$ cat peek.pir
.sub 'main'
$P0 = getstdin
$S0 = peek $S0
.end

$ ./parrot peek.pir < peek.pir
Can't peek at unbuffered I/O

The issue was detected with I/O library of Lua (see languages/lua/t/io.t#17).

François.
Chromatic
2008-12-23 22:07:53 UTC
Permalink
Post by François PERRAD
Since the merge of the branch ppd22io, the mode of the stdin stream has
changed. Currently, it isn't possible to peek on stdin.
$ cat peek.pir
.sub 'main'
$P0 = getstdin
$S0 = peek $S0
.end
$ ./parrot peek.pir < peek.pir
Can't peek at unbuffered I/O
The issue was detected with I/O library of Lua (see
languages/lua/t/io.t#17).
We should support this; how about upgrading the IO PMC to buffered reads when
we detect a peek? Here's a patch that makes the test pass for me. Any
objections, anyone else?

-- c
Chromatic
2008-12-26 20:17:54 UTC
Permalink
Are you sure this works? Have you checked that the resulting string is
correct? See Trac #52.
Fixed in r34399 -- calling Parrot_allocate_string() on the fake string
constructed for reading broke things. Parrot_reallocate_string() works
better.

-- c
Bob Rogers
2008-12-26 22:16:44 UTC
Permalink
From: chromatic <***@wgz.org>
Date: Fri, 26 Dec 2008 12:17:54 -0800
Are you sure this works? Have you checked that the resulting string is
correct? See Trac #52.
Fixed in r34399 -- calling Parrot_allocate_string() on the fake string
constructed for reading broke things. Parrot_reallocate_string() works
better.

-- c

Great; thanks. (I didn't know there was a Parrot_reallocate_string.)

Unfortunately, this still leaves me unable to use the trunk (also
r34399) because of a nasty segfault. It happens when loading the first
PBC file, so it seems like it ought to be easy to reproduce, except that
every time I try to isolate a test case, it stubbornly refuses to fail.
The *same* byte code file will fail if I invoke Parrot on it from the
command line, but works if invoked from a makefile! Using -G makes no
difference.

The segfault happens eventually because PF_fetch_string passes NULL
to string_make, which it turns into "ascii", but then complains that it
can't find that charset. The backtrace below was created from a
breakpoint in Parrot_ex_throw_from_c_args; unfortunately, without the
breakpoint, Parrot_ex_throw_from_c_args tries to use string_make on its
own error message, with the same failure, which exhausts the stack.

Any suggestions on how to track this down? I'd send you the PBC file
in question, except that it's unlikely to fail for you.

-- Bob

P.S. The list is not getting its copies of these posts because
mx.develooper.com is refusing connections. Kudos to the wgz.org mail
admins for not discriminating against the little guy.

------------------------------------------------------------------------
(gdb) r kea.pbc
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/src/parrot/parrot kea.pbc
Failed to read a valid object file image from memory.
Error in re-setting breakpoint 1:
No source file named exceptions.c.
Breakpoint 1 at 0xb7b443d2: file src/exceptions.c, line 374.
[Thread debugging using libthread_db enabled]
[New Thread -1229732144 (LWP 8027)]
warning: Lowest section in /usr/lib/libicudata.so.34 is .hash at 000000b4
[Switching to Thread -1229732144 (LWP 8027)]

Breakpoint 1, Parrot_ex_throw_from_c_args (interp=0x8050040, ret_addr=0x0, exitcode=4, format=0xb7e495f0 "Can't make '%s' charset strings") at src/exceptions.c:374
(gdb) bt
#0 Parrot_ex_throw_from_c_args (interp=0x8050040, ret_addr=0x0, exitcode=4, format=0xb7e495f0 "Can't make '%s' charset strings") at src/exceptions.c:374
#1 0xb7ad1b48 in string_make (interp=0x8050040, buffer=0x805530c "\004", len=0, charset_name=0xb7e49596 "ascii", flags=0) at src/string.c:719
#2 0xb7b9999d in PF_fetch_string (interp=0x8050040, pf=0x81186b0, cursor=0x810ba1c) at src/packfile/pf_items.c:682
#3 0xb7b88396 in shift_opcode_string (interp=0x8050040, io=0x81186a0) at src/pmc_freeze.c:806
#4 0xb7b513cc in hash_thaw (interp=0x8050040, hash=0x8118808, info=0xbf9adee8) at src/hash.c:468
#5 0xb7b516d1 in parrot_hash_visit (interp=0x8050040, hash=0x8118808, pinfo=0xbf9adee8) at src/hash.c:582
#6 0xb7d5d4c8 in Parrot_Hash_visit (interp=0x8050040, pmc=0x80e8f40, info=0xbf9adee8) at ./src/pmc/hash.pmc:1033
#7 0xb7b895dc in visit_loop_todo_list (interp=0x8050040, current=0x80e8f40, info=0xbf9adee8) at src/pmc_freeze.c:1567
#8 0xb7b898e6 in run_thaw (interp=0x8050040, image=0x810ba10, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1689
#9 0xb7b89b60 in Parrot_thaw (interp=0x8050040, image=0x810ba10) at src/pmc_freeze.c:1809
#10 0xb7b847f0 in PackFile_Constant_unpack_pmc (interp=0x8050040, constt=0x8116ff0, self=0x8118588, cursor=0xb6b0e498) at src/packfile.c:3588
#11 0xb7b84748 in PackFile_Constant_unpack (interp=0x8050040, constt=0x8116ff0, self=0x8118588, cursor=0xb6b0e348) at src/packfile.c:3542
#12 0xb7b8444c in PackFile_ConstTable_unpack (interp=0x8050040, seg=0x8116ff0, cursor=0xb6b0e344) at src/packfile.c:3338
#13 0xb7b81b0a in PackFile_Segment_unpack (interp=0x8050040, self=0x8116ff0, cursor=0xb6b0e340) at src/packfile.c:1614
#14 0xb7b8202e in directory_unpack (interp=0x8050040, segp=0x8116db8, cursor=0xb6b0e330) at src/packfile.c:1808
#15 0xb7b81b0a in PackFile_Segment_unpack (interp=0x8050040, self=0x8116db8, cursor=0xb6b09040) at src/packfile.c:1614
#16 0xb7b80a7a in PackFile_unpack (interp=0x8050040, self=0x8116db8, packed=0xb6b09000, packed_size=70192) at src/packfile.c:877
#17 0xb7b40e56 in Parrot_readbc (interp=0x8050040, fullname=0xbf9b037d "kea.pbc") at src/embed.c:513
#18 0xb7e3354f in imcc_run (interp=0x8050040, sourcefile=0xbf9b037d "kea.pbc", argc=1, argv=0xbf9ae2f8) at compilers/imcc/main.c:1046
#19 0x08048998 in main (argc=1, argv=0xbf9ae2f8) at src/main.c:61
(gdb) f 2
#2 0xb7b9999d in PF_fetch_string (interp=0x8050040, pf=0x81186b0, cursor=0x810ba1c) at src/packfile/pf_items.c:682
(gdb) p charset_name
$1 = 0x0
(gdb)
Bob Rogers
2008-12-27 03:54:40 UTC
Permalink
From: Bob Rogers <rogers-***@rgrjr.dyndns.org>
Date: Fri, 26 Dec 2008 17:16:44 -0500

P.S. The list is not getting its copies of these posts because
mx.develooper.com is refusing connections. Kudos to the wgz.org mail
admins for not discriminating against the little guy.

I take that back; it was my configuration error. Kudos to Ask for
pointing me at the real problem.

-- Bob
Bob Rogers
2008-12-24 23:57:20 UTC
Permalink
From: chromatic <***@wgz.org>
Date: Tue, 23 Dec 2008 14:07:53 -0800
Post by François PERRAD
Since the merge of the branch ppd22io, the mode of the stdin stream has
changed. Currently, it isn't possible to peek on stdin . . .
The issue was detected with I/O library of Lua (see
languages/lua/t/io.t#17).
We should support this; how about upgrading the IO PMC to buffered reads when
we detect a peek? Here's a patch that makes the test pass for me. Any
objections, anyone else?

-- c

Are you sure this works? Have you checked that the resulting string is
correct? See Trac #52.

-- Bob Rogers
http://www.rgrjr.com/

Loading...