Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

[perl #39778] Segfault when using a Namespace with an Iterator

10 views
Skip to first unread message

Matt Diephouse

unread,
Jul 10, 2006, 2:52:23 AM7/10/06
to bugs-bi...@rt.perl.org
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39778]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39778 >


Trying to use an Iterator with a NameSpace makes Parrot segfault:

mini:~/Projects/parrot mdiep$ cat test.pir
.sub main :main
.local pmc iter, ns
ns = get_namespace

iter = new .Iterator, ns
loop:
unless iter goto loop_end
$P0 = shift iter

$S0 = $P0
print $S0
print "\n"
goto loop

loop_end:
end
.end

mini:~/Projects/parrot mdiep$ parrot test.pir
Segmentation fault
mini:~/Projects/parrot mdiep$

This is bad for 2 reasons: I need to iterate through the items in the
namespace and parrot should never segfault.

--
Matt Diephouse

Chip Salzenberg

unread,
Jul 10, 2006, 8:20:34 PM7/10/06
to parrotbug...@parrotcode.org
On Sun, Jul 09, 2006 at 11:52:23PM -0700, Matt Diephouse wrote:
> Trying to use an Iterator with a NameSpace makes Parrot segfault

Ouch.

The current namespace class is typed but in a silly way -- not with name
mangling but with actually storing two things with exactly the same name.
(One being a sub-namespace, and the other being anything else.)

So iterating through it requires custom code.

Frankly I'd prefer to make the default namespace actually be a hash with
extra behaviors (methods mostly), but that requires something else first,
namely, the rearrangement of the Parrot namespace so that Parrot no longer
requires a class object and its namespace object to have the same name.

I'm going to create a bug for this plan and then connect that bug to this.
--
Chip Salzenberg <ch...@pobox.com>

Matt Diephouse via RT

unread,
Jul 16, 2006, 5:37:39 PM7/16/06
to perl6-i...@perl.org
mdiep wrote:
> Trying to use an Iterator with a NameSpace makes Parrot segfault:
>
> mini:~/Projects/parrot mdiep$ cat test.pir
> .sub main :main
> .local pmc iter, ns
> ns = get_namespace
>
> iter = new .Iterator, ns
> loop:
> unless iter goto loop_end
> $P0 = shift iter
>
> $S0 = $P0
> print $S0
> print "\n"
> goto loop
>
> loop_end:
> end
> .end
>
> mini:~/Projects/parrot mdiep$ parrot test.pir
> Segmentation fault
> mini:~/Projects/parrot mdiep$

FYI, changing C< $P0 = shift iter > to C< $S0 = shift iter > makes this example work
corrrectly (of course, you also have to remove C< $S0 = $P0 >).

--
Matt Diephouse 

Bob Rogers

unread,
Jul 16, 2006, 9:30:27 PM7/16/06
to bugs-par...@netlabs.develooper.com, parrot-...@perl.org
From: "Matt Diephouse via RT" <bugs-par...@netlabs.develooper.com>
Date: Sun, 16 Jul 2006 14:37:39 -0700

--
Matt Diephouse 

It doesn't segfault for me (GNU/Linux, SuSE 9.0), but does DoS my system
pretty effectively. This seems to be because Iterator.shift_pmc
eventually calls key_string => VTABLE_get_string => Key.get_string =>
get_string, ad nauseam. But the right thing is not obvious to me.

BTW, it doesn't seem right that I can run Parrot for only a second or
two and get more than 300K stack frames deep. Isn't there a way to
limit the stack to something sane, since more than a few MB of C stack
usage is a pretty sure sign of a Parrot bug?

-- Bob Rogers
http://rgrjr.dyndns.org/

------------------------------------------------------------------------
(gdb) thread 1
[Switching to thread 1 (Thread 16384 (LWP 1138))]#0 0x401e97a7 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:148
(gdb) bt
#0 0x401e97a7 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:148
#1 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#2 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#3 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#4 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#5 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#6 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#7 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#8 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#9 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#10 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#11 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#12 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#13 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#14 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#15 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#16 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#17 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#18 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#19 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#20 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#21 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#22 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#23 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#24 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#25 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#26 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#27 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#28 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#29 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#30 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#31 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#32 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#33 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#34 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#35 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#36 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#37 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#38 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#39 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#40 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#41 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:367
#42 0x401e97c1 in Parrot_Key_get_string (interpreter=0x8050fa0, pmc=0x81ba214) at key.pmc:149
#43 0x4016b067 in key_string (interpreter=0x8050fa0, key=0x81ba214) at src/key.c:

Leopold Toetsch

unread,
Jul 17, 2006, 5:50:35 AM7/17/06
to perl6-i...@perl.org, Bob Rogers
Am Montag, 17. Juli 2006 03:30 schrieb Bob Rogers:
>    BTW, it doesn't seem right that I can run Parrot for only a second or
> two and get more than 300K stack frames deep.  Isn't there a way to
> limit the stack to something sane, since more than a few MB of C stack
> usage is a pretty sure sign of a Parrot bug?

'man ulimit' is your friend.

In the long run, we'll have to refine the iteration interface, which might
prevent such recursion.

leo

Bob Rogers

unread,
Jul 17, 2006, 9:26:12 PM7/17/06
to Leopold Toetsch, perl6-i...@perl.org
From: Leopold Toetsch <l...@toetsch.at>
Date: Mon, 17 Jul 2006 11:50:35 +0200

Am Montag, 17. Juli 2006 03:30 schrieb Bob Rogers:
>    BTW, it doesn't seem right that I can run Parrot for only a second or
> two and get more than 300K stack frames deep.  Isn't there a way to
> limit the stack to something sane, since more than a few MB of C stack
> usage is a pretty sure sign of a Parrot bug?

'man ulimit' is your friend.

It certainly is; thank you.

But what I really meant was: Shouldn't Parrot do a 'setrlimit' on
itself in order to detect these sorts of bugs sooner, and more usefully?
Or, maybe 'ulimit -s' would be appropriate before running test cases?

-- Bob

Chip Salzenberg

unread,
Jul 17, 2006, 10:24:29 PM7/17/06
to Bob Rogers, Leopold Toetsch, perl6-i...@perl.org
On Mon, Jul 17, 2006 at 09:26:12PM -0400, Bob Rogers wrote:
> But what I really meant was: Shouldn't Parrot do a 'setrlimit' on
> itself in order to detect these sorts of bugs sooner, and more usefully?
> Or, maybe 'ulimit -s' would be appropriate before running test cases?

Running the test suite (or at least most of it) under ulimit is indeed a
good idea. Whoever jumps in on this, please be prepared to adjust the value
as reports come in from the field. :-)
--
Chip Salzenberg <ch...@pobox.com>

Chip Salzenberg

unread,
Aug 3, 2006, 4:27:37 PM8/3/06
to Bob Rogers, bugs-par...@netlabs.develooper.com, parrot-...@perl.org
So, is the namespace iteration working now ... at least enough to close the
ticket that says "segfault" in large friendly lettes?
--
Chip Salzenberg <ch...@pobox.com>

Leopold Toetsch

unread,
Aug 3, 2006, 4:42:24 PM8/3/06
to perl6-i...@perl.org
Am Donnerstag, 3. August 2006 22:27 schrieb Chip Salzenberg:
> So, is the namespace iteration working now ... at least enough to close the
> ticket that says "segfault" in large friendly lettes?

The segfault in the first place wasn't related to namespaces at all, more to
hash iteration abuse/bug/inconvenience. So yes, I think.

leo

0 new messages