IO subsystem stuff
Perhaps someone with a bit more familiarity with the Parrot IO subsystem could give me some guidance here. I'm currently trying to get a new 'peek' opcode working, and I'm having difficulties getting the io_unix layer implemented correctly. As far as I know, I'd get a call down into the io_unix layer when the ParrotIO object isn't buffered. What I want to be able to do is to read()/fread() a character off of the io-fd filedescriptor, copy it into the buffer, then ungetc() it back onto the stream. Unfortunately, however, ungetc requires a (FILE *), while the ParrotIO object carries around only a raw file descriptor (I think). I've seen some instances where people will cast the raw descriptor to a (FILE *), however the man page for ungetc warns ominously in its BUGS section that: It is not advisable to mix calls to input functions from the stdio library with low - level calls to read() for the file descriptor associated with the input stream; the results will be undefined and very probably not what you want. Numerous segfaults would seem to confirm that this is indeed very probably not what I want. That being said, what is the best course for buffering such characters at the io_unix layer? I apparently am not able to use the standard library functions to do so (additionally, they only guarantee that you can peek and replace a single character). -c
Re: Testing signal handlers
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT The attached t/pmc/signal.t should send a SIGINT to a sleeping or LT looping PASM test. This basically works, but the test output looks a LT bit ugly: LT t/pmc/signal# No tests run! LT t/pmc/signalok 1/2# Looks like you planned 2 tests but LT only ran 1. LT t/pmc/signalok LT It seems, that due to the fork, the test system is getting an empty LT test result too. Test::* can't handle output from forked children (it traps redirect STDOUT in the current process so it has no access to STDOUT of a child). this is a known problem. there are several ways around it. one, have the child signal the parent which can then report test results. two, have the child send data back to the parent (via a pipe or even a temp file) and then have the parent report results. you can also signal yourself and not need a child. i have a test script for event loops that works in a single process (it uses a socketpair to test i/o events). i can send it to you if you want. obviously it will need major changes to test parrot but the overall setup and test stuff should be useful to you. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
COWed stack bug (was: IMCC - PerlArray getting trounced)
Will Coleda wrote: Well, that was festive. I can reproduce that bug in 22 lines! Great. The bug (and other reported curruptions) are definitely coming from the COW logic in register.c. This is what happens: Setting up the exception handler (which is a continuation) triggers COW setting of the register stacks. Then on first subroutine return from __inner, the register stack is unCOWed (the chunk is copied). When then returning from __outer stack-top-used is still 2 end the same chunk gets popped off the stack, because the interpreter's stack is still unchanged. The register restoring memcpy is the same *twice*: memcpy (dstpp=0x824ca50, srcpp=0x4017d9a0, len=64) So returning from __outer places P17 (the RetContinuation of __inner) in mains registers and ruins the PerlUndef that you wanted to print. :get_string() not implemented in class 'RetContinuation' ... which then causes this error. Just returning from mark_register_stack_cow() makes the bug vanish (but doesn't fix anything) As mentioned several times, a COWed buffer needs distinct buffer headers and shared buffer memory. The current implementation in register *and* other stacks is broken. *Fixes welcome*. You can currently avoid the bug by not using Continuations and Exception Handlers. Thanks for your test program, leo
Re: Security problems with UnManagedStruct
On Jan 27, 2004, at 7:29 AM, Leopold Toetsch wrote: getinterp P5 dlfunc P0, Nul, Parrot_UnManagedStruct_get_pointer, pIP ... This is unlimited self-inspection and self-modification :) With little additions (nested structs) one could read/write all Parrot_Interp internals (including possible security bits) and not only registers like above. But current state is already sufficient to seriously damage the interpreter ($P2 above is a struct representing the current interpreter) This type of security issue seems inherent in anything NCI-related--once NCI is involved, all bets are off. It seems that, in order to guard against this (and related problems), any sort of secure mode operation of parrot would have to block use of any of the NCI infrastructure. JEff
Re: IMCC - PerlArray getting trounced
Well, that was festive. I can reproduce that bug in 22 lines! I expect the following code to print out a single colon (since PerlUndef prints as the empty string) and a newline. Instead, I get: :get_string() not implemented in class 'RetContinuation' which shows that the PerlUndef I assigned to $P1 in _main has morphed into a RetContinuation after the call to __outer in __main. How to avoid tripping the bug: 1) call __inner from __main directly, instead of outer. 2) comment out the newsub line in __inner. (Or, convert the newsub to a $P1 = new PerlString\n$P1 = a, which may be a more useful example) Note that I never actually set_eh the Exception Handler. I merely instantiate it and never call it. (Nor do I call __ignore -- I could change the IMC so that the handler called __outer instead of __ignore and drop the __ignore, but this is a little clearer, I think.) I fully expect to be told I'm missing something obvious, which, since it's 1:30 in the morning, would be expected, but since I started tracking this down when it was still yesterday, would also be rather sad. =-) .pcc_sub __main prototyped $P1 = new PerlUndef print $P1 print : __outer() print $P1 print \n end .end .pcc_sub __outer prototyped __inner() .pcc_begin_return .pcc_end_return .end .pcc_sub __inner prototyped newsub $P1, .Exception_Handler, __ignore .pcc_begin_return .pcc_end_return .end .sub __ignore noop .end On Tuesday, January 27, 2004, at 07:53 PM, Will Coleda wrote: Sorry about the delay in responding. My current sample program is 2760 lines of imcc in 23 files, plus a small .tcl script. I'll see if I can trim that down to a more reasonable test case. On Monday, January 26, 2004, at 05:32 AM, Leopold Toetsch wrote: Will Coleda [EMAIL PROTECTED] wrote: I'm trying to track down a problem with a PerlArray that is getting modified on me. I have a snippet of code like: Could you please provide a complete program, that imposes the bug? leo -- Will Coke Coledawill at coleda dot com -- Will Coke Coledawill at coleda dot com
Re: Security problems with UnManagedStruct
Leopold Toetsch writes: This is unlimited self-inspection and self-modification :) With little additions (nested structs) one could read/write all Parrot_Interp internals (including possible security bits) and not only registers like above. But current state is already sufficient to seriously damage the interpreter ($P2 above is a struct representing the current interpreter) Uh huh. I saw this coming when we first started rediscussing UnmanagedStruct. I see it not as a security hole, but as serious internal-hacking power without C code. I don't think it's fair to say that if you do something like this that the interpreter won't crash. You're being truly, ungodly evil, and you deserve what you get. But I also think it's important that this stay possible. When we're worried about security, we don't allow dlfunc (except in certain places) anyway. Luke
Re: This week's summary
The Perl 6 Summarizer wrote: The costs of sharing Leo Töposted a test program and some results for timing the difference between using shared and unshared PMCs. ... Hopefully the benchmark will get checked into examples/benchmarks as suggested by Luke earlier. Done now. $ time perl58-th shared_ref.pl real0m8.694s $ time parrot shared_ref.pasm real0m0.375s (Unoptimized parrot build, Athlon 800, pthreads/linux-i686) I hope the code is somehow equivalent. leo
Re: Testing signal handlers
Hi,
On Tue, Jan 27, 2004 at 12:49:25PM -0500, Uri Guttman wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT The attached t/pmc/signal.t should send a SIGINT to a sleeping or
LT looping PASM test. This basically works, but the test output looks a
LT bit ugly:
LT t/pmc/signal# No tests run!
LT t/pmc/signalok 1/2# Looks like you planned 2 tests but
LT only ran 1.
LT t/pmc/signalok
LT It seems, that due to the fork, the test system is getting an empty
LT test result too.
Test::* can't handle output from forked children (it traps redirect
STDOUT in the current process so it has no access to STDOUT of a
child). this is a known problem. there are several ways around it. one,
I had similar problem before with Test::More tests.
Try silencing the child with something like:
{
no warnings 'redefine';
*Test::Builder::_ending = sub {};
}
before exit(0).
This assumes that Parrot uses Test::Builder, which seems to be the
case from a quick grep :)
Thanks,
Boris
Re: Testing signal handlers
Uri Guttman wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT The attached t/pmc/signal.t should send a SIGINT to a sleeping or LT looping PASM test. This basically works, but the test output looks a Test::* can't handle output from forked children (it traps redirect STDOUT in the current process so it has no access to STDOUT of a child). I've now changed the code and use an SIGALRM handler to send a SIGINT to parrot. Works fine. Thanks for your comments, uri leo
Re: Testing signal handlers
On Tue, Jan 27, 2004 at 12:49:25PM -0500, Uri Guttman wrote:
Test::* can't handle output from forked children
Yes, the problem is the child process can't inform the parent of how many
tests it ran. The simplest way around this problem is to have the
parent account for any tests run in the child by incrementing the test
counter manually.
use Test::More tests = 4;
my $builder = Test::More-builder;
pass 'some test in the parent';
if( fork ) {
# account for the one test run in the child.
$builder-current_test($builder-current_test + 1);
pass 'another test in the parent';
}
else {
pass 'a test in the child';
exit;
}
pass 'one last test in the parent';
It can also sometimes make things less complicated if you shut off test
numbers ($builder-use_numbers(0)).
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
If it's stupid, but it works, it isn't stupid.
Re: This week's summary
At 10:40 +0100 1/28/04, Leopold Toetsch wrote: The Perl 6 Summarizer wrote: The costs of sharing Leo Töposted a test program and some results for timing the difference between using shared and unshared PMCs. ... Hopefully the benchmark will get checked into examples/benchmarks as suggested by Luke earlier. Done now. $ time perl58-th shared_ref.pl real0m8.694s $ time parrot shared_ref.pasm real0m0.375s Ah.. I want a Ponie! ;-) Liz
[CVS ci] (was: Managed and unmanaged structs (Another for the todo list))
chromatic wrote: On Sun, 2004-01-25 at 02:19, Leopold Toetsch wrote: s. t/pmc/orderedhash.t The initializer of the struct could look like: new P1, .OrderedHash set P1[a], .DATATYPE_a set P1[1], 0 set P1[2], 0 set P1[b], .DATATYPE_b set P1[4], 0 set P1[5], 0 new P2, .UnManagedStruct, P1 Now you can access P2[0] := P2[a] or P2[1] := P2[b] elements of the structure by name or by struct item index. (The index is internally multiplied by 3, so that it maps to the initializer item). Ahh, I think I get it. Here's what a couple of hours of fumbling produced. It's still not quite right and I'm stuck, but I'm further than before. I've corrected your code and the example, which is a new test now. Its working but need more testing. So just get it from CVS. leo
Re: Some namespace notes
On Thu, 15 Jan 2004 23:00:53 -0800, Jeff Clites wrote: I think we shouldn't try to do any sort of cross-language unification. That is, if we some day have a Parrot version of Java, and in Perl6 code I want to reference a global created inside of some Java class I've loaded in, it would be clearer to just reference this as java.lang.String.CASE_INSENSITIVE_ORDER, even inside of Perl6 code-- rather than having to do something like java::lang::String::CASE_INSENSITIVE_ORDER. Parrot itself would be completely ignorant of any concept of a separator character--these would just be uninterpreted strings, and foo::bar and foo.bar would be separate namespaces, whatever the language. What about languages which have the same separator, such as '::' (perl5, perl6, ruby) or '.' (java, python)? They are going to be unified either way. I think it's confusing to try to unify namespaces across languages, and doesn't buy us anything. Without namespace unification, how else are you going to even specify File::Spec from java, or java.lang.string from perl5? We can obviously invent suitable syntax for perl6, so that it can cope with arbitrarily named packages, but we don't have that luxury with most of the other languages we want to support. Then the question becomes, What about namespace clashes?, which Tim has already addressed. -- Peter Haworth [EMAIL PROTECTED] Perl 5's goal was to make easy things easy, and hard things possible. We want Perl 6 to make easy things trivial, hard things easy, and impossible things merely hard. -- Damian Conway, _Linux magazine_ 2003-04
