Re: Platform testing for concurrency scheduler runloop
On 7 Dec 2007, at 16:32, chromatic wrote: On Friday 07 December 2007 05:23:39 Allison Randal wrote: I'm about to turn on the concurrency scheduler runloop in Parrot trunk. Before I do, I'd like test results on as many platforms as possible (especially Windows, since it doesn't use POSIX threads). To test it, edit src/inter_create.c and uncomment the two lines that start with 'Parrot_cx...". Then run 'make test' and let me know if it fails any tests that passed before. On Ubuntu 7.10: [snip] On Debian 4.0 Test Summary Report --- t/configure/115-auto_warnings.t(Wstat: 0 Tests: 4 Failed: 0) TODO passed: 4 t/configure/124-auto_alignptrs-05.t(Wstat: 0 Tests: 21 Failed: 0) TODO passed: 20 t/configure/146-auto_snprintf-01.t (Wstat: 0 Tests: 31 Failed: 0) TODO passed: 30 t/src/intlist.t(Wstat: 0 Tests: 4 Failed: 0) TODO passed: 1-4 t/src/io.t (Wstat: 0 Tests: 20 Failed: 0) TODO passed: 16-17, 19 t/src/vtables.t(Wstat: 256 Tests: 4 Failed: 1) Failed test number(s): 4 Non-zero exit status: 1 Files=475, Tests=9747, 488 wallclock secs ( 0.61 usr 4.38 sys + 75.52 cusr 169.41 csys = 249.92 CPU) Result: FAIL Failed 1/475 test programs. 1/9747 subtests failed. make: *** [test] Error 255 But on Mac OS 10.5 I get random hangs. First at t/op/01-parse_ops..287/335 for about ten minutes until I interrupted it and then t/op/string_cs.1/50 for another ten or so minutes. -- Andy Armstrong, Hexten
Re: What is the origin of the nickname, "Texas quotes"?
> > So, it's because <> is so much bigger than «this», "this", or > 'this'? > Would that have anything to do with "Big hat, no cattle"? :-)* -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: What is the origin of the nickname, "Texas quotes"?
Chas. Owens wrote: Like a true Texan* (grin), he skewed the numbers to make Texas look bigger than it is. It is between 2.4** and 2.5*** when you include ... * I am resident of Virgina, so I have no axe to grind; I am just looking for a definitive answer. ** random sites on the Internet *** wikipedia: 663267/261797 = 2.5335 Ouch. But, back to Perl I didn't get an answer to my follow-up question: So, it's because <> is so much bigger than «this», "this", or 'this'? Chas. Owens wrote: *** wikipedia: 663267/261797 = 2.5335 As for skewing the numbers Actually, I just grabbed the land areas from the text of the two Wikipedia articles (570,380 /261,797~=2.1787). I didn't even notice that I was getting land area only. I didn't even see the "total area" that was conveniently available in the summary boxes. Really. I swear it. As a matter of fact, I've always been sensitive to the perception that Texans are braggarts. We had a family move to our area from California when I was young. They irritated me so much by their continual claims of California's superiority that I decided I never wanted to appear that obnoxious to anyone else, even if I am proud of my home state. Too many Texans are like a friend of mine who has a sign by his front door: "Never ask a man where he's from: if he's from Texas, he'll tell you; if he isn't, there's no point in embarrassing him." Makes me cringe, even if it /is/ all in fun. I told an Alaskan friend about that sign, and that's when he told me that if we didn't shut up about it, Alaska would split itself in half and make Texas the /third/ largest state. I suppose it's a measure of Texas pride that I was in my forties before I knew that Alaska was /that/ much bigger than Texas. =thom -- Numbers are like people; torture them enough and they'll tell you anything.
Re: Platform testing for concurrency scheduler runloop
Andy Armstrong wrote:
But on Mac OS 10.5 I get random hangs. First at
t/op/01-parse_ops..287/335
for about ten minutes until I interrupted it and then
t/op/string_cs.1/50
for another ten or so minutes.
Are you sure you've got the very latest version of all files on this box
('make realclean', etc)? A few revisions ago the scheduler runloop was
using a detached POSIX thread (like the old event system), and
occasionally had these hangs. It's now using a joined POSIX thread,
which resolves that problem on Mac OS 10.4.x and Ubuntu.
Also, try commenting out the 'Parrot_cx...' lines in src/inter_create.c
and recompiling, to make sure the other failures aren't completely
unrelated to the new scheduler runloop.
(Note to self to pick up a copy of 10.5.)
Allison
[perl #48326] [BUG] imcc register allocation does not consider PASM register usage
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #48326] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48326 > ACcording to PDD19: If you directly reference P99, Parrot will blindly allocate 100 registers It doesn't. .sub main P99 = new 'Integer' P99 = 3 print P99 .end running parrot -o - gives the following, as does parrot -t . # IMCC does produce b0rken PASM files # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392 main: new P0, 'Integer' new P0, 'Integer' set P0, 3 print P0 set_returns returncc According to the spec, this is a bug. Now, this isn't a big deal, because the semantics of the program aren't changed. The only problem I can imagine is for embedders, but I'm not sure if you can poke into parrot registers from a C program. If you can, and you expect something to be there because you stuffed it into a PASM style register (not symbolic PIR reg), then things go wrong. kjs
Re: Platform testing for concurrency scheduler runloop
On 8 Dec 2007, at 13:42, Allison Randal wrote:
Are you sure you've got the very latest version of all files on this
box ('make realclean', etc)?
Yup. I've just done make realclean && make && make test again and this
time it hung at
t/pmc/parrotlibrary1/1
(time passes)
Another run flies past t/pmc/parrotlibrary.t and hangs at
t/stm/basic_mt.1/4
A few revisions ago the scheduler runloop was using a detached POSIX
thread (like the old event system), and occasionally had these
hangs. It's now using a joined POSIX thread, which resolves that
problem on Mac OS 10.4.x and Ubuntu.
Also, try commenting out the 'Parrot_cx...' lines in src/
inter_create.c and recompiling, to make sure the other failures
aren't completely unrelated to the new scheduler runloop.
With those lines commented out the tests all run with just a couple of
failures.
(Note to self to pick up a copy of 10.5.)
Please let me know if there's anything you'd like me to investigate.
I'm afraid I don't know my way around parrot, er, at all - but I'm
willing to learn.
In happier news it's snowing here and repeatedly running the parrot
test suite is warming my knees up nicely :)
--
Andy Armstrong, Hexten
Re: Standards bearers (was "Re: xml and perl 6")
Larry Wall wrote: On Sun, Dec 02, 2007 at 07:43:25PM -0800, Peter Scott wrote: : I do feel strongly that we need some sort of solution to this so that Perl : 6 is not merely an outstanding framework that leaves all domain-specific : extensions to the end user. Perl 6 as a language doesn't address this (except to keep the library namespaces precise and accurate), but that doesn't mean it won't get addressed or that we don't want it addressed. We're aiming for an ecology more like Linux, where we distribute the kernel, and others build distributions around it, and those distributions are designed to make it easier for various classes of end users. Bear with me a minute: compiler implementation is conceptually different from language specification, yet language design choices affect compiler implementation, and hence compilation is taken into account when designing a language. The two are closely intertwined. So too, it seems to me, are language utilisation and language design intertwined, whilst appearing theoretically to be conceptually separate. The reasoning that eliminates as much problem related functionality from the core is solid. But if it leaves to others or to fate, the infant of perl6, I fear perl6 will not survive much beyond being a beautiful baby. If ordinary users, such as myself, cannot use the language because functionality does not exist, it wont be used. So much thought has gone into the language design. Surely, some concentrated thought by the inventive and resouceful minds of who lead this project should go into language utilisation and popularisation. Surely some common problem areas have to be addressed so that functionality - of some form - is available when p6 is at a stage it can be released? Database (SQL), web, xml processing as my guess for common functionality that people might need. The modules may change in the future, or evolve. But initial modules, and mechanisms to replace them, will help users use perl6. Richard In any case, I'm certain the community will also make sure that something CPANishly downloadable is there, since no distribution can possibly guess right all the time. But a single editorial board is not scalable over the long haul. We'll eventually need multiple such boards that compete among various perceived and real ecological niches. We can start with one distribution as long as it is explicitly realized that anyone can fork it at any time, for any reason. Then let Darwin take over, and see what the service economy does with it. Now, it might well be that a Perl standards body could specify a mininum suggested set of modules for any distribution to enhance interoperability, but we haven't got to that point yet, I don't think. Someone with an organizational bent could get a running start to come up with such a editorial center, but setting standards out ahead of practice is rarely the optimal approach. And right now, we would, at best, be guessing from Perl 5 "best practice". Maybe that's good enough to start with, if we can get any two people to agree on what the Perl 5 best practices are. :) Anyway, that's the reasoning behind supplying as little as possible with the P6 kernel. We don't want anyone mistaking it for a distribution in the first place, nor do we want us language lawyers to evolve into any kind of "official distribution board". Central planning doesn't scale over the long term. We should restrict our "federal" activities to those that help all the "states" get along with each other, at least well enough to avoid a civil war. Of course, as the U.S. proved at the beginning, when you fear a strong federal government it's possible to invent too weak a federal government. There's a balance in there somewhere that we're still trying to figure out... Larry
Re: Platform testing for concurrency scheduler runloop
chromatic wrote: On Ubuntu 7.10: t/src/vtables..1/4 # Failed test (t/src/vtables.t at line 142) # Exited with error code: [SIGNAL 139] [...] This didn't go away on a realclean. I even moved ending the runloop to before the full DOD when destroying an interpreter, but to no effect. Aye, this is the same problem as Andy Dougherty reported, and won't go away until the test changes to initialize the vtables for the test interpreter it creates. (There is no problem with a fully initialized interpreter.) I'm marking that test as TODO with RT#48357. It was already TODO on Win32. Allison
Re: Platform testing for concurrency scheduler runloop
On 8 Dec 2007, at 14:18, Andy Armstrong wrote: Please let me know if there's anything you'd like me to investigate. I'm afraid I don't know my way around parrot, er, at all - but I'm willing to learn. Ah, Mac OS 10.5 has dtrace - which I hadn't tried before but turns out to be rather cool. Anyway, attaching to parrot once it's hung suggests that it's deadlocked (I'd pretty much inferred that from the fact that it's CPU load goes to zero and I'm sure you knew that anyway). I have six threads - all waiting in __semwait_signal apart from one whose call stack looks like thread_start -> _pthread_start -> select$DARWIN_EXTSN If that kind of information helps at all I can try to work out a little more of what dtrace is actually doing. -- Andy Armstrong, Hexten
Re: Parrot & Partial application
chromatic wrote: On Thursday 06 December 2007 15:49:45 Jonathan Worthington wrote: What it implemented (when I get chance, which should be this weekend) as an arity method on the Sub PMC? That would be much nicer Implemented in r23598 for the Sub PMC. (which doesn't make sense with an NCI call) to determine if it has to pass parameters (which occurs *after* the invoke, which is sort of a problem if you want to pass parameters to the NCI call you've just invoked and which has already returned with an error that you haven't actually passed any parameters to it). Ah, yes, NCI. I'll have a look at implementing it there too. Another approach is to have a PMC that wraps up a sub PMC with the supplied arguments. It'd have an array for supplied positionals and a slurply for supplied named args. I think that'd give us what we want for implementing Perl 6's .assuming too, and perhaps better than a thunk... Heh, wouldn't you call that the Thunk PMC? I'd have thunk so. If anyone wants such a thing, I can take a crack at implementing it... Jonathan
Re: [perl #48326] [BUG] imcc register allocation does not consider PASM register usage
On Friday 07 December 2007 11:22:10 Klaas-Jan Stol wrote: > According to the spec, this is a bug. > > Now, this isn't a big deal, because the semantics of the program aren't > changed. The only problem I can imagine is for embedders, but I'm not sure > if you can poke into parrot registers from a C program. If you can, and you > expect something to be there because you stuffed it into a PASM style > register (not symbolic PIR reg), then things go wrong. Let it be known that any C program that pokes into Parrot registers is in a state of sin, and if the program breaks because of it, we shall all point and laugh. -- c
Re: Parrot & Partial application
On Saturday 08 December 2007 08:29:05 Jonathan Worthington wrote: > chromatic wrote: > > On Thursday 06 December 2007 15:49:45 Jonathan Worthington wrote: > >> What it implemented (when I get chance, which should be this weekend) as > >> an arity method on the Sub PMC? > > That would be much nicer > Implemented in r23598 for the Sub PMC. Two small things. First, the argument passing code should call this instead of VTABLE_invoke to find the arity. Second, it should be memoizable. I have some concerns about efficiency here (invoke is already very expensive), but let's get this right first and then worry about efficiency (but let me worry about efficiency now). > Ah, yes, NCI. I'll have a look at implementing it there too. These two changes ought to fix that long-standing bug about invoking a Sub/NCI from C, where you can pass parameters to the Sub but not to the NCI. -- c
Re: Platform testing for concurrency scheduler runloop
Andy Armstrong wrote: On 8 Dec 2007, at 14:18, Andy Armstrong wrote: Please let me know if there's anything you'd like me to investigate. I'm afraid I don't know my way around parrot, er, at all - but I'm willing to learn. Ah, Mac OS 10.5 has dtrace - which I hadn't tried before but turns out to be rather cool. Anyway, attaching to parrot once it's hung suggests that it's deadlocked (I'd pretty much inferred that from the fact that it's CPU load goes to zero and I'm sure you knew that anyway). I have six threads 6 threads is surprising, you should have 4 (the central interpreter, the I/O thread, the events thread, and the new concurrency scheduler thread). The particular hanging test could have its own threads added. What does the Mac OS "Activity Monitor" utility report for that process? (Or, in general. Watch it through a test run and see how many threads it reports for the parrot processes that flick by.) - all waiting in __semwait_signal apart from one whose call stack looks like thread_start -> _pthread_start -> select$DARWIN_EXTSN If that kind of information helps at all I can try to work out a little more of what dtrace is actually doing. That is useful. It's a pretty safe bet that the deadlocking resource is the scheduler PMC, so the question becomes, where is the contention? Especially in a test like t/pmc/parrotlibrary.t, which doesn't do anything but instantiate one PMC. Could you edit src/scheduler.c and change the value of CX_DEBUG to 1, recompile, and run the test suite? Most of the tests will fail because of the additional output on stderr, but if you can catch a hang, we'll have a little more detail on what stage the scheduler was in when the deadlock hit. Allison
Re: Platform testing for concurrency scheduler runloop
On 8 Dec 2007, at 20:22, Allison Randal wrote: Could you edit src/scheduler.c and change the value of CX_DEBUG to 1, recompile, and run the test suite? Most of the tests will fail because of the additional output on stderr, but if you can catch a hang, we'll have a little more detail on what stage the scheduler was in when the deadlock hit. CX_DEBUG = 1, make test, hangs quite promptly. The immediately preceding debug output looks like this: # Failed test (t/compilers/imcc/imcpasm/opt1.t at line 787) # got: '# IMCC does produce b0rken PASM files # # see http://guesthandling tasks in scheduler runloop # Found task ID # 1 # ended scheduler runloop # ' # expected: '# IMCC does produce b0rken PASM files # # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392 # _main: # inc N0 # end # ' (full transcript available here: http://hexten.net/junk/parrot1.txt) And Instruments is telling me this: http://hexten.net/junk/parrot1.png Only two threads this time. Here's another similar hang: http://hexten.net/junk/parrot2.png I can't seem to reproduce the six thread case. It seems to hang much more readily with CX_DEBUG enabled - including once during make rather than make test. What next? -- Andy Armstrong, Hexten
What's up with compilers/imcc?
When last I was playing with Parrot, I recall noises that imcc was not useful, and was effectively dead. Is this right, or am I misremembering? Is it worth my time to const & headerize it? If not, I'm pretty much done with headerizing. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
[perl #48357] Initialize vtables for newly created interpreter
# New Ticket Created by Allison Randal
# Please include the string: [perl #48357]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48357 >
Original Message
Subject: Re: Platform testing for concurrency scheduler runloop
Date: Fri, 7 Dec 2007 15:38:10 -0500 (EST)
From: Andy Dougherty <[EMAIL PROTECTED]>
To: Allison Randal <[EMAIL PROTECTED]>
CC: p2 <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
On Solaris 8/SPARC, the only regression is in src/vtables.t
$ perl5.10 -Ilib t/src/vtables.t
1..4
ok 1 - Parrot_new_vtable
ok 2 - Parrot_clone_vtable
not ok 3 - Parrot_destroy_vtable # TODO vtable not NULL after destroy
# Failed (TODO) test (t/src/vtables.t at line 100)
# got: 'ok
# not ok
# '
# expected: 'ok
# ok
# '
# './t/src/vtables_3' failed with exit code 0
not ok 4 - parrot_alloc_vtables
# Failed test (t/src/vtables.t at line 142)
# Exited with error code: [SIGNAL 139]
# Received:
#
# Expected:
# ok
# ok
# ok
#
# Looks like you failed 1 test of 4.
Under the debugger, here's what I see
$ dbx vtables_4
(dbx) run
Running: vtables_4
(process id 3750)
ok
ok
ok
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault
address) in pmc_new
at line 70 in file "pmc.c"
70 PMC *const classobj =
interp->vtables[base_type]->pmc_class;
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] pmc_new(interp = 0x485318, base_type = 79), line 70 in "pmc.c"
[2] Parrot_cx_runloop_end(interp = 0x485318), line 232 in
"scheduler.c"
[3] Parrot_really_destroy(interp = 0x485318, exit_code_unused =
0, arg_unused = (nil)), line 380 in "inter_create.c"
[4] Parrot_exit(interp = 0x485318, status = 0), line 94 in "exit.c"
[5] main(argc = 1, argv = 0xffbefa8c), line 33 in "vtables_4.c"
(dbx) print *interp
*interp = {
ctx = {
state = 0x486580
bp= {
regs_n = 0x4866e0
regs_i = 0x4866e0
}
bp_ps = {
regs_p = 0x4867e0
regs_s = 0x4867e0
}
}
ctx_mem = {
free_list= 0x486430
n_free_slots = 81
}
arena_base= 0x487078
class_hash= 0x4eb110
vtables = 0x67e0a0
n_vtable_max = 81
n_vtable_alloced = 100
[ etc. ]
}
(dbx) print *interp->vtables
*interp->vtables = (nil)
The problem may well be in the vtables_4.c test file and not in pmc_new:
#include
#include
#include
int
main(int argc, char* argv[])
{
Interp *interp;
VTABLE *vtable;
interp = Parrot_new(NULL);
if (!interp) {
return 1;
}
parrot_alloc_vtables(interp);
[ . . . ]
In parrot_alloc_vtables, space is allocated for the vtables, but
it is all zeroed. It doesn't point anywhere useful. Thus when
Parrot_cx_runloop_end() calls pmc_new(), and it does:
PMC *const classobj = interp->vtables[base_type]->pmc_class;
things go boom.
Whether this is a defect in the vtables_4 test sourcefile for failing to
initialize the vtables, or whether pmc_new ought to be more defensive, I
can't say.
--
Andy Dougherty [EMAIL PROTECTED]
Switch/Given and English, Was perl 6 grammar
I don't know why, this given... when sounds so 'English' without really being that English. The construct sounds better in English than case ...> because: a) Switch is more commonly used in English as a noun, eg., Use the switch to turn on the light. But because English can use nouns for verbs and adjectives as well, eg., 'Switch on the light' or 'he is a switched-on type of guy', it seems ok to use it in for control purposes. Except ... the verb is really 'switch on' not 'switch'. Also we have 'switch over', 'switch from', 'switch between' etc. where as 'switch' as a verb as in 'she just switched boyfriends' means exchanging one for another, not choosing between alternative cases. So really 'switch' as a verb is really more like 'toggle'. So when an English person (or at least one that cares about the use of language) sees 'switch' in a programming language, there is the feeling that something is missing, or not quite right. And there is absolutely no linguistic link between 'switch' and 'case'. If I am uncomfortable with 'switch', 'case' really sucks. In fact, whenever I work in language other than perl, and 'switch' is the preferred construct, I always have to check the syntax to work out what goes where. b) 'Given' is more commonly used in English as a verb form. 'He was given an award'. Also, it is in the correct form for use at the beginning of a sentence, eg., 'Given three choices, he chose the most profitable'. So we have something that looks and feels like it is a part of normal English speech. The 'when' part is also a natural tag in English indicating one of several alternatives. 'Given' can be used as noun (the power of English! as a language) as in 'we have a number of givens, but the issue is still unresolved'. This is much rarer than the use of 'given' in verb uses. c) You might ask, why bother? Just choose words, and since switch is the most common one, just use it. Well, computers dont care whether you use words or symbols, so long as semantics can be uniquely extracted from syntax, that is, the computer knows uniquely what you are trying to say to it. But the reality is that humans dont work that way. From the time of FORTRAN and COBOL, the aim has been to choose words over symbols so that they have semantic meaning for the programmer. It makes it easier for programmers to write descriptions of algorithms and operations, and to understand the logic of the descriptions they are writing. This reduces development and debugging time. Perl has been so successful, and my programming language of choice, because where words have been chosen, they have very similar semantics to normal English. That helps me in my programming. My own guess is that once Perl6 starts being used (When oh when oh when), other languages or dialects will switch 'switch' for 'given', or at the least, the 'given ... when' will be an alias for 'switch ... case'.
Re: Switch/Given and English, Was perl 6 grammar
On Dec 8, 2007, at 9:06 , Richard Hainsworth wrote: or not quite right. And there is absolutely no linguistic link between 'switch' and 'case'. If I am uncomfortable with 'switch', 'case' really sucks. In fact, whenever I work in language other than perl, and 'switch' is the preferred construct, I always have to check the syntax to work out what goes where. Actually, before C the construct was usually case ... when; compare, for example, Algol (/bin/sh lifted its case construct from Algol68, IIRC). (And see below.) b) 'Given' is more commonly used in English as a verb form. 'He was given an award'. Also, it is in the correct form for use at the beginning of a sentence, eg., 'Given three choices, he chose the most profitable'. So we have something that looks and feels like it is a part of normal English speech. The 'when' part is also a natural tag in English indicating one of several alternatives. 'Given' can be used as noun (the power of English! as a language) as in 'we have a number of givens, but the issue is still unresolved'. This is much rarer than the use of 'given' in verb uses. It is worth noting that given ... when is a way in which I would (and indeed have) expressed this *in English*, as opposed to when programming. (As is case ... when, but as an abbreviation of "in/ *given* the case of , when ...".) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: What's up with compilers/imcc?
On Saturday 08 December 2007 14:59:32 Andy Lester wrote: > When last I was playing with Parrot, I recall noises that imcc was not > useful, and was effectively dead. > > Is this right, or am I misremembering? You're misremembering. IMCC still handles all PIR, and you can't do much with Parrot without it. > Is it worth my time to const & headerize it? Yes, please do. -- c
[perl #48365] get_string() on Fresh Key PMC Causes Infinite Loop
# New Ticket Created by chromatic
# Please include the string: [perl #48365]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48365 >
Test #9 in t/oo/new.t consumes ever-increasing amounts of memory for me. I
ran it in the debugger, caused a segfault, and stopped the backtrace at:
#17283 0xb7e39340 in Parrot_Key_get_string (interp=0x804f008, pmc=0x8262790)
at ./src/pmc/key.pmc:146
#17284 0xb7d0b741 in key_string (interp=0x804f008, key=0x8262790)
at src/key.c:442
#17285 0xb7e39340 in Parrot_Key_get_string (interp=0x804f008, pmc=0x8262790)
at ./src/pmc/key.pmc:146
#17286 0xb7d0b741 in key_string (interp=0x804f008, key=0x8262790)
---Type to continue, or q to quit---q
at src/key.c:4Quit
Let's call that an infinite loop. The get_string vtable entry is pretty
simple:
STRING *get_string() {
return key_string(INTERP, SELF);
}
Here's the punchline in key_string (src/key.c):
switch (PObj_get_FLAGS(key) & KEY_type_FLAGS) {
/* ... code elided for explanation ... */
default:
case KEY_pmc_FLAG:
return VTABLE_get_string(interp, key);
}
That's right, there's an infinite loop here for Key PMCs with no flags set.
How do I know there are no flags set? Look at the initializer:
void init() {
PObj_custom_mark_SET(SELF);
}
It should never be possible to wedge Parrot into an infinite loop without
explicitly coding an infinite loop yourself, so we need to fix this. One
solution is to fix the switch statement so that the default behavior is to
return an empty string. Another solution is to set a default value in the
initializer.
Are there other options?
-- c
Re: [perl #48365] get_string() on Fresh Key PMC Causes Infinite Loop
On Saturday 08 December 2007 18:17:17 chromatic wrote: > Test #9 in t/oo/new.t consumes ever-increasing amounts of memory for me. I > ran it in the debugger, caused a segfault, and stopped the backtrace at: > > #17283 0xb7e39340 in Parrot_Key_get_string (interp=0x804f008, > pmc=0x8262790) at ./src/pmc/key.pmc:146 > #17284 0xb7d0b741 in key_string (interp=0x804f008, key=0x8262790) > at src/key.c:442 > #17285 0xb7e39340 in Parrot_Key_get_string (interp=0x804f008, > pmc=0x8262790) at ./src/pmc/key.pmc:146 > #17286 0xb7d0b741 in key_string (interp=0x804f008, key=0x8262790) > ---Type to continue, or q to quit---q > at src/key.c:4Quit > > Let's call that an infinite loop. My favorite option so far is to check if the Key PMC has any flags set and call key_string() if so. Otherwise, it returns the empty string. All coretests pass without infinite loops with this patch applied. -- c
