[perl #59940] [patch] convert perl tests to parrot
On Thu Oct 23 01:38:59 2008, mgrimes wrote: Christoph, Thanks for your help. This has been a great, low intensity, way to learn a bit of parrot. I think I have addressed everything, and I have attached a new patch. The patch no longer applies cleanly to objects.t, and I thought it'd be better to let you merge the recent changes from svn and add the .pcc_sub Looks like there were just a few changes to spacing. This patch applied cleanly to version 32115. I added the .pcc_sub tests to objects.t. It's a good idea to test for exception types rather than exact messages. This keeps the tests passing if the wording of the message is changed. The exception type is much more likely to remain constant. This recommended but not a blocker. I wanted to keep the changes to the code down to a minimum, so I was reluctant to add ExecptionHandler objects. If there is a simpler way (ie, testing with typeof, etc), I would be happy to look into changing it. Test messages for shouldn't be blank. If a test fails, it should be fairly Oops. Got a bit ahead of myself with complex.t. Messages have been added. This is a minor nit, but -ve and +ve generally expand to negative and Ah... should have known. Thanks. Again, thanks for working on this. Happy to help. Thanks to you and the rest of the team for doing the heavy lifting! -Mark Good times. I changed the register names to use the $P0 format, switched a few tests to isa_ok and made some minor changes (description updates, removing unneeded code/comments). The getting_null_attribute test was only throwing an exception because the old version was trying to print a null PMC. It tests nullness more sanely now. The exception-throwing tests are a little more defensive now. This doesn't matter when they pass but should make debugging easier if they ever fail. pmichaud confirmed that the typeof_class test tests the right thing, so I enabled that one too. Apart from those (mostly cosmetic) changes, the patch was good. It was committed as r32145 and r32149 after I checked that everything was sane and no tests got dropped in the conversion. Thanks.
[perl #59940] [patch] convert perl tests to parrot
On Thu Oct 16 17:43:28 2008, mgrimes wrote: Hi, The attached patch converts two perl based tests into parrot tests: t/pmc/string.t t/pmc/objects.t Each of these included pir_error_is type tests. I am not aware of any way to test those within parrot right now, so I kept them in perl tests and move them to t/pmc/string-errors.t and t/pmc/objects-errors.t. Converting these test to pir dropped their run time from 19 secs to 3 secs, and more than 2 of those seconds are spent in the *-errors.t tests. Unfortunately, I ran into a small issue applying the patch. Since I am changing lines near the # $Id:$ line, svn diff creates a patch that doesn't apply cleanly. The following one liner will clean up the $Id: line, so the patch applies cleanly. $ perl -i.bak -pe's/# \$Id: .*$/# \$Id\$/' t/pmc/string.t t/pmc/objects.t If there is a better way to make the patch, please let me know. Thanks, Mark You can fix the foo_error_bar tests by using an exception handler to catch the (appropriate type of) exception. The simplest way is to use push_eh with a label. If the exception is raised, control will jump to that label. t/pmc/resizablestringarray.t uses this style. The more fine-grained approach is to use an ExceptionHandler PMC. t/pmc/ro.t uses this style. This lets you set the types and min/max severity that the eh will handle and resume execution. t/pmc/exceptionhandler.t has some nice examples. Thanks for rewriting those two tests. I thought about tackling them when I was on my PIRifying binge, but I didn't have nearly enough patience at the time.
[perl #59686] [CAGE] Review t/pmc/ro.t - improve error testing
On Tue Oct 07 06:53:58 2008, [EMAIL PROTECTED] wrote: In fixing the Complex PMC in r31749, I revealed a problem in our read-only PMC tests. In t/pmc/ro.t, test 5 gets an error as expected, but the error it gets complains that add_p_ic_p doesn't exist (it hasn't existed for years, if ever). So, test 5 isn't actually testing anything useful. I'm a bit suspicious about the whole test file now, because it's not testing for the actual text of the error message, it's just testing that it got *some* error. The cage task is to review the test file and improve the error testing, so that if the read-only error is masked by some other error, the tests will fail. One possible direction is to use exception handlers to trap the read-only exceptions inside the tests, instead of just relying on the exit code. Allison Most of the tests are rewritten in r31997 so that only the appropriate exception types are caught. I also split the ROTest tests into a separate file in src/dynpmc/rotest.t so t/distro/test_file_coverage.t would be happy (r32001,2). Rewriting the tests uncovered a couple errors in the tests themselves. All these have been resolved to both correctly test ro functionality and pass (unless I'm missing a subtlety). The last test in t/pmc/ro.t needs a look, but it has a separate ticket. I'm marking this one resolved.
[perl #44457] [TODO] make sure files match test files for DYNPMCs and DYNOPs etc
On Mon Oct 13 07:31:30 2008, [EMAIL PROTECTED] wrote: Hi Christoph, I send you the patch atached. The script with TODO block works equal without it(with TODO gives more information and adds the not yet implemented leyend). Sincerely, Igor Hi Igor, This patch looks good. There's no need to make sure that every .t file has a matching .pmc or .ops file, so I took that code and those tests out. Other than that and a minor codingstd fix, the patch looks good. I've applied it and committed it as r31964. Thanks for contributing. I hope this will be the first of many contributions from you. Christoph PS: The commit can be viewed at http://www.parrotvm.org/svn/parrot/revision?rev=31964 .
[perl #52778] [RFC] Are resizable arrays too Perlish?
On Sun Sep 14 13:43:15 2008, cotto wrote: On Sun Sep 14 07:47:34 2008, pmichaud wrote: On Sun, Sep 14, 2008 at 12:41:42AM -0700, Christoph Otto via RT wrote: I got impatient and committed this as r31101. I'm marking this ticket as resolved. According to [1], r31101 causes Rakudo to stop building with the following error: $ make ../../parrot /home/pmichaud/parrot/trunk/runtime/parrot/library/PGE/Perl6Grammar.pbc \ --output=src/gen_grammar.pir \ src/parser/grammar.pg src/parser/grammar-oper.pg ../../parrot /home/pmichaud/parrot/trunk/compilers/nqp/nqp.pbc --output=src/gen_actions.pir \ --encoding=fixed_8 --target=pir src/parser/actions.pm Null PMC access in get_bool() current instr.: 'parrot;NQP::Grammar::Actions;routine_def' pc 33982 (src/Grammar/Actions.pir:403) called from Sub 'parrot;NQP::Grammar;routine_def' pc 20036 (src/Grammar_gen.pir:7553) called from Sub 'parrot;NQP::Grammar;noun' pc 25828 (src/Grammar_gen.pir:9806) called from Sub 'parrot;NQP::Grammar;term' pc 22730 (src/Grammar_gen.pir:8622) called from Sub 'parrot;PGE::OPTable;parse' pc 1959 (compilers/pge/PGE/OPTable.pir:554) [...] As a temporary fix, Reini Urban reverted parts of the r31101 patch in r31108. I've traced the problem back to NQP; it was testing a value retrieved from a ResizablePMCArray for truth without first checking it for PMCNULL. I've since fixed that part of NQP (r31115). However, this does point out that there may be other languages and tools in Parrot that likewise depend on the old behavior of the various *Array types, so I'm reopening this ticket until all of those have been tested. In fact, it may be that we should revert r31101 entirely and go through a complete deprecation cycle before changing the behaviors of the core Array types in this manner, in case there are other libraries or languages depending on it. Pm 1. http://groups.google.com/group/perl.perl6.internals/msg/2cd7d9ede7a3cd4e I've completely reverted r31101 in r31124 so this behavior change can go through the deprecation cycle. I also added a note to DEPRECATED.pod in r31134. I've re-committed the patch in r31968. If it messes anything up (again) this ticket can be reopened, but I'm resolving it for now.
[perl #52478] [BUG] unwanted string - int conversion for array-like PMCs
On Tue Apr 08 19:11:10 2008, pmichaud wrote: On Fri, Apr 04, 2008 at 02:15:26PM -0700, Christoph Otto (Volt) wrote: When running the following PIR code, Parrot does the Perlish thing and implicitly converts s to an int. This violates the principle of least surprise and makes it unnecessarily difficult to test whether an element exists within an array. It would be much more logical if the array-like PMCs threw an exception in this circumstance. .sub _main .local pmc a .local string s a = new 'ResizablePMCArray' a['foo'] = 'stuff' s = a['bar'] print s #prints 'stuff' s = a[0] print s #prints 'stuff' print \n .end What about the case of ... ? .sub _main .local pmc a .local pmc s s = new 'String' s = 'foo' a = new 'ResizablePMCArray' a[s] = 'stuff' $S0 = a[0] say $S0 # prints stuff\n .end It seems to me that whatever we do with String PMCs as keys we should also do with string registers. In this case it means numifying the string (just as we would any PMC key). As far as testing for existence of an element, that should probably be some special behavior attached to the exists_p_s opcode as opposed to a set_* opcode. Pm Sounds good to me. Resolved.
[perl #59782] [PATCH] add pmc_cmp VTABLE function
On Sat Oct 11 05:07:25 2008, [EMAIL PROTECTED] wrote: Christoph Otto (via RT) wrote: In response to a question about comparison operators in Pipp*, Allison suggested that I add a variant cmp VTABLE function which returns a PMC instead of an INTVAL. This patch adds such a function, named pmc_cmp. It's named pmc_cmp rather than cmp_pmc to try to avoid confusion with the other cmp_* functions, since the type name in this function name refers to the return type rather than the argument type. Hmmm... we don't use that convention anywhere else (putting the type first to indicate that it's a return type, rather than an argument type). The closest we come is the 'get' and 'set' vtable functions which are 'get_returntype_keyed_argumenttype'. The 'shift' and 'pop' vtable functions both use 'shift_pmc' and 'pop_pmc' to indicate that the return type is a PMC. So, let's stick with 'cmp_pmc' for this one. Otherwise, thumbs up, looks great! Allison This was committed (with the recommended change) in r31892. Thanks for the feedback!
[perl #59340] t/stm/runtime_4.pir segfaults on FreeBSD 7 (i386)
On Thu Sep 25 15:09:30 2008, geraud wrote: I reported a problem on IRC yesterday and was prompted to file a bug. So here we go. The GeJ reports that this test is passing now so I'm marking this ticket resolved.
[perl #59336] [BUG] Parrot fails integer comparisons when integers are 2^31 apart
On Thu Sep 25 14:18:40 2008, julianalbo wrote: I suspect the problem is that the integer greater than operation is performing a subtraction between the two (signed long) values being compared, but the result of the subtraction is outside of the range of signed longs. Correct. Fixed in r31419 chromatic added a test for this in r31420, so I'm marking it resolved.
[perl #50908] [CAGE] gcc -Werror=declaration-after-statement
On Wed Sep 24 10:47:16 2008, cotto wrote: On Mon Feb 18 18:07:43 2008, coke wrote: On Feb 18, 2008 8:39 PM, chromatic [EMAIL PROTECTED] wrote: On Friday 15 February 2008 11:35:04 Will Coleda wrote: According to http://gcc.gnu.org/onlinedocs/index.html#DIR, looks like as of gcc 4.2.3 (but not 4.1.2), we can use the following option to gcc: -Werror=declaration-after-statement To help enforce our C89 compliance by causing this particular style to become an error instead of just a warning. This should be added as a default to the build options if a recent enough version of gcc is available. Works for me with gcc 4.1.3; I think this is closeable. -- c It's not checked in anywhere, though. We're just using -Wdeclaration-after-statement not -Werror=declaration-after-statement Parrot builds with gcc 4.3.1 just fine when -Werror=declaration-after-statement is added after -Wdeclearation-after-statement in config/auto/warnings.pm . The option shows up in the generated Makefile and in the gcc invocation that's used. Adding this line with a gcc that doesn't support -Werror=declaration-after-statement doesn't cause any problems. It looks like this can safely be integrated into the build process. Once such a change is committed, this ticket can be closed. I'll do this tonight if nobody beats me to it. This option was added in r31396. I'll be keeping an eye on smolder in case this breaks anything, but I'm also resolving the ticket. It can be reopened if needed.
[perl #57728] [TODO] avoid 2038 bug if we haven't already.
On Thu Aug 07 14:20:11 2008, coke wrote: Open a ticket for TODO item. -- Forwarded message -- From: jerry gay [EMAIL PROTECTED] Date: Thu, Aug 7, 2008 at 4:34 PM Subject: Re: time op inconsistent on Win32 To: Ron Blaschke [EMAIL PROTECTED] Cc: Jonathan Worthington [EMAIL PROTECTED], p2 [EMAIL PROTECTED] we definitely need date/time pmc(s?) not only to have a common epoch across platforms, but to deal with 2038. in particular, we should leverage schwern's work on perl to address the 2038 bug. ~jerry We definitely haven't already fixed this. Here's an easy test using libfaketime: $ cat time.pir .sub main :main .local int time_int time time_int say time_int .end $ ./parrot time.pir 113121 $ LD_PRELOAD=/usr/src/libfaketime-0.8/libfaketime.so.1 FAKETIME=+40y ./parrot time.pir -1811314167
[perl #46677] [TODO] [C] Merge fixedbooleanarray.pmc with functions from BigInt PMC
On Mon Oct 22 09:47:52 2007, pcoch wrote: In src/pmc/fixedbooleanarray.pmc there is the todo item; * TODO merge this with functions from BigInt PMC The functionality in this file should be merged with that in the BigInt PMC I propose to reject this ticket. Reducing code duplication is a good idea, but it's not at all clear to me what this ticket is referring to. If someone cares to point out what code should be merged, great. Otherwise this ticket is too vague to be useful. Christoph
[perl #50908] [CAGE] gcc -Werror=declaration-after-statement
On Mon Feb 18 18:07:43 2008, coke wrote: On Feb 18, 2008 8:39 PM, chromatic [EMAIL PROTECTED] wrote: On Friday 15 February 2008 11:35:04 Will Coleda wrote: According to http://gcc.gnu.org/onlinedocs/index.html#DIR, looks like as of gcc 4.2.3 (but not 4.1.2), we can use the following option to gcc: -Werror=declaration-after-statement To help enforce our C89 compliance by causing this particular style to become an error instead of just a warning. This should be added as a default to the build options if a recent enough version of gcc is available. Works for me with gcc 4.1.3; I think this is closeable. -- c It's not checked in anywhere, though. We're just using -Wdeclaration-after-statement not -Werror=declaration-after-statement Parrot builds with gcc 4.3.1 just fine when -Werror=declaration-after-statement is added after -Wdeclearation-after-statement in config/auto/warnings.pm . The option shows up in the generated Makefile and in the gcc invocation that's used. Adding this line with a gcc that doesn't support -Werror=declaration-after-statement doesn't cause any problems. It looks like this can safely be integrated into the build process. Once such a change is committed, this ticket can be closed. I'll do this tonight if nobody beats me to it.
[perl #58796] [CAGE] src/library.c (and others?) refer to .past files, which are no longer used
On Fri Sep 12 10:06:01 2008, [EMAIL PROTECTED] wrote: src/library.c (and others?) refer to .past files, which are no longer used. remove all references to this filetype from the parrot repo. ~jerry This one should be closeable as of r31284. I tried acking through all instances of the string past in trunk and none of them looked like it referred to a filename extension. For that reason, I'm marking this resolved.
[perl #45909] [TODO] Replace quadratic search with something linear in find_exception_handler()
On Wed Sep 17 16:57:06 2008, cotto wrote: On Mon Oct 01 10:40:33 2007, pcoch wrote: In src/exceptions.c there is the todo comment: [TODO: replace quadratic search with something linear, hopefully without trashing abstraction layers I can't find this comment any more, nor any occurrence of this ticket's number. I'll do some digging later to see where the comment went, but it's likely that this ticket can be resolved or rejected. Christoph This comment was deleted by Allison in r27357 as part of the pdd25cx work. Since that revision deleted the comment and more or less completely rewrote the function in question, I'm resolving this ticket.
[perl #58866] calling a PIR sub with 206 params segfaults parrot
On Thu Sep 18 08:52:10 2008, julianalbo wrote: I changed the fix in r31230 to allocate char instead of char *, adjusted the formula for buffer size and added a comment explaining it to lower the level of black magic, and added a check for each item, dropping the XXX comment that asked for it. I hope this is enough understanding of the error ;) Thanks. I think neither of us read the code quite correctly, but your patch was a significant improvement. It also fixed a hard-to-reproduce bug that GeJ was running into on FreeBSD 7.1. In looking at the code, I can see some ways to make the test more comprehensive. I'm going to reopen it as a way to remind me to write some more exhaustive tests which exercise sub signatures as well as sub calls.
[perl #41291] [RFC] Can't use null PMC with :multi sub
On Thu Jan 18 14:14:30 2007, mdiep wrote: On Thu Jan 18 13:52:33 2007, leo wrote: While that was never actually specced, I do consider a NULL PMC as something like a null pointer in C. Any access (except testing for NULL-ness) to it is an error. Above example tests, that some usage of a NULL PMC fails. It's of course debatable, which usage of NULL should be allowed, e.g. above one. An explicit test in PMC-type conversion for PMCNULL in the MMD code is very likely all to make above code running (mmd.c:167,168). I based the bug report on the behavior of normal subs: .sub main :main null $P0 foo($P0) # this *does* print foo\n .end .sub foo say foo .end I don't know that I particularly need to be able to pass null PMCs to a MultiSub, but I at least demand a better error message. :-) I think either way will be trivial to write, but it probably needs some input from the architect. -- Matt Diephouse The above code prints Any in the mmd branch. Unless that's an unwanted behavior, it looks like this ticket can be resolved once the mmd branch is merged.
[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.
[perl #58866] calling a PIR sub with 206 params segfaults parrot
On Wed Sep 17 08:31:26 2008, particle wrote: On Tue, Sep 16, 2008 at 11:45 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote: On Tuesday 16 September 2008 14:47:58 NotFound wrote: It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. The problem is located inside compilers/imcc/pcc.c:pcc_get_args function. It has the comment /* XXX check avail len */ just at the point where the segfault happens. char buf[1024] is the variable overrunned. That sounds like a bog-standard static variable overflow, where each parameter requires five bytes of storage. If that's a good rule of thumb, we could malloc/free that buffer instead, and then beat anyone who uses more than a dozen parameters. -- c Looking at the code, it's 5n+1. r31200 changes the static buffer to a dynamic one of the correct size. The original PIR code now runs without segfaulting, as does a version with 20,000 int params. make test also passes, so nothing new appears to be broken. With the assumption that the said beatings will be a manual process, I'm marking this resolved. you didn't mention it, but i sincerely hope you committed a test with 20,000 params that proves this and makes sure we don't regress in a future revision. parrot needs much more stress testing like this, and it would be a shame to miss this opportunity. ~jerry I didn't think of it until after I went to bed, but I added one with 1000 params in r31208 the next morning. The 20,000 param version took more than a second to run and I didn't see any reason to slow the tests down more than necessary.
[perl #45909] [TODO] Replace quadratic search with something linear in find_exception_handler()
On Mon Oct 01 10:40:33 2007, pcoch wrote: In src/exceptions.c there is the todo comment: [TODO: replace quadratic search with something linear, hopefully without trashing abstraction layers I can't find this comment any more, nor any occurrence of this ticket's number. I'll do some digging later to see where the comment went, but it's likely that this ticket can be resolved or rejected. Christoph
[perl #53536] [PATCH] sub-second sleep precision for non-threaded architectures
On Mon Sep 15 20:08:38 2008, [EMAIL PROTECTED] wrote: chromatic wrote: On Monday 15 September 2008 01:25:15 Christoph Otto via RT wrote: It applies with a little noise to the current trunk and passes make test. The attached version just changes line numbers so the patch applies without any complaints (plus a codingstd fix). +1 for applying, fwiw. +1 as well, if someone replaces the Not yet documented lines with documentation (man usleep should help). -- c I'll be applying the attached the patch after tomorrow's release, if someone doesn't beat me to it. Done. Thanks for the patch!
[perl #58866] calling a PIR sub with 206 params segfaults parrot
On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote: On Tuesday 16 September 2008 14:47:58 NotFound wrote: It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. The problem is located inside compilers/imcc/pcc.c:pcc_get_args function. It has the comment /* XXX check avail len */ just at the point where the segfault happens. char buf[1024] is the variable overrunned. That sounds like a bog-standard static variable overflow, where each parameter requires five bytes of storage. If that's a good rule of thumb, we could malloc/free that buffer instead, and then beat anyone who uses more than a dozen parameters. -- c Looking at the code, it's 5n+1. r31200 changes the static buffer to a dynamic one of the correct size. The original PIR code now runs without segfaulting, as does a version with 20,000 int params. make test also passes, so nothing new appears to be broken. With the assumption that the said beatings will be a manual process, I'm marking this resolved.
[perl #49722] [CAGE] Add Tests for SchedulerMessage PMC
On Sun Jan 13 05:38:42 2008, coke wrote: -- Will Coke Coleda On Jan 12, 2008, at 7:33 PM, chromatic (via RT) parrotbug- [EMAIL PROTECTED] wrote: # New Ticket Created by chromatic # Please include the string: [perl #49722] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49722 The current tests in t/pmc/schedulermessage.t are only a placeholder. This PMC needs full test coverage. Also: Current test is pir with perl coda... r31100 adds tests that hit every VTABLE method except mark() and share_ro(). The tests pretty generic, but they should be good enough to justify my having marked this ticket resolved.
[perl #52778] [RFC] Are resizable arrays too Perlish?
On Thu Sep 11 23:15:50 2008, cotto wrote: On Mon Sep 08 22:54:28 2008, [EMAIL PROTECTED] wrote: Patrick R. Michaud wrote: Fixing this shouldn't be all that difficult -- in particular, I think that src/pmc/resizablepmcarray.pmc lines 205-206 should be changed from - if (key = PMC_int_val(SELF)) - SELF.set_integer_native(key+1); to something like + if (key = PMC_int_val(SELF)) + return PMCNULL; I haven't tested this -- there may be other things that need to change as well. Hope this helps, Pm It turns out that no further changes were needed to implement this behavior. The attached patch fixes this (and two incorrect ResizableBooleanArray tests). With the patch applied, all tests in make test pass. If this is what we want Parrot to do, I'll apply the patch and add tests to Resizable*Array to make sure the behavior stays consistent. I'm going to give this until next Tuesday for comment, at which point I'll commit the patch and mark this ticket as resolved. I got impatient and committed this as r31101. I'm marking this ticket as resolved.
[perl #52778] [RFC] Are resizable arrays too Perlish?
On Mon Sep 08 22:54:28 2008, [EMAIL PROTECTED] wrote: Patrick R. Michaud wrote: Fixing this shouldn't be all that difficult -- in particular, I think that src/pmc/resizablepmcarray.pmc lines 205-206 should be changed from - if (key = PMC_int_val(SELF)) - SELF.set_integer_native(key+1); to something like + if (key = PMC_int_val(SELF)) + return PMCNULL; I haven't tested this -- there may be other things that need to change as well. Hope this helps, Pm It turns out that no further changes were needed to implement this behavior. The attached patch fixes this (and two incorrect ResizableBooleanArray tests). With the patch applied, all tests in make test pass. If this is what we want Parrot to do, I'll apply the patch and add tests to Resizable*Array to make sure the behavior stays consistent. I'm going to give this until next Tuesday for comment, at which point I'll commit the patch and mark this ticket as resolved.
[perl #44457] [TODO] make sure files match test files for DYNPMCs and DYNOPs etc
On Mon Aug 06 06:08:54 2007, pcoch wrote: In the file t/distro/test_file_coverage.t there is the todo item: # TODO: DYNPMC, DYNOPS, etc This is in the context of making sure that the files match the test files. This needs to be implemented. Is this as simple as writing a test to make sure every src/dynpmc/*.pmc and src/dynoplibs/*.ops has a matching t/dynpmc/*.t and t/dynoplibs/*.t ? If so, this would be an ideal task for one of our recent volunteers, since the code would be pure Perl. Also, the test will fail without an exception for src/dynpmc/rotest.pmc. I don't know if a test should be written for this PMC or not.
[perl #41892] [BUG] t/stm/llqueue segment violation on test #2
On Mon Mar 19 10:22:42 2007, coke wrote: test TODOd for next release, thanks for the report. (Hopefully it'll get fixed shortly after the release.) On Sun Mar 18 08:07:05 2007, [EMAIL PROTECTED] wrote: I get SIGSEGV in t/stm/llqueue, test #2 openSuSe 10.2 linux 2.6.18.8-0.1-xen i686 athlon Tested at parrot svn revision 17614 t/stm/llqueueok 1/2 # Failed test (t/stm/llqueue.t at line 59) # got: '' # expected: 'sum is 4950 # ' # './parrot -D40 --gc-debug /home/uniejo/parrot/parrot/t/stm/llqueue_2.pir' failed with exit code [SIGNAL 11] t/stm/llqueueNOK 2# Looks like you failed 1 test of 2. t/stm/llqueuedubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/2 tests, 50.00% okay It looks like this test is passing now (on Debian/x86, at least). If someone doesn't mind confirming this, we can close this ticket.
[perl #41825] [BUG] morph vtable override not working in PIR
On Tue Nov 20 20:58:35 2007, [EMAIL PROTECTED] wrote: On Wed Mar 14 07:49:33 2007, [EMAIL PROTECTED] wrote: Hi, Given the following: .namespace ['A'] .sub 'morph' :method :vtable say 'morphing!' .end .sub main :main $P0 = newclass 'A' $P1 = new 'A' morph $P1, .Undef .end the 'morph' vtable method doesn't get called Works for me in 0.5.0 (r22925), if I remove :method from the 'morph' declaration. Can you confirm? I'm still seeing the broken behavior in r30915.
[perl #55372] [BUG] Segfault/double free when manually running perl6
On Sun Sep 07 15:19:22 2008, cotto wrote: On Thu Jun 12 10:23:06 2008, [EMAIL PROTECTED] wrote: On Thursday 12 June 2008 10:01:21 NotFound wrote: Some more details: adding: Parrot_set_flag(interp, PARROT_DESTROY_FLAG); in src/main.c it segfaults also when executing with perl6.pbc, and also a lot of parrot test fails. So it looks like there is a general problem of interpreter destruction in exits from the exception handler. That's why I added the flag in the fakecutables; I figured we'd never catch these problems unless we tested for them frequently. -- c I'm no longer seeing a double-free (linux/x86). The test in question still fails, but it doesn't fail quite as horribly. If there are no objections, I'll close this ticket before the next #parrotsketch. resolved
[perl #57668] [BUG][PATCH] Iterate through the current namespace causes a segfault
On Fri Sep 05 00:18:19 2008, [EMAIL PROTECTED] wrote: Bob Rogers wrote: From: chromatic [EMAIL PROTECTED] Fixed in r30286. -- c Terrific; thanks. (Especially since it looks like something I may have seen in other circumstances, but could not reproduce.) -- Bob It looks like this is resolved. I'll mark it as such in rt in a couple days unless there are any objections. Christoph resolved
[perl #52054] [CAGE]: Make all PDDs conform to coding standards
On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote: Christoph Otto wrote: If those are your thoughts on the subject, then it seems to make sense to add the pdd format test to make test. The attached patch does this. I'll apply it and mark this ticket as resolved before the next #parrotsketch unless there are any objections. Excellent idea. Thanks! Allison committed and resolved
[perl #51464] [TODO] [PDD] add date stamps to PDD's
On Mon Sep 08 01:18:37 2008, [EMAIL PROTECTED] wrote: Christoph Otto via RT wrote: Is this something we want to go ahead with or should this ticket be rejected? I've had it on my hiveminder todo list for over a month now. The problem is, it's not only a matter of annoying fiddly bookkeeping work now, it's also annoying fiddly bookkeeping work eternally into the future. And, it doesn't actually solve the original problem of knowing when a PDD was significantly updated, because whoever edited the PDD might have just forgotten to update the manual date stamp. So, ticket rejected. The only authoritative information on revisions to a PDD is the commit logs. Allison Rejected it is.
[perl #52054] [CAGE]: Make all PDDs conform to coding standards
On Mon Sep 08 00:12:44 2008, cotto wrote: On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote: Christoph Otto wrote: If those are your thoughts on the subject, then it seems to make sense to add the pdd format test to make test. The attached patch does this. I'll apply it and mark this ticket as resolved before the next #parrotsketch unless there are any objections. Excellent idea. Thanks! Allison committed and resolved attempt #2 at marking this resolved
[perl #56636] [BUG] segfault from sort if comparison is always 1
On Mon Jul 07 00:13:20 2008, [EMAIL PROTECTED] wrote: On Sunday 06 July 2008 22:17:12 Andrew Johnson via RT wrote: On Sun Jul 06 11:03:37 2008, japhb wrote: Better yet, we should replace the inherently insecure quicksort algorithm (insecure in the vulnerable to algorithmic attack sense) with a more secure mergesort like perl5 uses. IIRC, perl5's mergesort is also carefully crafted to be as sensible as possible in the face of insane compare functions No objections here, but until that's available the attached patch stops the segfault from occurring with the existing quicksort function. Agreed. Thanks, applied with a test from the original message as r29115. The test should be robust enough in the face of algorithmic changes to continue to pass as long as the code fails to segfault. -- c Since the code in question is no longer segfaulting, I'm marking this as resolved.
[perl #58484] [PATCH] Use of uninitialized value in scalar assignment at lib/Parrot/Revision.pm line 95.
On Mon Sep 08 04:23:37 2008, [EMAIL PROTECTED] wrote: Applied in r30888. cotto is going to check its functioning on Cygwin, but it did no harm on Darwin and Linux, so I'm committing it now. Thank you very much. kid51 It looks good on Cygwin too, so I'm marking this resolved.
[perl #54938] [BUG] Double free
On Fri Sep 05 12:16:25 2008, cotto wrote:
On Tue May 27 13:33:11 2008, [EMAIL PROTECTED] wrote:
Running this program:
sub foo($a) {say $a} ; my $x = ;
on Ubuntu 8.04 with latest Parrot from svn gives this:
$ ./perl6 test.p6
Statement not terminated properly at line 1, near = ;\n
current instr.: 'parrot;PGE::Util;die' pc 120
(runtime/parrot/library/PGE/Util.pir:82)
called from Sub 'parrot;Perl6::Grammar;statementlist' pc 18610
(src/gen_grammar.pir:2736)
called from Sub 'parrot;Perl6::Grammar;statement_block' pc 15456
(src/gen_grammar.pir:1614)
called from Sub 'parrot;Perl6::Grammar;TOP' pc 11688
(src/gen_grammar.pir:211)
called from Sub 'parrot;PCT::HLLCompiler;parse' pc 562
(src/PCT/HLLCompiler.pir:348)
called from Sub 'parrot;PCT::HLLCompiler;compile' pc 438
(src/PCT/HLLCompiler.pir:291)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 753
(src/PCT/HLLCompiler.pir:450)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1065
(src/PCT/HLLCompiler.pir:587)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1244
(src/PCT/HLLCompiler.pir:676)
called from Sub 'parrot;Perl6::Compiler;main' pc 10064 (perl6.pir:186)
*** glibc detected *** ./perl6: double free or corruption (!prev):
0x00e83310 ***
Attached is a valgrind --leak-check=full log of a double free with this
program:
I'm no longer seeing the double free on Debian/x86. It would be good to
get a confirmation from the thread starter, but it looks like this
ticket can be resolved. I'll give it a couple days and mark it as such.
Christoph
resolved
[perl #42378] [TODO] explicit exit from debug_break() op is not ok
On Mon Apr 09 01:29:52 2007, pcoch wrote: In the file src/ops/debug.ops in the debug_break() op, there is an explicit exit(0), which is marked as being not an ok thing to do. This issue needs to be investigated and fixed. It looks like the explicit exit in debug_break() is gone, so I'm marking this ticket as resolved.
[perl #45357] [TODO] Which exception should be thrown with register overflow?
On Tue Sep 11 03:32:51 2007, pcoch wrote: Having a look through PDD03 I noticed the TODO item left by Chip: =head3 Overflow If too many values are provided to fit into the given target registers, Parrot will throw an exception. Note that if the final target is a P register with FLAT set, then this exception can never occur. XXX - FIXME - which exception? We really could use an exception subsystem. Oh, wait, that's my job. Never mind. --Chip What should we do here? Do we already have an exception subsystem? Has this been designed/implemented? Given the way Parrot currently regards registers, is this ticket still relevant?
[perl #46635] [TODO] [C] Check overflow for -maxint in absolute()
On Thu Feb 21 12:15:06 2008, Whiteknight wrote: What would be the best way to handle this? We certainly don't need to do anything on systems where INT_MAX == -INT_MIN, but a simple compiler directive should help to detect that case. In the event that abs(INT_MIN) abs(INT_MAX), should we silently saturate the result to INT_MAX, or should we error? I'll be happy to put in a patch for this once I know what the behavior should be. --Andrew Whitworth Any ruling on this?
[perl #46651] [TODO] [C] Make a better interface for hash creation
On Mon Oct 22 07:01:59 2007, pcoch wrote: In src/pmc/hash.pmc:thaw() there is the todo item: /* TODO make a better interface for hash creation ... do this. Where do we want to go with this?
[perl #48320] [BUG] Example in pdd23 doesn't work
On Sat Sep 06 15:51:16 2008, julianalbo wrote: Sorry, the code I poste was bad. The valid form is: $P1 = new ['Exception'], $P0 # create new exception object I've changed the example code to use the more common syntax without brackets: $P1 = new 'Exception', $P0 . The code works now, so I'm resolving this ticket.
[perl #40156] [TODO] - Can't use an Iterator with a DynLexPad PMC
On Tue Feb 05 06:50:24 2008, coke wrote: On Wed Aug 16 23:09:16 2006, mdiep wrote: I don't know how to write a test for this off the top of my head, but Iterator and DynLexPad don't play well together atm. When I tried, I got this error: elements() not implemented in class 'DynLexPad' Is there an easy way to make an arbitrary hash-like PMC (DynLexPad, NameSpace, etc.) play well with iterator? Tcl needs to be able to iterate over the keys to return a list of all the variables in the current procedure/lexpad. (See [info vars]) -- Matt Diephouse A nice cage task would be to write a test demonstrating the use of an iterator in this case. As of r30844 there's a TODO'd test for this, but some work will need to be done to make DynLexPads (and LexPads, incidentally) iterable. Since DynLexPads are based on Hashes, I imagine most of the work will be in adapting get_iter and get_*_keyed.
[perl #39430] [TODO] Method cache not always invalidated
On Sat May 17 14:55:53 2008, pmichaud wrote: On Mon Jun 12 16:30:13 2006, jonathan wrote: Both Parrot_store_global and store_sub call Parrot_invalidate_method_cache, however the versions of these that take keys (Parrot_store_global_p and store_sub_p) fail to do so. Is this ticket still relevant after the pdd15oo changes incorporated in late 2007? If the ticket is not relevant, let's close it. Pm There's a test that appears to be relevant in t/pmc/object-meths.t, but I'm not sure if it tests for the behavior mentioned in this ticket.
[perl #56614] [TODO] Config hash should be marked read-only
On Sat Jul 05 02:53:11 2008, bernhard wrote: In runtime/parrot/library/config.pir I encountered the comment. XXX hash should probably be marked read-only.. This should be investigated. Regards, Bernhard This seems to be a very sane suggestion. It's implemented and has a test test as of r30849. Happily, all other tests passed without any modifications.
[perl #58374] [TODO][PDD19] Decide on maximum identifier length and implement this.
On Tue Aug 26 18:39:55 2008, rgrjr wrote: From: Klaas-Jan Stol (via RT) [EMAIL PROTECTED] Date: Tue, 26 Aug 2008 04:46:56 -0700 From PDD19: Identifiers don't have any limit on length at the moment, but some sane-but-generous length limit may be imposed in the future (256 chars, 1024 chars?). If the code already supports arbitrarily long identifiers, what is the motivation for setting a limit? -- Bob Rogers http://rgrjr.dyndns.org/ +1 If there isn't a technical reason why this is necessary, there's no reason to create such a limitation. If there is such a reason, just pick something big and make the code enforce it. The PDD should of course be kept in sync with reality, but that simply entails a simple edit/commit once the issue is settled.
[perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
On Wed May 10 11:01:34 2006, stmpeters wrote: I'm taking a look at it. I should have something working this evening for the configs. Adding the HAS_BLAH's will take some additional time. Steve Peters [EMAIL PROTECTED] when useful is vague does not indicate why the extra configuration machinery is justified by whatever benefit we'd get from using these functions. If someone would like to make the requirements a little tighter or make the case for implementing this request (or even implement it), they'd be encouraged. Otherwise this ticket isn't very useful. It would be good to either go somewhere with this or reject this request.
[perl #57610] [PATCH] Resumable exceptions
On Tue Aug 05 04:09:14 2008, tene wrote: pdd23: Exception handlers can resume execution immediately after the throw opcode by invoking the resume continuation which is stored in the exception object. That continuation must be invoked with no parameters; in other words, throw never returns a value. Exception.pmc has the following attributes: ATTR INTVALid; /* The task ID in the scheduler. */ ATTR FLOATVAL birthtime;/* The creation time stamp of the exception. */ ATTR STRING *message; /* The exception message. */ ATTR PMC *payload; /* The payload for the exception. */ ATTR INTVALseverity; /* The severity of the exception. */ ATTR INTVALtype; /* The type of the exception. */ ATTR INTVALexit_code;/* The exit code of the exception. */ ATTR PMC *stacktrace; /* The stacktrace of an exception. */ ATTR INTVALhandled; /* Whether the exception has been handled. */ ATTR PMC *handler_iter; /* An iterator of handlers (for rethrow). */ ATTR Parrot_Context *handler_ctx; /* A stored context for handler iterator. */ None of these is a continuation. The throw opcode passes the address of the next opcode to Parrot_ex_throw_from_op, but Petfo only uses it in: address= VTABLE_invoke(interp, handler, dest); and the ExceptionHandler PMC's invoke() does not use that parameter at all. This first draft of a patch adds an attribute to the exception pmc to hold a return continuation, creates a retcontinuation pmc in the throw opcode and assigns it to that attribute, and patches new_ret_continuation to initialize the new continuation's from_ctx attribute in the same way new_continuation does. This last item is there to fix a segfault. I don't understand parrot's continuations well enough yet to have any idea why they were different, so I just guessed. I don't know if it's wrong, but it doesn't seem to fail any extra tests. Added a simple test case. It looks like Allison applied your patch in r30123 but forgot to close this ticket. Now seems like a good time to resolve it. Thanks for the patch.
[perl #55372] [BUG] Segfault/double free when manually running perl6
On Thu Jun 12 10:23:06 2008, [EMAIL PROTECTED] wrote: On Thursday 12 June 2008 10:01:21 NotFound wrote: Some more details: adding: Parrot_set_flag(interp, PARROT_DESTROY_FLAG); in src/main.c it segfaults also when executing with perl6.pbc, and also a lot of parrot test fails. So it looks like there is a general problem of interpreter destruction in exits from the exception handler. That's why I added the flag in the fakecutables; I figured we'd never catch these problems unless we tested for them frequently. -- c I'm no longer seeing a double-free (linux/x86). The test in question still fails, but it doesn't fail quite as horribly. If there are no objections, I'll close this ticket before the next #parrotsketch.
[perl #52976] [BUG] perl6 stand-alone binary broken
On Wed Apr 16 14:24:28 2008, [EMAIL PROTECTED] wrote: On Wednesday 16 April 2008 10:49:15 Christoph Otto (Volt) wrote: The perl6 stand-alone binary chokes on chromatic's mmd example (http://www.oreillynet.com/onlamp/blog/2008/04/multiple_dispatch_now_please .html) under linux/x86. The bug was exposed in r26173, but the root cause is probably deeper. It looks easy to reproduce, but I can certainly provide more information if as needed. The root cause is a double-free on something in a context somewhere. If you keep the patch in r26173 around and bisect the thousand or so commits before there, you (or I) can probably find it. -- c I'm not sure why this didn't get closed earlier, but now's a fine time to do so. resolved
[perl #51838] [BUG] cygwin build fails
On Tue Mar 18 14:05:34 2008, rurban wrote:
It's time to use Configure.pl with the option --without-crypto
Or to add -lcrypto to the cmdline.
Configure.pl fails to pick it up apparently.
my %Parrot::Config::Generated::PConfig contains -lcrypto in libs
'libs' = '-ldl -lcrypt -lgmp -lreadline -lcrypto',
so there's something else broken.
However, the rest compiles ok.
dynpmc does contain it:
my $extraLibs = '-ldl -lcrypt -lgmp -lreadline -lcrypto ';
but it is only used on windows. How should does work on other platforms?
Anyway I fixed it with this patch:
config/gen/makefiles/dynpmc_pl.in
diff -ub config/gen/makefiles/dynpmc_pl.in.orig
--- config/gen/makefiles/dynpmc_pl.in.orig 2008-03-15
22:01:26.015625000 +
+++ config/gen/makefiles/dynpmc_pl.in 2008-03-18 21:06:16.25000
+
@@ -92,6 +92,8 @@
}
else {
$liblist = join( ' ', map { -l$_ } keys %$libs );
+my $extraLibs = '@libs@ @icu_shared@';
+$liblist .= ' ' . $extraLibs;
}
return
It looks like chromatic added this patch in r26632. Does it resolve
this issue?
[perl #48439] [TODO] [configure] compiling Parrot with LLVM
On Mon Dec 10 08:52:27 2007, [EMAIL PROTECTED] wrote:
Marton Papp has successfully compiled Parrot with LLVM on Windows with
mingw-make (it's failing 18 tests, which is impressively low for a first
run on a new compiler). Below is his summary of the steps he followed.
I'd like to extract the changes he made for the configuration system.
Original Message
Subject: Re: hi! LLVM and parrot
Date: Mon, 10 Dec 2007 14:33:46 +0100
From: [EMAIL PROTECTED]
[...]
I used this file to compile it
set path=%path%;c:\mingw\bin;D:\extracted\icu2\icu\bin
e:
cd e:\extracted\parrot-0.5.0\bin
perl configure.pl --cc=E:\llvm\bin\llvm-gcc.exe
--cxx=E:\llvm\bin\llvm-g++.exe --link=E:\llvm\bin\llvm-gcc.exe
--ld=E:\llvm\bin\llvm-gcc.exe
I changed the makefile in the directory
where there is line CUR_DIR = .
I changed it for full path of the current directory.
(Otherwise ./mini_parrot caused in error)
In my case,
It became CUR_DIR = E:\extracted\parrot-0.5.0
and ran mingw-make
Then make stopped.
I moved into the directory, it just left.
Changed these files/
In dynpmc.pl
I changed last line of partial_link_cmd.
return
$LD .
'-o ' . $target . .
join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources) .
$PATHQUOTE$LIBPARROT$PATHQUOTE $liblist $LDFLAGS
$LD_LOAD_FLAGS ;
and changed this:our $LIBPARROT = q[]; for our $LIBPARROT = q[-lparrot]
continued make by mingw-make...
The make failed again , then
I changed parrot-0.5.0\tools\build\dynoplibs.pl
I inserted these lines (copied them from tools\build\dynpmc.pl) :
# Also note that we may need to look in the Parrot blib directory.
if ($CC =~ /gcc/i) {
$liblist .= qq{ -Wl,-L E:/extracted/parrot-0.5.0/blib/lib};
}
else {
$liblist .= qq{
/LIBPATH:E:/extracted/parrot-0.5.0/blib/lib};
}
I changed last lines of partial_link_cmd in dynpmc.pl
(something similar to this)
return
$LD .
'-o ' . $target . .
join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources) .
$liblist $LDFLAGS $LD_LOAD_FLAGS ;
The explanation: remove $PATHQUOTE$LIBPARROT$PATHQUOTE so that
unreferenced symbol do not occur..
I did something similar in the code it is not worth duplicating it here.
I changed $extraLibs in dynoplibs.pl inpartial_link_cmd
for $extraLibs = '-lparrot ..
I added -lparrot at the beginning
I went into directory just failed. I ran make.
Then I want back to the main make.
I ran it.
Marton Papp
All tests pass on Debian/x86 with --cc=llvm-gcc --link=llvm-gcc
--ld=llvm-gcc passed to Configure.pl . If someone can confirm that
Configure.pl is similarly smart on Windows, this ticket can be closed.
[perl #48176] [TODO] [pugs] Warning: use of uninitialized value
On Wed Dec 05 04:53:15 2007, pcoch wrote: In languages/pugs/pmc/pugscapture.pmc there are todo items of the form: /* XXX Warning: use of uninitialized value */ This looks very similar to RT#48170 which was in the regex language. Does this todo item mean that we should be *warning* about an uninitialised value here, rather than that there is one in the C code? I'm rejecting this, since pugs has been deleted from trunk.
[perl #32087] [PATCH] .include with an absolute path
On Fri Sep 05 00:58:51 2008, cotto wrote: On Fri Aug 01 06:44:05 2008, coke wrote: On Thu, Jul 31, 2008 at 7:35 PM, James Keenan via RT [EMAIL PROTECTED] wrote: Coke: Given the points Leo made and the fact that there has been nothing from the OP in 4 years, can we close this ticket? Thanks. kid51 Just because there's no activity or followups on a ticket doesn't mean the bug isn't still there. In this case, though, I can't reproduce the poster's original complaint about an absolute include path not working, ignoring the quality or state of his patch. We can close this ticket by adding a test that - creates a temporary PIR file with a simple one line :main that outputs something. - gets the absolute path of that file - uses another file to .include that temporary file via the absolute path. - verifies the output - removes the temporary file. This patch adds test of this functionality to t/compilers/imcc/syn/file.t . It passes on Linux/x86. I'll try it on a windows machine tomorrow and apply it over the weekend unless there any objections. Christoph The patched test works on windows, so I've applied it as r30801 and am resolving this ticket.
[perl #50878] [BUG] is_equal vtable function not callable in C
On Fri Feb 15 02:43:05 2008, [EMAIL PROTECTED] wrote: They're marked as MMD in vtable.tbl, so my guess is that they're not directly callable by vtable pointer from C. Fdocs/mmd.pod (though admittedly out of date) suggests that mmd_dispatch_* is the right approach. -- c Sounds good enough for me. I'm marking this as resolved.
[perl #54938] [BUG] Double free
On Tue May 27 13:33:11 2008, [EMAIL PROTECTED] wrote:
Running this program:
sub foo($a) {say $a} ; my $x = ;
on Ubuntu 8.04 with latest Parrot from svn gives this:
$ ./perl6 test.p6
Statement not terminated properly at line 1, near = ;\n
current instr.: 'parrot;PGE::Util;die' pc 120
(runtime/parrot/library/PGE/Util.pir:82)
called from Sub 'parrot;Perl6::Grammar;statementlist' pc 18610
(src/gen_grammar.pir:2736)
called from Sub 'parrot;Perl6::Grammar;statement_block' pc 15456
(src/gen_grammar.pir:1614)
called from Sub 'parrot;Perl6::Grammar;TOP' pc 11688
(src/gen_grammar.pir:211)
called from Sub 'parrot;PCT::HLLCompiler;parse' pc 562
(src/PCT/HLLCompiler.pir:348)
called from Sub 'parrot;PCT::HLLCompiler;compile' pc 438
(src/PCT/HLLCompiler.pir:291)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 753
(src/PCT/HLLCompiler.pir:450)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1065
(src/PCT/HLLCompiler.pir:587)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1244
(src/PCT/HLLCompiler.pir:676)
called from Sub 'parrot;Perl6::Compiler;main' pc 10064 (perl6.pir:186)
*** glibc detected *** ./perl6: double free or corruption (!prev):
0x00e83310 ***
Attached is a valgrind --leak-check=full log of a double free with this
program:
I'm no longer seeing the double free on Debian/x86. It would be good to
get a confirmation from the thread starter, but it looks like this
ticket can be resolved. I'll give it a couple days and mark it as such.
Christoph
[perl #55196] [BUG] print/say opcodes have different float precision
On Mon Jun 02 13:08:27 2008, [EMAIL PROTECTED] wrote: On Monday 02 June 2008 12:27:17 Bernhard Schmalhofer wrote: The behavior of .sub main $N0 = 3.14159 say $N0 print $N0 print \n .end surprised me, as I got: [EMAIL PROTECTED]:~/devel/Parrot/trunk$ uname -a Linux heist 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 GNU/Linux [EMAIL PROTECTED]:~/devel/Parrot/trunk$ ./parrot t.pir 3.14159 3.141590 Why should 'print' print trailing a '0' and 'say' not? The print opcode calls PIO_printf with a format of %f, while the say pseudo-opcode calls the say method on a ParrotIO PMC and Parrot converts the N-register argument into a string by some other means. This happens in src/inter_call.c, in convert_arg_from_num(), which calls string_from_num() in src_string.c with a format of %vg. They should probably be consistent, but changing either of them to match the other causes test failures (though they all look superficial). -- c I'll sign up to do the grunt work to fix the failing tests if someone makes a decision on what the consistent behavior should be. Christoph
[perl #52854] [bug] Build failure with G++
On Mon Apr 14 08:07:32 2008, [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 11:40:01AM +0530, Senaka Fernando wrote: On Mon, Apr 14, 2008 at 6:33 AM, chromatic [EMAIL PROTECTED] wrote: Thanks, applied as r26965, except for the patch to compilers/imcc/imclexer.c, which is a generated file. The source is compilers/imcc/imcc.l. Well if it is a generated file, why should it be under version control? Shouldn't that be removed? Normally, yes. In this case, we don't want to require everyone to install the correct versions of lex/flex and yacc/bison just to be able to build Parrot. In practice, very few people touch the IMCC parser or lexer. -- c I'm marking this resolved, since #52874 is resolved and is a continuation of this ticket.
[perl #48172] [TODO] [pugs] Getting nonexistent value, exception or undef?
On Wed Dec 05 04:49:22 2007, pcoch wrote: In languages/pugs/pmc/pugscapture.pmc:retval() there is the todo item: /* XXX getting non existent value, exception or undef? It looks like we need to determine at this point whether or not the value we are getting doesn't exist, is an exception, or is undef. Please correct me if I'm wrong! I'm rejecting this, since pugs has been deleted from trunk.
[perl #54414] [BUG] t\benchmark\benchmarks.t failure (r27624)
On Mon May 19 03:55:46 2008, [EMAIL PROTECTED] wrote: On Sun May 18 17:02:30 2008, ajr wrote: t\benchmark\benchmarks..28/37 # Failed test 'examples/benchmarks/primes2.pasm' # at t\benchmark\benchmarks.t line 219. # Exited with error code: 1 I think this problem is not restricted to Windows. Like Alan, I was running 'make fulltest' in response to chromatic's request for pre-release feedback. During the section 'make benchmark_tests', I got the attached on linux/386. All the benchmark tests are passing for me in linux/x86. Is that enough to close this ticket? Christoph
[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 #48971] [BUG] Parrot build failure no such instruction: `trap'
On Sun May 04 03:11:12 2008, [EMAIL PROTECTED] wrote: Excellent, the patch from ticket 52214 works. Walter resolved
[perl #48320] [BUG] Example in pdd23 doesn't work
On Sat Feb 16 17:23:47 2008, coke wrote: The example in the PDD now reads: $P0 = new 'String' $P0 = something bad happened $P1 = new ['parrot';'exception'], $P0 # create new exception object throw $P1 # throw it This code continues to not work. Would it be DTRT to copy/pasta some code from t/pmc/exception.t, such as the throw - no handler test?
[perl #51464] [TODO] [PDD] add date stamps to PDD's
On Fri Apr 04 16:52:39 2008, [EMAIL PROTECTED] wrote: On Fri Apr 04 04:30:17 2008, [EMAIL PROTECTED] wrote: One (possibly solvable) problem is that subversion tags don't substitute properly in the HTML generated versions on the website http://www.parrotcode.org/docs/pdd/pdd07_codingstd.html. What code do we use to generate those pages? How frequently are they updated? Who has permissions needed to run the update process? A bigger problem is that the $Id$ tag shows the last time the file was modified in any way (property changes, for example), but what people are looking for is a way to know the last time the design document was edited in a significant way. Ah, 'significant'. So this will require human intervention after all. Is this something we want to go ahead with or should this ticket be rejected?
[perl #32087] [PATCH] .include with an absolute path
On Fri Aug 01 06:44:05 2008, coke wrote: On Thu, Jul 31, 2008 at 7:35 PM, James Keenan via RT [EMAIL PROTECTED] wrote: Coke: Given the points Leo made and the fact that there has been nothing from the OP in 4 years, can we close this ticket? Thanks. kid51 Just because there's no activity or followups on a ticket doesn't mean the bug isn't still there. In this case, though, I can't reproduce the poster's original complaint about an absolute include path not working, ignoring the quality or state of his patch. We can close this ticket by adding a test that - creates a temporary PIR file with a simple one line :main that outputs something. - gets the absolute path of that file - uses another file to .include that temporary file via the absolute path. - verifies the output - removes the temporary file. This patch adds test of this functionality to t/compilers/imcc/syn/file.t . It passes on Linux/x86. I'll try it on a windows machine tomorrow and apply it over the weekend unless there any objections. Christoph Index: t/compilers/imcc/syn/file.t === --- t/compilers/imcc/syn/file.t (revision 30772) +++ t/compilers/imcc/syn/file.t (working copy) @@ -7,6 +7,7 @@ use lib qw( . lib ../lib ../../lib ); use File::Spec; use Test::More; +use Cwd qw(cwd); use Parrot::Config; use Parrot::Test tests = 13; @@ -52,6 +53,29 @@ unlink 'temp.pasm'; ## +open $FOO, '', temp.pasm or die Can't write temp.pasm\n; +print $FOO 'ENDF'; + .macro_const BAR 42 +ENDF +close $FOO; +my $temp_abs_path = cwd()./temp.pasm; + +pir_output_is( CODE, 'OUT', 'include pasm (absolute path)' ); +.sub test :main +say before +.include '$temp_abs_path' +say .BAR +say after +end +.end +CODE +before +42 +after +OUT +unlink 'temp.pasm'; + +## open $FOO, '', 'temp.pir' or die Can't write temp.pir: $!\n; print $FOO 'ENDF'; .const int BAR = 42
[perl #56304] smokej consumes all memory Revision: 28672 on linux
On Mon Jul 14 13:47:29 2008, [EMAIL PROTECTED] wrote: Seems to be fixed as of 29440: Sounds like a happy ending. resolved
[perl #39313] [TODO] or [BUG] improve PMC compiler
On Fri Jun 27 13:14:53 2008, coke wrote:
While I think this particular example is now valid with the new calling
conventions, you can get a similar effect with:
METHOD BORK BORK parent() {
/* nothing to see here*/
}
This ticket doesn't seem to be closeable as is. Would it be good enough
if pmc2c.pl spit out an error on the above definition, or is this even
something that pmc2c.pl should be concerned about?
[perl #57116] [BUG] make: *** [perl6] Segmentation fault
On Tue Jul 29 00:38:29 2008, tuxdna wrote: I found that it is now working correctly in the latest revision 29838. resolved
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Wed Aug 27 22:49:37 2008, cotto wrote: Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph Done.
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Thu Oct 25 00:49:38 2007, pcoch wrote: To be totally honest I wish I knew. I'm just going through converting the todo items in code into RT tickets and sometimes the todo comments aren't necessarily all that clear as to what needs to be done. I'm also (unfortunately) not familiar enough with pir to see in the code of the tests what needs fixing otherwise I might have been able to expand a little in the ticket. I'm really sorry I can't be of more help here! Paul Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph
[perl #57468] unused VNSNPRINTF check?
On Mon Aug 04 16:29:03 2008, coke wrote: As I mentioned on IRC, I'd recommend just removing it instead of adding another probe we're not sure we need. We can always come back to this ticket and grab your patch for later application if it we need to. Good enough. Andy (who originally wrote it) doesn't care either way, so I'm taking out the extra conditional and marking this rt as resolved. It'd be safer to use vsnprintf, but this is the only place it'd be used and a single use doesn't justify the extra configuration and testing code. The code in question was removed in r30028. If this ever gets revived, kid51 noted that there should be some documentation stating the difference between vsprintf and vsnprintf, and that a t/steps/auto_vsnprintf-01.t should also be added.
[perl #46691] [TODO] [C] Should the shift_pmc() method be silently ignored?
On Tue Jul 29 07:46:08 2008, coke wrote: Make this ticket one of the children ticket of the META pdd25cx merge ticket, we can close it out after the merge removes it. Allison++'s merge removed shift_pmc from src/pmc/exception.pmc, so this ticket is now rejected.
[perl #48264] [TODO] [C] Write file-level documentation
On Thu Dec 06 08:54:35 2007, pcoch wrote: Many files in the Parrot repository are lacking descriptions within the pod DESCRIPTION section. This needs to be done. An appropriate description of what the given file does is all that is necessary. r29788 adds a test for this. Unless the test is broken, this ticket can be closed once the second test in t/doc/pod.t passes.
[perl #46895] [TODO] [Pir] [C] Investigate and correct incorrect recursion depth counting in debug backtrace
On Thu Jul 24 23:21:19 2008, cotto wrote: I agreee. I ran with a few different runcores and always got 1000 as the number (when Parrot ran and I was patient enough to wait for the output). It was the same for cgoto, cgp, fast, slow and switch. I ran the following with a normal build of Parrot (no options passed to Configure.pl), in case someone wants to say ur doin it rong. ./parrot -R cgoto t/op/debuginfo_5.pir If it turns out I'm no doin it rong, I'll close this ticket in a couple days. Good enough. Resolved.
[perl #48367] [BUG] intlist_get could be dereferencing NULL
On Sat Jul 26 14:34:26 2008, [EMAIL PROTECTED] wrote: I'd write that as: if (ret) return *(INTVAL *)ret; return (INTVAL)0; The pointer casting dereferencing bothers me a little, but if compilers don't warn about it -- c That looks cleaner. I made that change and committed as r29786. This ticket is closed.
[perl #46805] [TODO] [Perl] Add more list_* tests
On Fri Jul 25 11:06:01 2008, [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2008 at 11:05:28PM -0700, Christoph Otto via RT wrote: From what I can tell, t/src/list.t was deleted or moved sometime after r22464. Searching for some of the more unique-looking strings in that revision of the file ( http://www.parrotvm.org/svn/parrot/checkout/trunk/t/src/list.t?rev=22464) turned up nothing in the current version, indicating that this file was deleted because its function was either unnecessary or redundant. If nobody objects I'll mark this ticket as rejected in a couple days. Go ahead now; I removed that test because it poked into the guts of libparrot unnecessarily to test code that we should be testing elsewhere less invasively. Done.
[perl #56548] PATCH] for file 01-literals.t
On Thu Jul 03 14:15:22 2008, [EMAIL PROTECTED] wrote: (sorry if this arrives multiple times, br0ken ISP and all..) Hi, Although there are some similar tests in t/00-parrot/ I wouldn't start adding more in this file, because the official test suite lives in the pugs repository under t/spec (svn co http://svn.pugscode.org/pugs/t/spec ). The file S02-literals/radix.t seems like the better place to start, there you also have access to better testing tools (like is(), ok() etc.) If you want to contribute to the test suite, please tell us your desired nick name and you can get a commit bit. Cheers, Moritz Since parrot isn't the right place for this patch, is there any reason not to reject this ticket?
[perl #57260] [BUG] Segfaults in sprintf opcode
On Fri Jul 25 14:13:59 2008, japhb wrote: On Fri, 2008-07-25 at 22:18 +0200, Peter Gibbs wrote: typedef HUGEINTVAL(*sprintf_getint_t) (PARROT_INTERP,INTVAL, SPRINTF_OBJ *); So, since obj-getint returns a HUGEINTVAL, I gave it one to store the result in. Fair enough, that's good enough for me. As to why sprintf_obj is defined that way, I have no clue. A question for another day ... when we take a pass through our typedefs and check ourselves for sanity. -'f sprintf2.t now also has one of the tests coke++ originally posted. Since it now passes and is tested for, I'm marking this resolved.
[perl #46805] [TODO] [Perl] Add more list_* tests
On Wed Oct 24 12:53:42 2007, pcoch wrote: In t/src/list.t there is the todo item: # TODO which says much in little i.e.: improve the test coverage of the list_* functionality. From what I can tell, t/src/list.t was deleted or moved sometime after r22464. Searching for some of the more unique-looking strings in that revision of the file ( http://www.parrotvm.org/svn/parrot/checkout/trunk/t/src/list.t?rev=22464) turned up nothing in the current version, indicating that this file was deleted because its function was either unnecessary or redundant. If nobody objects I'll mark this ticket as rejected in a couple days.
[perl #46909] [TODO] [Perl] Cope with escaped quotes in tools/build/c2str.pl
On Thu Jun 05 19:07:49 2008, coke wrote: We can always improve the diagnostic emitted by the PMC compiler. Mismatched strings are going to be an issue whether they're in a CONST_STRING declaration or just an assignment to char *. So, no, it's not worth fixing up c2str.pl, IMO. So if it's not worth fixing c2str.pl, can this ticket be rejected?
[perl #48367] [BUG] intlist_get could be dereferencing NULL
On Sat Dec 08 18:24:17 2007, petdance wrote:
In intlist_get(), we call list_get() which can return a NULL.
Then, the result is checked against -1, and then
dereferenced.
I suspect that check against -1 should actually be a
check against NULL, but don't know enough to prove it
and write the test case.
According to make cover, the case where the return was -1 was never hit.
A simple test case caused a segfault, which definitely isn't the right
thing. The attached patch fixes and refactors intlist_get() to make the
coverage more obvious in the output of the coverage tests. It also adds
a test case to exercise the previously neglected path.
I'd like comments on whether intlist_get does the right thing with this
patch and if it's exercised correctly by the test.
Index: src/intlist.c
===
--- src/intlist.c (revision 29733)
+++ src/intlist.c (working copy)
@@ -306,10 +306,13 @@
INTVAL
intlist_get(PARROT_INTERP, ARGMOD(IntList *list), INTVAL idx)
{
-/* XXX list_get can return NULL RT #48367 */
void * const ret = list_get(interp, (List *)list, idx, enum_type_INTVAL);
-const INTVAL retval = ret == (void *)-1 ? 0 : *(INTVAL *)ret;
-return retval;
+if (ret == NULL) {
+return (INTVAL)0;
+}
+else {
+return *(INTVAL *)ret;
+}
}
/*
Index: t/pmc/intlist.t
===
--- t/pmc/intlist.t (revision 29733)
+++ t/pmc/intlist.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test tests = 8;
+use Parrot::Test tests = 9;
=head1 NAME
@@ -168,6 +168,15 @@
I need a shower.
OUTPUT
+pasm_output_is( 'CODE', 'OUTPUT', out of bounds );
+#not sure if this is the right thing to do, but it doesn't segfault
+new P0, 'IntList'
+set P0, 1
+set I0, P0[25]
+end
+CODE
+OUTPUT
+
pasm_output_is( 'CODE', 'OUTPUT', direct access 2 );
new P0, 'IntList'
set I10, 110
[perl #46895] [TODO] [Pir] [C] Investigate and correct incorrect recursion depth counting in debug backtrace
On Thu May 15 10:24:00 2008, julianalbo wrote: On Thu, Oct 25, 2007 at 5:28 PM, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # XXX # in plain functional run-loop result is 999 # other run-loops report 998 # TODO investigate this after interpreter strtup is done # see also TODO in src/embed.c I can't reproduce the problem, and looking at the revisions of src/embed.c around the date of this ticket I don't see any TODO related. I agreee. I ran with a few different runcores and always got 1000 as the number (when Parrot ran and I was patient enough to wait for the output). It was the same for cgoto, cgp, fast, slow and switch. I ran the following with a normal build of Parrot (no options passed to Configure.pl), in case someone wants to say ur doin it rong. ./parrot -R cgoto t/op/debuginfo_5.pir If it turns out I'm no doin it rong, I'll close this ticket in a couple days.
[perl #43218] Memory leaks (compreg, invokecc)
On Thu Jun 14 16:25:24 2007, [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 14:42:31 Jurosz Michal wrote: Attached test use compreg P1, PASM and invokecc it 100,000 times. On win32 (mingw32) it consumes 70MB of RAM with r18834 (107 MB of RAM with r11704). With Linux at r19010, the memory use jumped up to 62 MB for me. However, Valgrind says: ==24190== LEAK SUMMARY: ==24190==definitely lost: 128 bytes in 2 blocks. ==24190==indirectly lost: 208 bytes in 1 blocks. ==24190== possibly lost: 0 bytes in 0 blocks. ==24190==still reachable: 0 bytes in 0 blocks. ==24190== suppressed: 0 bytes in 0 blocks. ==24190== 252 (44 direct, 208 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 3 ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) ==24190==by 0x41A1170: mem_sys_allocate ==24190==by 0x41AF37E: parrot_new_pmc_hash_x ==24190==by 0x41AF45E: parrot_new_pmc_hash ==24190==by 0x424930A: Parrot_Hash_init ==24190==by 0x4203715: Parrot_default_thaw ==24190==by 0x424934B: Parrot_Hash_thaw ==24190==by 0x41AD9C0: visit_todo_list_thaw ==24190==by 0x41AD703: visit_loop_todo_list ==24190==by 0x41AE1EB: run_thaw ==24190==by 0x419B518: init_world ==24190== 84 bytes in 1 blocks are definitely lost in loss record 2 of 3 ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) ==24190==by 0x41A1170: mem_sys_allocate ==24190==by 0x41EC1DB: queue_init ==24190==by 0x41ED08B: Parrot_init_events ==24190==by 0x419F464: make_interpreter ==24190==by 0x41D3BEB: Parrot_new ==24190==by 0x8048860: main ==24190== 208 bytes in 1 blocks are indirectly lost in loss record 3 of 3 ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) ==24190==by 0x41A1170: mem_sys_allocate ==24190==by 0x41AF2C9: init_hash ==24190==by 0x41AF45E: parrot_new_pmc_hash ==24190==by 0x424930A: Parrot_Hash_init ==24190==by 0x4203715: Parrot_default_thaw ==24190==by 0x424934B: Parrot_Hash_thaw ==24190==by 0x41AD9C0: visit_todo_list_thaw ==24190==by 0x41AD703: visit_loop_todo_list ==24190==by 0x41AE1EB: run_thaw ==24190==by 0x419B518: init_world I realize the numbers don't add up, but I'm not sure that this is an actual leak. -- c Is this something we're still concerned about or can this ticket be closed?
[perl #44967] Using a freed variable (Coverity CID 98)
On Tue Sep 04 11:40:30 2007, rblasch wrote:
The key here is the model. While Coverity's model captures the
Cfree quite correctly, I don't think it recognizes the pointer update
in the double linked list, which is done in Csubst_ins, as important.
Coverity probably sees something like the following in the inspected code:
Instruction *ins, *ins2;
for (ins = unit-instructions; ins; ins = ins-next) {
ins2 = ins-next;
free(ins2);
}
So, it's a false positive.
Ron
Since this is a false positive, is there any reason to keep this ticket
open?
Christoph
[perl #39738] [BUG] bind fails with errno EADDRNOTAVAIL on darwin and FreeBSD
On Thu Jul 06 09:21:34 2006, [EMAIL PROTECTED] wrote: With parrot r13181, binding to a non-privileged port on localhost consistently fails with EADDRNOTAVAIL on Mac OS X and FreeBSD boxes for Intel and PPC platforms. The same command succeeds on Linux. Steps to reproduce: 1) ./parrot examples/io/httpd.pir 2) netstat -na | grep 1234 | grep LISTEN Actual results: Socket is not bound Expected results: netstat -na should contain a line like this: tcp0 0 127.0.0.1:1234 0.0.0.0:* LISTEN This no longer fails on a FreeBSD 7.0 vm. It'd be nice to confirm that it also works on Darwin, but I'll plan on marking this resolved in a few days if there are no objections. Christoph
[perl #39738] [BUG] bind fails with errno EADDRNOTAVAIL on darwin and FreeBSD
On Tue Jul 22 23:24:10 2008, [EMAIL PROTECTED] wrote: It works for me too on Mac OSX 10.4 and parrot rev 29370. Thanks for following up! Chris It just goes to show that all problems (even interpersonal ones) go away if you ignore them for long enough. I'm marking this one as resolved.
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Tue Jul 22 23:34:13 2008, [EMAIL PROTECTED] wrote: This patch contains a fix and a simplification. It should now be cross-platform and thread-safe. I'll test on some other *nixes and go on from there. If nothing else it works fine on Ubuntu/x86. It also works in FreeBSD 7.0 and OpenBSD 4.3. If someone can confirm that it's OK on windows (msvc or cygwin) and that the patch otherwise looks good, it can be committed and this ticket resolved.
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Thu Jul 17 15:53:12 2008, julianalbo wrote:
On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
With this patch, the new tests still pass on Linux/x86. The patch uses
STRING-strstart to avoid leaking a malloc'd buffer when throwing an
exception, which may or may not be considered kosher in this situation.
Can't you use real_exception(interp, NULL, E_SystemError, %Ss,
errmsg_pstring); ?
Using internal details of parrot strings must be avoided.
I agree. I just didn't know real_exception was smart enough to do that
trick. The attached patch (v5) properly fixes the problem on my system.
There shouldn't be any remaining issues, but the patch ought to be
tested on a another *nix and Windows.
Index: src/pmc/file.pmc
===
--- src/pmc/file.pmc (revision 29551)
+++ src/pmc/file.pmc (working copy)
@@ -26,6 +26,21 @@
/* RT#46681 apparently, strerror_r is thread-safe and should be used instead.*/
+/* strerror_r should truncate the message if its too long for the supplied buffer
+ * it's probably best to just specify a sane default buffer size than to worry
+ * about retrying calls
+ */
+#define ERRBUF_SIZE 128
+
+#define STRERROR_R_EXCEPTION() \
+{ \
+char errmsg[ERRBUF_SIZE]; \
+char *errstr = strerror_r(errno, errmsg, ERRBUF_SIZE); \
+STRING *errmsg_pstring = string_make(interp, errstr, strlen(errstr), NULL, 0); \
+real_exception(interp, NULL, E_SystemError, %Ss, errmsg_pstring); \
+}
+
+
static PMC *File_PMC;
pmclass File singleton {
@@ -89,6 +104,7 @@
*/
+
METHOD is_dir(STRING *path) {
struct stat info;
char *cpath = string_to_cstring(interp, path);
@@ -100,8 +116,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISDIR(info.st_mode))
@@ -131,8 +146,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISREG(info.st_mode))
@@ -164,8 +178,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISLNK(info.st_mode))
@@ -199,6 +212,8 @@
string_cstring_free(cfrom);
+char errmsg[ERRBUF_SIZE];
+
if (source) {
char *cto= string_to_cstring(interp, to);
FILE *target = fopen(cto, w+b);
@@ -223,14 +238,12 @@
fclose(target);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
fclose(source);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
#undef CHUNK_SIZE
}
@@ -254,8 +267,7 @@
string_cstring_free(cto);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
}
}
Index: config/gen/platform/win32/string.h
===
--- config/gen/platform/win32/string.h (revision 29551)
+++ config/gen/platform/win32/string.h (working copy)
@@ -14,6 +14,8 @@
# endif
#endif
+#define strerror_r(errnum, buf, buflen) strerror_s((buf), (buflen), (errnum))
+
#endif /* PARROT_PLATFORM_WIN32_STRING_H_GUARD */
/*
[perl #46679] [TODO] [C] Check if we need to deallocate strerror strings
On Tue Feb 19 16:19:14 2008, Whiteknight wrote: On Mon Oct 22 09:49:02 2007, ptc wrote: In src/pmc/file.pmc there is the todo item: /* XXX Check if we need to deallocate strerror strings */ Do this. According to: http://www.cplusplus.com/reference/clibrary/cstring/strerror.html The strings returned by strerror() are statically allocated, and should not be modified or freed. I have not been able to find explicit confirmation of this fact anywhere else, however. I'll keep looking, but I think that we do not need to free them. --Andrew whitworth All the documentation and examples I've found agree that strerr returns a pointer to a static buffer that shouldn't be free'd. I'm calling this resolved.
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Wed Apr 23 18:18:00 2008, [EMAIL PROTECTED] wrote: This thread trailed off about 4 months ago. Could we get an update on its status, i.e., whether it should be applied, what OSes it's passing on, etc. Thank you very much. kid51 The tests passed because the strerror/strerror_r code doesn't have any coverage. I added some tests that make sure the error message consists only of alphanumerics and whitespace in r29551. The tests pass with the current src/pmc/file.pmc, but fail with the attached patch. I don't have the tuits to fix the patch, but at least now it's obvious that it was broken.
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Thu Jul 17 01:17:51 2008, cotto wrote:
On Wed Apr 23 18:18:00 2008, [EMAIL PROTECTED] wrote:
This thread trailed off about 4 months ago. Could we get an update on
its status, i.e., whether it should be applied, what OSes it's passing
on, etc.
Thank you very much.
kid51
The tests passed because the strerror/strerror_r code doesn't have any
coverage. I added some tests that make sure the error message consists
only of alphanumerics and whitespace in r29551. The tests pass with the
current src/pmc/file.pmc, but fail with the attached patch. I don't
have the tuits to fix the patch, but at least now it's obvious that it
was broken.
With this patch, the new tests still pass on Linux/x86. The patch uses
STRING-strstart to avoid leaking a malloc'd buffer when throwing an
exception, which may or may not be considered kosher in this situation.
If this is judged appropriate, I'd appreciate test confirmation from at
least OSX/x86 and Windows since strerror_r seems to be a special function.
Index: src/pmc/file.pmc
===
--- src/pmc/file.pmc (revision 29551)
+++ src/pmc/file.pmc (working copy)
@@ -26,6 +26,21 @@
/* RT#46681 apparently, strerror_r is thread-safe and should be used instead.*/
+/* strerror_r should truncate the message if its too long for the supplied buffer
+ * it's probably best to just specify a sane default buffer size than to worry
+ * about retrying calls
+ */
+#define ERRBUF_SIZE 128
+
+#define STRERROR_R_EXCEPTION() \
+{ \
+char errmsg[ERRBUF_SIZE]; \
+char *errstr = strerror_r(errno, errmsg, ERRBUF_SIZE); \
+STRING *errmsg_pstring = string_make(interp, errstr, strlen(errstr), NULL, 0); \
+real_exception(interp, NULL, E_SystemError, errmsg_pstring-strstart); \
+}
+
+
static PMC *File_PMC;
pmclass File singleton {
@@ -89,6 +104,7 @@
*/
+
METHOD is_dir(STRING *path) {
struct stat info;
char *cpath = string_to_cstring(interp, path);
@@ -100,8 +116,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISDIR(info.st_mode))
@@ -131,8 +146,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISREG(info.st_mode))
@@ -164,8 +178,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISLNK(info.st_mode))
@@ -199,6 +212,8 @@
string_cstring_free(cfrom);
+char errmsg[ERRBUF_SIZE];
+
if (source) {
char *cto= string_to_cstring(interp, to);
FILE *target = fopen(cto, w+b);
@@ -223,14 +238,12 @@
fclose(target);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
fclose(source);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
#undef CHUNK_SIZE
}
@@ -254,8 +267,7 @@
string_cstring_free(cto);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
}
}
Index: config/gen/platform/win32/string.h
===
--- config/gen/platform/win32/string.h (revision 29551)
+++ config/gen/platform/win32/string.h (working copy)
@@ -14,6 +14,8 @@
# endif
#endif
+#define strerror_r(errnum, buf, buflen) strerror_s(buf, buflen, errnum)
+
#endif /* PARROT_PLATFORM_WIN32_STRING_H_GUARD */
/*
[perl #56718] [BUG] Array PMC freeze/thaw/visit broken
On Wed Jul 09 00:04:45 2008, [EMAIL PROTECTED] wrote:
r29183 adds a test to t/pmc/array.t that exposes some brokenness in
the Array
PMC's freeze/thaw code path. I added the test because it looked like
Array's
freeze/thaw/visit code had no test coverage. It turns out that
list_visit
also never gets called (at least according to make cover). I don't
have the
tuits to fix this for now, hence the ticket and the failing test.
To repo, just prove t/pmc/array.t. If everything passes, you win!
(from #ps today)
As a note to whomever fixes this, the sparseness of the Array PMC is its
only remaining useful feature. Fixing freeze/thaw/visit is valuable
because it will make implementing sparseness in
{Fixed|Resizable}{PMC|Integer|Boolean|Float|String}Array easier. Once
those PMCs are sparse, the Array PMC can go away.
[perl #40631] [TODO] add tests for native PMC types
On Mon Feb 13 13:05:01 2006, [EMAIL PROTECTED] wrote: all PMCs (src/pmc/*.pmc) should be tested. the basic types, as defined in PDD17 (docs/pdds/clip/pdd17_basic_types.pod) should be given higher priority, so tests should be developed first to cover these. not surprisingly, basic types have a number of tests already, but there are holes in test coverage that should be plugged. after basic types are well-tested, remaining PMC types distributed in the parrot core should be targeted. this is a job that requires the ability to read c source, and read and write pir and/or pasm test code. however, deep knowledge of these languages is not required. takers most welcome. ~jerry Adding more native PMC tests is a good idea, but this ticket isn't closeable as described. There should be a concrete criteria (or at least a reasonably simple subjective one) for determining when a PMC is sufficiently well-tested. Something based on code coverage (via make cover) would be a good start.
[perl #46825] [TODO] [Pir] Fix ResizableBooleanArray Cclone test
On Wed Oct 24 14:23:23 2007, pcoch wrote:
In t/pmc/resizeablebooleanarray.t there is the todo item:
TODO: {
local $TODO = this is broken;
pasm_output_is( 'CODE', 'OUTPUT', clone );
Which is to say, fix cloning in ResizableBooleanArrays or fix the test (or
both?)
It looks like both the test and the code were broken. The clone test
passes now and the code seems to do right thing as of r29469.
I'm calling it resolved.
[perl #47109] [CAGE] wrap macro args in parens inside macro bodies
On Sun Jul 13 23:26:51 2008, [EMAIL PROTECTED] wrote: +1 for modifying the test, not the macros. -- c Resloved.
[perl #56832] Fwd: src/jit/i386/core.jit:1031: error: ?DO? undeclared
On Fri Jul 11 14:00:12 2008, cotto wrote: On Fri Jul 11 05:29:20 2008, coke wrote: Belatedly add Moritz's response to the ticket. A fix for this bug was committed in r29289 which looks like it will resolve this issue. If that's the case, this ticket can be closed. Since there haven't been any responses to this and since based on http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk it looks like this is fixed, I'm marking this ticket as resolved.
[perl #47109] [CAGE] wrap macro args in parens inside macro bodies
On Thu Feb 21 13:52:31 2008, coke wrote: On Fri Nov 02 07:56:44 2007, particle wrote: as per PDD07 (r22655,) c macro args *must* be wrapped in parens inside macro bodies, to allow expressions passed as macro parameters. for example, i expect: #define CLASS_has_alien_parents_TEST(o) CLASS_flag_TEST(has_alien_parents, (o)) instead of #define CLASS_has_alien_parents_TEST(o) CLASS_flag_TEST(has_alien_parents, o) this entails conversion of all current macros to meet this criterion, and a test to ensure compliance. ~jerry After a few false starts, we now have t/codingstd/c_macro_args.t which is currently reporting 502 macro/arg combinations where the parens are not used. To close out this ticket, this test should pass, and be added to the list of codingstd tests in lib/Parrot/Harness/DefaultTests.pm The test now passes, although I'll leave this ticket open until someone can confirm that it still does the right thing. The new version of t/codingstd/c_macro_args.t as of r29372 has several special cases: stringification, concatenation, use of args as types when pointers to that type are cast/created, function argument instrumentation, args as function names and macros which recursively use macros which use concatenation. This last case is used mostly in includes/parrot/pobj.h for testing, setting and clearing flags. These macros could be rewritten, but there are enough of them that it's easier just to tell the test that these macros are ok. I would appreciate comments on whether this is the right approach. Thanks, Christoph
[perl #56832] Fwd: src/jit/i386/core.jit:1031: error: ?DO? undeclared
On Fri Jul 11 05:29:20 2008, coke wrote: Belatedly add Moritz's response to the ticket. A fix for this bug was committed in r29289 which looks like it will resolve this issue. If that's the case, this ticket can be closed.
[perl #42313] [CAGE] improper casting to void * in src/dynext.c
On Thu Jun 12 09:56:55 2008, nahoo wrote: Does this suggest that the patch is moot, and that we may close the ticket? yes. Since the patch seem to have been applied without this ticket being updated, I'm marking it as resolved now.
[perl #43741] [TODO] generate C line comments in vtable_decl()
On Tue Jul 10 06:46:20 2007, pcoch wrote: In the file lib/Parrot/Pmc2c.pm there is the todo item (within the vtable_decl() sub): # TODO gen C line comment Implement this. The todo is no longer there but the code doesn't generate a #line directive either. Looking at the generated code it's easy to see how #line directives wouldn't be helpful in this situation. Vote to reject.
[perl #42374] [TODO] free results from string_to_cstring() without ugly warnings
On Mon Apr 09 01:17:50 2007, pcoch wrote: In the file src/ops/io.ops there is the todo item: all results from string_to_cstring() need freeing but this generates ugly warnings WRT discarding the const qualifier free the results but also without generating the warnings if possible. I didn't see any suspicious warnings when building r28926 on linux/x86/gcc. If someone else can confirm that there aren't any ugly warnings here, this ticket can be closed.
