Re: [perl #59886] Segfault in pcre.t
chromatic wrote: On Monday 13 October 2008 14:23:21 Moritz Lenz wrote: with r31926 the pcre.t tests fails due to a segfault: (gdb) run pcre.pir Starting program: /home/moritz/src/parrot/parrot pcre.pir [Thread debugging using libthread_db enabled] [New Thread -1232648512 (LWP 21873)] warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 00b4 ok 1 ok 2 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1232648512 (LWP 21873)] 0xb7d4881b in compact_pool (interp=0x90fd048, pool=0x90fda48) at src/gc/resources.c:475 475 memcpy(cur_spot, PObj_bufstart(b), PObj_buflen(b )); (gdb) bt #0 0xb7d4881b in compact_pool (interp=0x90fd048, pool=0x90fda48) at src/gc/resources.c:475 #1 0xb7d48a7d in Parrot_go_collect (interp=0x90fd048) at src/gc/resources.c:566 #2 0xb7beb984 in Parrot_dod_ms_run (interp=0x90fd048, flags=1) at src/gc/dod.c:1137 #3 0xb7beba9a in Parrot_do_dod_run (interp=0x90fd048, flags=1) at src/gc/dod.c:1190 #4 0xb7bed4f8 in more_traceable_objects (interp=0x90fd048, pool=0x911db68) at src/gc/smallobject.c:163 #5 0xb7bed5da in gc_ms_get_free_object (interp=0x90fd048, pool=0x911db68) at src/gc/smallobject.c:245 #6 0xb7bf03ac in get_free_buffer (interp=0x90fd048, pool=0x911db68) at src/headers.c:101 This is on Debian 4.0 Etch, 32 bit. I can't reproduce this; are you still seeing it? Yes (r31936). Which version of pcre do you have installed? ii libpcre3 6.7+7.4-4 Perl 5 Compatible Regular Expression Library -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [perl #59544] open(null) kills parrot
NotFound wrote: Where to put a test for this? There is no t/ops/io.t and creating a file for each io opcode seems excessive Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one on the list, which I'll create a branch for later this week). Allison
Re: [perl #59658] Build failure in src/pmc/float.c -- non-constant intiializer
On Tue, Oct 14, 2008 at 7:23 AM, Andy Dougherty [EMAIL PROTECTED] wrote: On Sat, 11 Oct 2008, Allison Randal via RT wrote: jerry gay wrote: .\src\pmc\float.c(3340) : warning C4204: nonstandard extension used : non-constant aggregate initializer there are now hundreds of these warnings in that build. we do have warnings ratcheted up pretty high, but i don't think it's worth relaxing them for this construct unless it's very difficult to change the code generator--i assume this is generated code, since it's in so many pmc .c files. i may get a chance to investigate further this evening, if somebody hasn't beaten me to it. Yes, that's generated code, it's part of the initialization of MULTIs declared in a PMC. I was hoping to avoid all those C strings. But, try r31879. Yes, that works fine. works fine here, too. thanks. ~jerry
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
On Monday 13 October 2008 16:15:54 chromatic wrote:
That's pretty clearly not a PMC. Can you use the breakpoint
technique to figure out 1) What creates this CPointer PMC and
In the following dump, the offending PMC ix 0x1731de8. The arena's base
pointer varies every time, but I seem to be able to catch it with a
pointer suffix check.
Breakpoint 3, Parrot_CPointer_init (interp=0x1f99080, pmc=0x20f3de8)
at ./src/pmc/cpointer.pmc:67
67 mem_allocate_typed(Parrot_CPointer_attributes);
(gdb) bt
#0 Parrot_CPointer_init (interp=0x1f99080, pmc=0x20f3de8)
at ./src/pmc/cpointer.pmc:67
#1 0x7fa669216be0 in pmc_new (interp=0x1f99080, base_type=52)
at src/pmc.c:93
#2 0x7fa6691dfe74 in Parrot_build_sig_object_from_varargs (
interp=0x1f99080, sig=0x7fa66944bb33 PPP-P, args=0x7fff71a10230)
at src/multidispatch.c:477
#3 0x7fa6691e05c6 in Parrot_mmd_multi_dispatch_from_c_args (
interp=0x1f99080, name=0x7fa66944c310 modulus,
sig=0x7fa66944bb33 PPP-P) at src/multidispatch.c:574
#4 0x7fa6692c159f in Parrot_default_modulus (interp=0x1f99080,
pmc=0x20f3f00, value=0x2072a08, dest=0x2071e70)
at ./src/pmc/default.pmc:1673
#5 0x7fa669172af8 in Parrot_mod_p_p_p (cur_opcode=0x20f36a0,
interp=0x1f99080) at src/ops/math.ops:760
#6 0x7fa669217c2f in runops_slow_core (interp=0x1f99080,
pc=0x20f36a0)
at src/runops_cores.c:222
#7 0x7fa6691d7ed4 in runops_int (interp=0x1f99080, offset=0)
at src/interpreter.c:937
#8 0x7fa6691d88c3 in runops (interp=0x1f99080, offs=0)
at src/inter_run.c:101
#9 0x7fa6691d8b7a in runops_args (interp=0x1f99080, sub=0x20738b0,
obj=0x2026020, meth_unused=0x0, sig=0x7fa669442cfb vP,
ap=0x7fff71a10500)
at src/inter_run.c:236
#10 0x7fa6691d8d6b in Parrot_runops_fromc_args (interp=0x1f99080,
sub=0x20738b0, sig=0x7fa669442cfb vP) at src/inter_run.c:300
#11 0x7fa6691ba81e in Parrot_runcode (interp=0x1f99080, argc=1,
argv=0x7fff71a107e0) at src/embed.c:951
#12 0x7fa66941bf38 in imcc_run_pbc (interp=0x1f99080, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff71a107e0) at
compilers/imcc/main.c:791
#13 0x7fa66941c837 in imcc_run (interp=0x1f99080,
sourcefile=0x7fff71a11165 t/op/bitwise_27.pir, argc=1,
argv=0x7fff71a107e0) at compilers/imcc/main.c:1079
#14 0x00400c64 in main (argc=1, argv=0x7fff71a107e0) at
src/main.c:61
(gdb) cont
Continuing.
Breakpoint 4, Parrot_CPointer_set_pointer (interp=0x1f99080,
pmc=0x20f3de8,
value=0x7fff71a10358) at ./src/pmc/cpointer.pmc:167
167 Parrot_CPointer_attributes * const data =
PARROT_CPOINTER(SELF);
(gdb) bt
#0 Parrot_CPointer_set_pointer (interp=0x1f99080, pmc=0x20f3de8,
value=0x7fff71a10358) at ./src/pmc/cpointer.pmc:167
#1 0x7fa6691e0189 in Parrot_build_sig_object_from_varargs (
interp=0x1f99080, sig=0x7fa66944bb33 PPP-P, args=0x7fff71a10230)
at src/multidispatch.c:497
#2 0x7fa6691e05c6 in Parrot_mmd_multi_dispatch_from_c_args (
interp=0x1f99080, name=0x7fa66944c310 modulus,
sig=0x7fa66944bb33 PPP-P) at src/multidispatch.c:574
#3 0x7fa6692c159f in Parrot_default_modulus (interp=0x1f99080,
pmc=0x20f3f00, value=0x2072a08, dest=0x2071e70)
at ./src/pmc/default.pmc:1673
#4 0x7fa669172af8 in Parrot_mod_p_p_p (cur_opcode=0x20f36a0,
interp=0x1f99080) at src/ops/math.ops:760
#5 0x7fa669217c2f in runops_slow_core (interp=0x1f99080,
pc=0x20f36a0)
at src/runops_cores.c:222
#6 0x7fa6691d7ed4 in runops_int (interp=0x1f99080, offset=0)
at src/interpreter.c:937
#7 0x7fa6691d88c3 in runops (interp=0x1f99080, offs=0)
at src/inter_run.c:101
#8 0x7fa6691d8b7a in runops_args (interp=0x1f99080, sub=0x20738b0,
obj=0x2026020, meth_unused=0x0, sig=0x7fa669442cfb vP,
ap=0x7fff71a10500)
at src/inter_run.c:236
#9 0x7fa6691d8d6b in Parrot_runops_fromc_args (interp=0x1f99080,
sub=0x20738b0, sig=0x7fa669442cfb vP) at src/inter_run.c:300
#10 0x7fa6691ba81e in Parrot_runcode (interp=0x1f99080, argc=1,
argv=0x7fff71a107e0) at src/embed.c:951
#11 0x7fa66941bf38 in imcc_run_pbc (interp=0x1f99080, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff71a107e0) at
compilers/imcc/main.c:791
#12 0x7fa66941c837 in imcc_run (interp=0x1f99080,
sourcefile=0x7fff71a11165 t/op/bitwise_27.pir, argc=1,
argv=0x7fff71a107e0) at compilers/imcc/main.c:1079
#13 0x00400c64 in main (argc=1, argv=0x7fff71a107e0) at
src/main.c:61
(gdb) print *pmc
$3 = {cache = {_b = {_bufstart = 0x20f3db0, _buflen = 0}, _ptrs = {
_struct_val = 0x20f3db0, _pmc_val = 0x0}, _i = {_int_val =
34553264,
_int_val2 = 0}, _num_val = 1.7071580694083094e-316,
_string_val = 0x20f3db0}, flags = 72353280, vtable = 0x1ffbf30,
data = 0x2135c00, pmc_ext = 0x2125418, real_self = 0x20f3de8}
(gdb) print *((Parrot_CPointer_attributes *) 0x2135c00)
$4 = {pointer = 0x7fff71a10358, sig = 0x0}
2) What's setting an invalid
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
On Tuesday 14 October 2008 07:14:51 Mark Glines wrote: On Monday 13 October 2008 16:15:54 chromatic wrote: That's pretty clearly not a PMC. Can you use the breakpoint technique to figure out 1) What creates this CPointer PMC and In the following dump, the offending PMC ix 0x1731de8. The arena's base pointer varies every time, but I seem to be able to catch it with a pointer suffix check. Yes, I'm an idiot. I meant 0x20f3de8 of course. I've run through this several times, and like I said, it keeps changing... Breakpoint 3, Parrot_CPointer_init (interp=0x1f99080, pmc=0x20f3de8) -- Mark
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, Oct 13, 2008 at 09:30:33PM -0700, chromatic via RT wrote: On Mon Oct 06 12:15:49 2008, doughera wrote: Trying to compile today's parrot on an up-to-date version of OpenSolaris: SunOS xxx 5.11 snv_98 i86pc i386 i86pc Solaris it failed (after a while) with the following error: perl tools/build/pmc2c.pl --vtable Storable version 2.13 required--this is only version 2.12 at /export/home/doughera/src/parrot/parrot- cc/tools/build/../../lib/Parrot/Pmc2c/Pmc2cMain.pm line 6. BEGIN failed--compilation aborted at /export/home/doughera/src/parrot/parrot- cc/tools/build/../../lib/Parrot/Pmc2c/Pmc2cMain.pm line 6. Compilation failed in require at tools/build/pmc2c.pl line 10. BEGIN failed--compilation aborted at tools/build/pmc2c.pl line 10. make: *** [vtable.dump] Error 2 The problem is that OpenSolaris ships with (a patched version of) perl-5.8.4. I'm not sure why OpenSolaris is still shipping perl- 5.8.4, but they are. I haven't looked at tools/build/pmc2c.pl at all to see why Storable 2.13 is required, nor at how large of a burden it would be to relax that requirement. Such digging would take more time than I have available at the moment. If I remember correctly, Storable 2.12 and earlier did not restore overloading properly. Storable's changelog suggests that version 2.18 compiles properly on older versions of Perl; if it works with Perl 5.8.4 All versions on CPAN should build back to 5.004, without test failures. That's probably a bit more than you need. :-) in OpenSolaris, we could keep the dependency on 5.8.1 (or whatever) and increase the Storable dependency to 2.18. I infer from the quoted message above that bumping the dependency to 2.13 would work as well, but wouldn't cause a lot of other people who have 2.13 to 2.17 installed to need to upgrade. Nicholas Clark
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, 13 Oct 2008, chromatic via RT wrote: On Mon Oct 06 12:15:49 2008, doughera wrote: Trying to compile today's parrot on an up-to-date version of OpenSolaris: SunOS xxx 5.11 snv_98 i86pc i386 i86pc Solaris it failed (after a while) with the following error: perl tools/build/pmc2c.pl --vtable Storable version 2.13 required--this is only version 2.12 at The problem is that OpenSolaris ships with (a patched version of) perl-5.8.4. I'm not sure why OpenSolaris is still shipping perl- 5.8.4, but they are. I haven't looked at tools/build/pmc2c.pl at all to see why Storable 2.13 is required, nor at how large of a burden it would be to relax that requirement. Such digging would take more time than I have available at the moment. If I remember correctly, Storable 2.12 and earlier did not restore overloading properly. Storable's changelog suggests that version 2.18 compiles properly on older versions of Perl; if it works with Perl 5.8.4 in OpenSolaris, we could keep the dependency on 5.8.1 (or whatever) and increase the Storable dependency to 2.18. Storable 2.18 builds and tests fine on OpenSolaris. (So do perl-5.8.8 and perl-5.8.9-to-be.) On the other hand, changing the requirement in lib/Parrot/Pmc2c/Pmc2cMain.pm to Storable 2.12 instead of 2.13, and then building with Storable 2.12, also seems to work. That is, there are no significant differences between the generated files. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Tue, 14 Oct 2008, Nicholas Clark wrote: I infer from the quoted message above that bumping the dependency to 2.13 would work as well, but wouldn't cause a lot of other people who have 2.13 to 2.17 installed to need to upgrade. That's, in fact, what parrot currently requires: 2.13. However, if you only have 2.12 and go to CPAN to upgrade, you'll end up with 2.18, which is what chromatic was referring to. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59544] open(null) kills parrot
Where to put a test for this? There is no t/ops/io.t and creating a file for each io opcode seems excessive Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one on the list, which I'll create a branch for later this week). Created and added open null tests in r31950 -- Salu2
Re: [perl #59658] Build failure in src/pmc/float.c -- non-constant intiializer
On Sat, 11 Oct 2008, Allison Randal via RT wrote: jerry gay wrote: .\src\pmc\float.c(3340) : warning C4204: nonstandard extension used : non-constant aggregate initializer there are now hundreds of these warnings in that build. we do have warnings ratcheted up pretty high, but i don't think it's worth relaxing them for this construct unless it's very difficult to change the code generator--i assume this is generated code, since it's in so many pmc .c files. i may get a chance to investigate further this evening, if somebody hasn't beaten me to it. Yes, that's generated code, it's part of the initialization of MULTIs declared in a PMC. I was hoping to avoid all those C strings. But, try r31879. Yes, that works fine. Thanks, -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59784] [PATCH] Enhancement : support for multiple optables in PGE
I'm a little reluctant to commit to any specific modifications to optables at the moment because much of this will be significantly refactored in the relatively near future as part of implementing protoregexes and longest token matching into PGE. As that's being done, I suspect we may discover a far superior mechanism for handling optables in general, including allowing multiple optables. I'm also not a fan of having proto subs (i.e., the operator token definitions) place themselves into the most recently defined optable. That sounds quite fragile, and it goes against the Perl 6 semantics that the grammar files are intended to be following. I do like the idea that the name of the $optable variable is based on the rulename, though -- that's definitely a step in the right direction. If we can come up with a better mechanism for associating operator tokens with the correct optable, then perhaps we should go with that. The ultimate answer will be to use protoregexes and categories, as STD.pm is currently doing. An intermediate answer might be to have an is optable trait for proto subs that can specify an optable to use other than the default. (Ideally the equiv/tighter/looser traits would also tie a new token to the optable of whatever it's being defined in relation to.) In particular, I don't want to provide too many new structures/ features that we may want to turn around and quickly deprecate when protoregexes come into play. Pm
[perl #59898] [TODO][IMCC] add some #define's to fix the inconsistent dll linkage on windows
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #59898] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59898 hi, In order to fix the 'inconsistent dll linkage' errors on windows (and also the warnings during compiling the parser/lexer of imcc), 2 defines must be added. These are: #define YYMALLOC #define YYFREE These must occur /before/ #including imclexer.h in imcc.y This is an easy, low-hanging-fruit kind of job (but no time now to do it myself). kjs
Re: [perl #59898] [TODO][IMCC] add some #define's to fix the inconsistent dll linkage on windows
On Tuesday 14 October 2008 02:14:24 Klaas-Jan Stol wrote: In order to fix the 'inconsistent dll linkage' errors on windows (and also the warnings during compiling the parser/lexer of imcc), 2 defines must be added. These are: #define YYMALLOC #define YYFREE These must occur /before/ #including imclexer.h in imcc.y I don't have an imclexer.h file, but does this patch do the trick? -- c === compilers/imcc/imcc.y == --- compilers/imcc/imcc.y (revision 31991) +++ compilers/imcc/imcc.y (local) @@ -22,13 +22,14 @@ #include imc.h #include parrot/dynext.h #include pbc.h -#include parser.h -#include optimizer.h /* prevent declarations of malloc() and free() in the generated parser. */ #define YYMALLOC #define YYFREE +#include parser.h +#include optimizer.h + #ifndef YYENABLE_NLS # define YYENABLE_NLS 0 #endif
[perl #59898] [TODO][IMCC] add some #define's to fix the inconsistent dll linkage on windows
fixed in r31956
