[perl #41035] [BUG] Parrot segfaults in perl6 08-regex.t (GC/pointer bug?)
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #41035] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41035 > --- osname= linux osvers= 2.6.16 arch= x86_64-linux-thread-multi cc= cc --- Flags: category=core severity=high ack=no --- Here's another segfault arising in the parrot core as a result of running perl6.pbc on a test file. This may or may not be related to RT #40966; I'm entering it as a separate ticket just in case the two are different. As before, the test works when the -G flag is present, but segfaults when it isn't. The problem appears in r15837: 1. build parrot 2. cd languages/perl6 3. make The core dump appears when running t/00-parrot/08-regex.t: $ ../../parrot perl6.pbc t/00-parrot/08-regex.t Segmentation fault (core dumped) It works fine if -G is present: $ ../../parrot -G perl6.pbc t/00-parrot/08-regex.t 1..11 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 The backtrace (complete copy below) shows a worrisome "0xdeadbeef": (gdb) backtrace #0 0xdeadbeef in ?? () #1 0x2ad8a1631762 in parrot_hash_put (interp=0x50c010, hash=0x2adcfcb0, key=0x2ad48f28, value=0x2adcfc10) at src/hash.c:850 #2 0x2ad8a1631af9 in parrot_hash_clone (interp=0x50c010, hash=0x754050, dest=0x2adcfcd8) at src/hash.c:967 #3 0x2ad8a16d56f1 in Parrot_Hash_clone (interp=0x50c010, pmc=0x2adcfd78) at src/pmc/hash.pmc:205 #4 0x2ad8a1561882 in Parrot_clone_p_p (cur_opcode=0x2acd0ab8, interp=0x50c010) at src/ops/set.ops:524 #5 0x2ad8a162b031 in runops_slow_core (interp=0x50c010, pc=0x2acd0ab8) at src/runops_cores.c:184 #6 0x2ad8a161314a in runops_int (interp=0x50c010, offset=137) at src/interpreter.c:775 #7 0x2ad8a1618a0e in runops (interp=0x50c010, offs=137) at src/inter_run.c:87 #8 0x2ad8a1618ca8 in runops_args (interp=0x50c010, sub=0x7e6c58, obj=0x550350, meth=0x0, sig=0x2ad8a17481b2 "vP", ap=0x7fff097c0110) at src/inter_run.c:193 #9 0x2ad8a1618e9b in Parrot_runops_fromc_args (interp=0x50c010, sub=0x7e6c58, sig=0x2ad8a17481b2 "vP") at src/inter_run.c:295 #10 0x2ad8a16391d8 in Parrot_runcode (interp=0x50c010, argc=2, argv=0x7fff097c0430) at src/embed.c:806 #11 0x004035a6 in main (argc=2, argv=0x7fff097c0430) at compilers/imcc/main.c:723 Thanks! Pm complete transcript including backtrace $ ../../parrot perl6.pbc t/00-parrot/08-regex.t Segmentation fault (core dumped) $ ../../parrot -G perl6.pbc t/00-parrot/08-regex.t 1..11 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 $ gdb ../../parrot core.15950 GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `../../parrot perl6.pbc t/00-parrot/08-regex.t'. Program terminated with signal 11, Segmentation fault. Reading symbols from /home/pmichaud/parrot/trunk/blib/lib/libparrot.so.0.4.7...done. Loaded symbols for /home/pmichaud/parrot/trunk/blib/lib/libparrot.so.0.4.7 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libpthread.so.0...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /lib64/librt.so.1...done. Loaded symbols for /lib64/librt.so.1 Reading symbols from /lib64/libreadline.so.5...done. Loaded symbols for /lib64/libreadline.so.5 Reading symbols from /lib64/libncurses.so.5...done. Loaded symbols for /lib64/libncurses.so.5 Reading symbols from /usr/lib64/libstdc++.so.6...done. Loaded symbols for /usr/lib64/libstdc++.so.6 Reading symbols from /lib64/libm.so.6...done. Loaded symbols for /lib64/libm.so.6 Reading symbols from /lib64/libgcc_s.so.1...done. Loaded symbols for /lib64/libgcc_s.so.1 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /home/pmichaud/parrot/trunk/runtime/parrot/dynext/perl6_group.so...done. Loaded symbols for /home/pmichaud/parrot/trunk/runtime/parrot/dynext/perl6_group.so #0 0xdeadbeef in ?? () (gdb) backtrace #0 0xdeadbeef in ?? () #1 0x2ad8a1631762 in parrot_hash_put (interp=0x50c010, hash=0x2adcfcb0, key=0
[perl #41032] [PATCH] Compiling Parrot with the new Borland C++
# New Ticket Created by Steve Peters
# Please include the string: [perl #41032]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41032 >
It took some tweaking to get some of the warnings shut off, but the
attached patch actually gets the files to compile, although it doesn't
actually build a parrot to test with. Expect a few more patches over the
next week to finish this off.
Steve Peters
[EMAIL PROTECTED]
--- parrot-old/src/pic.c2006-11-18 18:16:41.921875000 -0600
+++ parrot/src/pic.c2006-11-18 16:06:35.31250 -0600
@@ -83,7 +83,7 @@
# include "parrot/oplib/core_ops_cgp.h"
#endif
-#if HAS_JIT
+#ifdef HAS_JIT
#include "parrot/exec.h"
#include "jit.h"
#endif
@@ -484,7 +484,6 @@
is_pic_func(Interp *interp, void **pc, Parrot_MIC *mic, int core_type)
{
PMC *sub, *sig_args, *sig_results;
-char *base;
parrot_context_t *ctx;
opcode_t *op, n;
int flags;
@@ -507,7 +506,6 @@
* pc is at set_args
*/
-base = (char*)interp->ctx.bp.regs_i;
ctx = CONTEXT(interp->ctx);
sig_args = (PMC*)(pc[1]);
ASSERT_SIG_PMC(sig_args);
@@ -543,7 +541,6 @@
parrot_PIC_prederef(Interp *interp, opcode_t op, void **pc_pred, int core)
{
op_func_t * const prederef_op_func = interp->op_lib->op_func_table;
-char * const _reg_base = (char*)interp->ctx.bp.regs_i;
opcode_t * const cur_opcode = (opcode_t*)pc_pred;
Parrot_MIC *mic = NULL;
--- parrot-old/src/pic_jit.c2006-11-18 18:16:41.140625000 -0600
+++ parrot/src/pic_jit.c2006-11-18 16:08:04.765625000 -0600
@@ -38,7 +38,7 @@
# include "parrot/oplib/core_ops_cgp.h"
#endif
-#if HAS_JIT
+#ifdef HAS_JIT
#include "parrot/exec.h"
#include "jit.h"
@@ -261,7 +261,6 @@
{
opcode_t *base, *start, *end;
-STRING * const name = VTABLE_get_string(interp, sub);
*flags = 0;
--- parrot-old/src/mmd.c2006-11-18 18:16:43.859375000 -0600
+++ parrot/src/mmd.c2006-11-18 18:30:03.640625000 -0600
@@ -135,7 +135,7 @@
func = D2FPTR(PMC_struct_val(method));
*is_pmc = 0;
mmd_register(interp, func_nr, left_type, r,
-PMC_struct_val(method));
+(void (*)())PMC_struct_val(method));
}
else {
*is_pmc = 1;
[perl #41031] bad links in docs/ROADMAP.pod
# New Ticket Created by Will Coleda # Please include the string: [perl #41031] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41031 > -- Dead: http://feather.perl6.nl/~chip/Chip_APW.sxi -- Dead: http://feather.perl6.nl/~chip/Chip_APW.pdf -- Will "Coke" Coleda [EMAIL PROTECTED]
Re: KeySet, KeyBag and KeyHash typing
At 6:53 PM +0100 12/1/06, TSa wrote: HaloO Larry, you wrote: I think a consequence of this view is that (x) ops are all key-based set ops unless you explicitly make sure both sides are bags. But it's still early enough in the morning that I've not thought this through entirely... I understand that you want first of all 'KeyHash does Hash' and then we have three special key handling subtypes of Hash. They differ only in the value type. With Bit <: UInt <: Any and covariant container typing this yields KeySet <: KeyBag <: KeyHash <: Hash. And I still opt for Seq/List/Array entering the picture as subtypes of KeyBag because we loose no information then. The question is now how the mixed value case Bit and UInt from the respective KeySet and KeyBag types are handled. I think we should promote the Bit to an Uint and go for Bag operations. Note that Bag operations yield set semantics when fed with set data. The subtyping of KeyBag to KeyHash is a bit bogus because we loose Bag semantics in so far as the Any supertype of UInt is not a generalized multiplicity. That is KeyHash is more like KeySet but with arbitrary items indicating presence. Actuallly the Any type might support the needed min/max and +/- calls but I guess this is not what a user of a KeyHash would expect when she uses it as argument to the (x) ops. In the end it might be more practical to make Bag an interface subtype of Set that adds multiplicity of items that is dropped when mixed Set Bag (x) ops are used. This is where I started before Darren mentioned the Set <: Bag fact. Is that enough food for thought for later in the day? Tsa, I consider the current KeyHash|KeySet|KeyBag|Set|Bag etc in Synopsis 6 to be a good solution for users of sets and bags. I do not understand the rationale to make any further changes as you have described above. Please clarify benefits of what you are debating to change, maybe with use case examples. -- Darren Duncan
Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Am Donnerstag, 30. November 2006 01:20 schrieb Matt Diephouse:
> Matt Diephouse <[EMAIL PROTECTED]> wrote:
> > We've basically run into the fact that there's no spec for MMD. I'll
> > see if I can provide a patch that just makes "_" match native types,
> > but I think it'll be somewhat more involved than this one.
>
> It ended up being easier than expected -- implemented in r15910.
Looks good and works as expected.
BTW: the subject is a bit misleading, MMD and auto{un,}boxing are really
orthogonal, the former selects a sub depending on call argument types (and
available multis), the latter deals with argument passing to the one select
sub.
Great job, thanks
leo
Re: [perl #40998] [PATCH] Fix build error on Win32
OK, so no one seems interested.
Anyway, the attached patch in this message is a
better version of the previous one.
It checks for a white space in build_dir and makes the value
short path only when a space exists.
"Nikolay Ananiev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Ron Blaschke" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Nikolay Ananiev (via RT) wrote:
> > > # New Ticket Created by "Nikolay Ananiev"
> > > # Please include the string: [perl #40998]
> > > # in the subject line of all future correspondence about this issue.
> > > # http://rt.perl.org/rt3/Ticket/Display.html?id=40998 >
> >
> > > When build_dir contains spaces the build process fails.
> > > The fix is to translate build_dir to a short path name.
> >
> > In my opinion it would be better to escape/quote the relevant paths
> > properly. I think the short file names were introduced for backwards
> > compatibility, as a kludge. Besides, they are ugly to read. ;-)
> >
> > Ron
> >
>
> If we use quotes, we'll have to refactor some of the scripts in the build
> tree,
> because there are many concatenations and currently they won't work
> if we use quotes on build_dir. There's one more way. We can check
build_dir
> and use short path names only if there are spaces.
>
>
>
>
begin 666 win32build.patch
[EMAIL PROTECTED](&-O;F9I9R]I;FET+VAI;G1S+VUS=VEN,S(N<&T-"CT]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T-"BTM+2!C;VYF:6PI 0" M,C2 D8G5I;&1?9&ER(#T@)&-O;F8M/F1A=&$M/F=E="@G8G5I
M;&1?9&ER)RD["BL@(" @"BL@(" @:68H)&)U:6QD7V1I
Re: [perl #40815] Summary of 'make test' failures on Darwin
On Thursday 30 November 2006 20:25, Andy Bach wrote: > James Keenan via RT wrote: > > On Sat Nov 11 10:17:33 2006, [EMAIL PROTECTED] wrote: > >> perl Configure.pl --without-gmp --cc=gcc --ccflags='-fno-common -pipe > >> -I/usr/local/include -pipe -fno-common' > >> > >> Then chromatic suggested manually editing the Makefile to delete '- > >> bundle' from the following line. > >> LD_LOAD_FLAGS = -bundle -undefined suppress > > It appears (from google) that "-bundle" is a MacOS specific option to > their version of gcc's c++ (also Intel's MacOS c++) but, I'm guessing, > your version of c++, which is then treating the -bundle as -b undle or > somesuch. So, perhaps the MacOS guessing code needs to poke a tad > harder at the versions of gcc/c++ its getting its hands on. What's weirder to me is that Configure.pl picks up g++ as the linker while using cc as the compiler. I couldn't figure that out at the hackathon; something's definitely weird there. I think we opened a ticket asking for an override to specify "Link with gcc instead of g++", but I don't know the status of that. -- c
Re: KeySet, KeyBag and KeyHash typing
HaloO Larry, you wrote: I think a consequence of this view is that (x) ops are all key-based set ops unless you explicitly make sure both sides are bags. But it's still early enough in the morning that I've not thought this through entirely... I understand that you want first of all 'KeyHash does Hash' and then we have three special key handling subtypes of Hash. They differ only in the value type. With Bit <: UInt <: Any and covariant container typing this yields KeySet <: KeyBag <: KeyHash <: Hash. And I still opt for Seq/List/Array entering the picture as subtypes of KeyBag because we loose no information then. The question is now how the mixed value case Bit and UInt from the respective KeySet and KeyBag types are handled. I think we should promote the Bit to an Uint and go for Bag operations. Note that Bag operations yield set semantics when fed with set data. The subtyping of KeyBag to KeyHash is a bit bogus because we loose Bag semantics in so far as the Any supertype of UInt is not a generalized multiplicity. That is KeyHash is more like KeySet but with arbitrary items indicating presence. Actuallly the Any type might support the needed min/max and +/- calls but I guess this is not what a user of a KeyHash would expect when she uses it as argument to the (x) ops. In the end it might be more practical to make Bag an interface subtype of Set that adds multiplicity of items that is dropped when mixed Set Bag (x) ops are used. This is where I started before Darren mentioned the Set <: Bag fact. Is that enough food for thought for later in the day? Regards, TSa. --
Re: [perl #40815] Summary of 'make test' failures on Darwin
James Keenan via RT wrote: On Sat Nov 11 10:17:33 2006, [EMAIL PROTECTED] wrote: perl Configure.pl --without-gmp --cc=gcc --ccflags='-fno-common -pipe -I/usr/local/include -pipe -fno-common' Then chromatic suggested manually editing the Makefile to delete '- bundle' from the following line. LD_LOAD_FLAGS = -bundle -undefined suppress It appears (from google) that "-bundle" is a MacOS specific option to their version of gcc's c++ (also Intel's MacOS c++) but, I'm guessing, your version of c++, which is then treating the -bundle as -b undle or somesuch. So, perhaps the MacOS guessing code needs to poke a tad harder at the versions of gcc/c++ its getting its hands on. a -- Andy Bach, Sys. Mangler Internet: [EMAIL PROTECTED] VOICE: (608) 261-5738 FAX 264-5932 "Capital is only the fruit of labor. Labor is the superior of capital and deserves much the higher consideration." Abraham Lincoln, first annual address to Congress 1861
