[perl #54110] [BUG] segfault in infix/n_infix with string arguments
On Tue Sep 09 15:06:38 2008, [EMAIL PROTECTED] wrote: Patrick R. Michaud wrote: Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. Yes. That is, calling 'add', 'sub', etc. will now create a new PMC for the result on all the builtin PMCs. But, HLL/application developers will have the option of writing their own PMCs that reuse the destination PMC instead of a creating a new one. [...] This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. Yes, these string variants only existed because of the unintelligent way the infix/n_infix opcodes blindly redispatched. In the branch, where the math opcodes are real opcodes, there are no string variants and we're not adding them. So, ticket can be reclassified as irrelevant. Allison In that case it's rejected.
Re: [perl #54110] [BUG] segfault in infix/n_infix with string arguments
On Fri, Sep 05, 2008 at 05:20:45PM -0700, Christoph Otto via RT wrote: On Tue, May 13, 2008 at 9:48 AM, via RT Patrick R. Michaud The infix and n_infix opcodes cause segfaults when invoked with string arguments. (Kubuntu 8.04, x86, r27472) $ cat z.pir .sub main :main $P0 = new 'Float' $P0 = 3 n_mul $P1, $P0, 4 say $P1# 12 .end $ ./parrot z.pir Segmentation fault $ Is this bug going to continue to be relevant, since the pdd27mmd branch has removed the n_* opcodes (and presumably trunk will too after the branch is merged back)? Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. So, trying the above code in the pdd27mmd branch (and changing the 'n_mul' to 'mul'), I now get: $ cat x.pir .sub main :main $P0 = new 'Float' $P0 = 3 mul $P1, $P0, '4' say $P1# 12 .end $ ./parrot x.pir error:imcc:The opcode 'mul_p_p_sc' (mul3) was not found. Check the type and number of the arguments in file 'x.pir' line 5 $ This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. If they're not going away, then this ticket is still relevant. It would also be relevant because Parrot trunk fails on the non-n_ versions of the opcodes in the same way: $ cat x.pir .sub main :main $P0 = new 'Float' $P0 = 3 $P1 = new 'Float' mul $P1, $P0, '4' say $P1# 12 .end $ ./parrot x.pir Segmentation fault Pm
Re: [perl #54110] [BUG] segfault in infix/n_infix with string arguments
Patrick R. Michaud wrote: Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. Yes. That is, calling 'add', 'sub', etc. will now create a new PMC for the result on all the builtin PMCs. But, HLL/application developers will have the option of writing their own PMCs that reuse the destination PMC instead of a creating a new one. [...] This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. Yes, these string variants only existed because of the unintelligent way the infix/n_infix opcodes blindly redispatched. In the branch, where the math opcodes are real opcodes, there are no string variants and we're not adding them. So, ticket can be reclassified as irrelevant. Allison
[perl #54110] [BUG] segfault in infix/n_infix with string arguments
On Tue May 13 08:05:08 2008, coke wrote: On Tue, May 13, 2008 at 9:48 AM, via RT Patrick R. Michaud [EMAIL PROTECTED] wrote: # New Ticket Created by Patrick R. Michaud # Please include the string: [perl #54110] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=54110 The infix and n_infix opcodes cause segfaults when invoked with string arguments. (Kubuntu 8.04, x86, r27472) Here's an example: $ cat z.pir .sub main :main $P0 = new 'Float' $P0 = 3 n_mul $P1, $P0, 4 say $P1# 12 .end $ ./parrot z.pir Segmentation fault $ Pm Doing some digging: This code (String pmc instead of STRING register) generates the expected result: .sub main :main $P0 = new 'Float' $P0 = 3 $P2 = new 'String' $P2 = 4 n_mul $P1, $P0, $P2 say $P1# 12 .end And here's the backtrace on the original code: #0 0x in ?? () #1 0xb7dedd1e in Parrot_Integer_multiply (interp=0x804f040, pmc=0x82313f8, value=0x81fba7c, dest=0x0) at ./src/pmc/integer.pmc:605 #2 0xb7c773e3 in mmd_dispatch_p_psp (interp=0x804f040, left=0x82313f8, right=0x81fba7c, dest=0x0, func_nr=4) at src/mmd.c:569 #3 0xb7c0b684 in Parrot_n_infix_ic_p_p_sc (cur_opcode=0x82490b0, interp=0x804f040) at src/ops/math.ops:102 #4 0xb7c9eef4 in runops_slow_core (interp=0x804f040, pc=0x82490b0) at src/runops_cores.c:221 #5 0xb7c704d6 in runops_int (interp=0x804f040, offset=0) at src/interpreter.c:918 #6 0xb7c70e07 in runops (interp=0x804f040, offs=0) at src/inter_run.c:106 #7 0xb7c71096 in runops_args (interp=0x804f040, sub=0x82317b0, obj=0x8096090, meth_unused=0x0, sig=0xb7ecda37 vP, ap=0xbfb1ba6c \224\027#\b¨º±¿P\fø·Ðò\004\b\224\027#\b°\027#\b|[EMAIL PROTECTED]) at src/inter_run.c:232 #8 0xb7c711cc in Parrot_runops_fromc_args (interp=0x804f040, sub=0x82317b0, sig=0xb7ecda37 vP) at src/inter_run.c:301 #9 0xb7c59de7 in Parrot_runcode (interp=0x804f040, argc=1, argv=0xbfb1bbd8) at src/embed.c:943 #10 0xb7ea9f92 in imcc_run_pbc (interp=0x804f040, obj_file=0, output_file=0x0, argc=1, argv=0xbfb1bbd8) at compilers/imcc/main.c:783 #11 0xb7eaa982 in imcc_run (interp=0x804f040, sourcefile=0xbfb1c9dd z.pir, ... Is this bug going to continue to be relevant, since the pdd27mmd branch has removed the n_* opcodes (and presumably trunk will too after the branch is merged back)? Christoph
[perl #54110] [BUG] segfault in infix/n_infix with string arguments
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #54110] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=54110 The infix and n_infix opcodes cause segfaults when invoked with string arguments. (Kubuntu 8.04, x86, r27472) Here's an example: $ cat z.pir .sub main :main $P0 = new 'Float' $P0 = 3 n_mul $P1, $P0, 4 say $P1# 12 .end $ ./parrot z.pir Segmentation fault $ Pm
Re: [perl #54110] [BUG] segfault in infix/n_infix with string arguments
On Tue, May 13, 2008 at 9:48 AM, via RT Patrick R. Michaud [EMAIL PROTECTED] wrote: # New Ticket Created by Patrick R. Michaud # Please include the string: [perl #54110] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=54110 The infix and n_infix opcodes cause segfaults when invoked with string arguments. (Kubuntu 8.04, x86, r27472) Here's an example: $ cat z.pir .sub main :main $P0 = new 'Float' $P0 = 3 n_mul $P1, $P0, 4 say $P1# 12 .end $ ./parrot z.pir Segmentation fault $ Pm Doing some digging: This code (String pmc instead of STRING register) generates the expected result: .sub main :main $P0 = new 'Float' $P0 = 3 $P2 = new 'String' $P2 = 4 n_mul $P1, $P0, $P2 say $P1# 12 .end And here's the backtrace on the original code: #0 0x in ?? () #1 0xb7dedd1e in Parrot_Integer_multiply (interp=0x804f040, pmc=0x82313f8, value=0x81fba7c, dest=0x0) at ./src/pmc/integer.pmc:605 #2 0xb7c773e3 in mmd_dispatch_p_psp (interp=0x804f040, left=0x82313f8, right=0x81fba7c, dest=0x0, func_nr=4) at src/mmd.c:569 #3 0xb7c0b684 in Parrot_n_infix_ic_p_p_sc (cur_opcode=0x82490b0, interp=0x804f040) at src/ops/math.ops:102 #4 0xb7c9eef4 in runops_slow_core (interp=0x804f040, pc=0x82490b0) at src/runops_cores.c:221 #5 0xb7c704d6 in runops_int (interp=0x804f040, offset=0) at src/interpreter.c:918 #6 0xb7c70e07 in runops (interp=0x804f040, offs=0) at src/inter_run.c:106 #7 0xb7c71096 in runops_args (interp=0x804f040, sub=0x82317b0, obj=0x8096090, meth_unused=0x0, sig=0xb7ecda37 vP, ap=0xbfb1ba6c \224\027#\b¨º±¿P\fø·Ðò\004\b\224\027#\b°\027#\b|[EMAIL PROTECTED]) at src/inter_run.c:232 #8 0xb7c711cc in Parrot_runops_fromc_args (interp=0x804f040, sub=0x82317b0, sig=0xb7ecda37 vP) at src/inter_run.c:301 #9 0xb7c59de7 in Parrot_runcode (interp=0x804f040, argc=1, argv=0xbfb1bbd8) at src/embed.c:943 #10 0xb7ea9f92 in imcc_run_pbc (interp=0x804f040, obj_file=0, output_file=0x0, argc=1, argv=0xbfb1bbd8) at compilers/imcc/main.c:783 #11 0xb7eaa982 in imcc_run (interp=0x804f040, sourcefile=0xbfb1c9dd z.pir, ... -- Will Coke Coleda
