On Thu, Jul 17, 2008 at 11:26 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 17, 2008 at 9:47 AM, Will Coleda via RT
> <[EMAIL PROTECTED]> wrote:
>> On Thu Jul 10 06:40:28 2008, coke wrote:
>>> Using tcl, I can make parrot segfault in this branch.
>>>
>>> $ ../../parrot tcl.pbc -e "error eek"
>>> Segmentation fault
>>>
>>> Real tclsh, if you put that in a file and ran it, would say:
>>> eek
>>>     while executing
>>> "error eek"
>>>     (file "foo.tcl" line 1)
>>>
>>> The backtrace is:
>>> #0  0xb7b75357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
>>>     at src/string.c:516
>>> #1  0xb7b9a69b in Parrot_concat_s_sc (cur_opcode=0xb7a887f4,
>>> interp=0x804f040)
>>>     at src/ops/string.ops:112
>>> #2  0xb7c1c3e4 in runops_slow_core (interp=0x804f040, pc=0xb7a887f4)
>>>     at src/runops_cores.c:221
>>> #3  0xb7bee9d6 in runops_int (interp=0x804f040, offset=3)
>>>     at src/interpreter.c:929
>>> #4  0xb7bef2b3 in runops (interp=0x804f040, offs=3) at
>>> src/inter_run.c:101
>>> #5  0xb7bef550 in runops_args (interp=0x804f040, sub=0x82233a8,
>>> obj=0x809dac0,
>>>     meth_unused=0x0, sig=0xb7e4e20f "vP",
>>>     ap=0xbff5ce7c
>>> "è1\"\b¸Îõ¿Pìï·\220Q\034\bè1\"\b¨3\"[EMAIL PROTECTED]") at
>>> src/inter_run.c:223
>>> #6  0xb7bef68c in Parrot_runops_fromc_args (interp=0x804f040,
>>> sub=0x82233a8,
>>>     sig=0xb7e4e20f "vP") at src/inter_run.c:295
>>> #7  0xb7bd8b37 in Parrot_runcode (interp=0x804f040, argc=3,
>>> argv=0xbff5cfe8)
>>>     at src/embed.c:944
>>> #8  0xb7e2a812 in imcc_run_pbc (interp=0x804f040, obj_file=0,
>>> output_file=0x0,
>>>     argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:783
>>> #9  0xb7e2b202 in imcc_run (interp=0x804f040, sourcefile=0xbff5d9b0
>>> "tcl.pbc",
>>>     argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:1071
>>> #10 0x08048988 in main (argc=3, argv=0xbff5cfe8) at src/main.c:61
>>>
>>>
>>> This may be related to the intermediate test file I began with:
>>>
>>> catch after result
>>> if {$result != {wrong # args: should be "after option ?arg arg ...?"}}
>>> {
>>>   puts -nonewline "not "
>>> }
>>> puts "ok"
>>>
>>> The first line eval's the command "after", and stores the error
>>> message in "result" ([after] requires arguments). In tclsh, this
>>> prints "ok". Partcl in this branch prints "not ok", and the result is
>>> the empty string. This exception handler is in
>>> runtime/builtin/catch.pir, beginning at line 81. If I comment out the
>>> push_eh/pop_eh pair there, I get another segfault from the same bit of
>>> C code, although the path to get there is different.
>>>
>>> #0  0xb7b7a357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
>>>     at src/string.c:516
>>> #1  0xb7b9f69b in Parrot_concat_s_sc (cur_opcode=0xb7a8d7f4,
>>> interp=0x804f040)
>>>     at src/ops/string.ops:112
>>> #2  0xb7c213e4 in runops_slow_core (interp=0x804f040, pc=0xb7a8d7f4)
>>>     at src/runops_cores.c:221
>>> #3  0xb7bf39d6 in runops_int (interp=0x804f040, offset=3253)
>>>     at src/interpreter.c:929
>>> #4  0xb7bf42b3 in runops (interp=0x804f040, offs=3253) at
>>> src/inter_run.c:101
>>> #5  0xb7bf4550 in runops_args (interp=0x804f040, sub=0x843fde8,
>>> obj=0x809dac0,
>>>     meth_unused=0x0, sig=0xb7e53530 "vPS",
>>>     ap=0xbfd2010c "\füC\bÐÃG¶°­G\bH\001Ò¿Hÿ½·èýC\bÐÃG¶") at
>>> src/inter_run.c:223
>>> #6  0xb7bf468c in Parrot_runops_fromc_args (interp=0x804f040,
>>> sub=0x843fde8,
>>>     sig=0xb7e53530 "vPS") at src/inter_run.c:295
>>> #7  0xb7be052a in Parrot_ex_throw_from_c (interp=0x804f040,
>>>     exception=0x843fc0c) at src/exceptions.c:302
>>> #8  0xb7be05fe in Parrot_ex_throw_from_c_args (interp=0x804f040,
>>> ret_addr=0x0,
>>>     exitcode=20, format=0xb7e5689c "Class %Ss already registered!\n")
>>>     at src/exceptions.c:349
>>> #9  0xb7c14ac1 in fail_if_type_exists (interp=0x804f040,
>>> name=0x843fd5c)
>>>     at src/oo.c:632
>>> #10 0xb7c14b34 in Parrot_oo_register_type (interp=0x804f040,
>>> name=0x843fd5c)
>>>     at src/oo.c:662
>>> <SNIP>
>>>
>>>
>>>
>>
>> This is still occurring at revision 29555.
>> --
>> Will "Coke" Coleda
>>
>
> This is very likely due to the fact that tcl has its own set of
> opcodes for throwing exceptions that need to be updated to match,
> e.g., the "die" opcode in the new branch.
>
> --
> Will "Coke" Coleda
>

I committed a patch (r29559) that updates all the tcl.ops to be more
like the 'die' opcode in how the exception object is constructed and
created. Still segfaulting. As long as I'm in here, I'm going to
eliminate the forms of tcl_error that are now identical to 'die'.


-- 
Will "Coke" Coleda

Reply via email to