Re: [perl #39378] Pheme Segfault with Keyed Class Names
Am Freitag, 9. Juni 2006 21:19 schrieb chromatic: > Oddly, I see these only when running through the Pheme interpreter, not > when dumping out the raw PIR code and executing that. (gdb) r -G pheme.pbc t/cdr.t 1..2 ok 1 - tail of three elem list should be two elem list ok 2 - tail of two elem list should be one elem list When GC is enabled, I see the same error as shown in the backtrace. Looks like a GC bug to me. For some strange reason, the key in the multi signature has the key_number bit set, which is leading to the segfault. For now I'd suggest to disable DOD/GC for runtime by emitting sweepoff & collectoff opcodes. leo
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Jun 12 13:15:01 2006 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 80 new + 200 open = 280 Created this week: 5 Closed this week: 7 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 39272 failures in languages/tcl/t/cmd_lsort.t 39248 Parrot release 0.4.6 2 - 3 weeks old 39197 lib/Parrot/Test.pm ignores core dumps failures! 39196 [TODO] tests - need to test addmethod 3 - 4 weeks old 39140 Parrot release 0.4.5 4 - 5 weeks old 39132 [TODO] pirtidy - call for help 5 - 6 weeks old 39092 [TODO] Autogenerate functions in *.h files from source 39088 [TODO] Add conditional GCC attributes to functions 39051 Test failure in t/pmc/objects_62.pasm (attributes) 39050 Build failure in compilers/pge/pgc.pir 39043 [TODO] Dynamic PMCs should not include 'parrot/parrot.h' 6 - 7 weeks old 39018 t/pmc/complex failures on Solaris 8/SPARC 39004 [PDD] review pdd25_threads.pod 39003 [PDD] review pdd24_events.pod 39001 [PDD] review pdd22_io.pod 39000 [PDD] review pdd19_pir.pod 38999 [PDD] review pdd18_security.pod 38998 [PDD] review pdd17_basic_types.pod 38997 [PDD] review pdd16_native_call.pod 38996 [PDD] review pdd15_objects.pod 38995 [PDD] review pdd14_bignum.pod 38994 [PDD] review pdd13_bytecode.pod 38993 [PDD] review pdd12_assembly.pod 38992 [PDD] review pdd11_extending.pod 38991 [PDD] review pdd10_embedding.pod 38990 [PDD] review pdd09_gc.pod 38989 [PDD] review pdd08_keys.pod 38988 [PDD] review pdd07_codingstd.pod 38987 [PDD] review pdd06_pasm.pod 38986 [PDD] review PDD05_opfunc.pod 38985 [PDD] review PDD04_datatypes.pod 38984 [PDD] review pdd02_vtables.pod 38983 [PDD] review PDD01_overview.pod 38969 parrot source does not conform to standards 38967 Parrot release 0.5.0 7 - 8 weeks old 8 - 9 weeks old 9 - 10 weeks old 38887 Result of INFINITY or NAN stringification is platform dependent 10 - 11 weeks old 38823 [BUG] solaris 10 w gcc 11 - 12 weeks old 38788 make test results 12 - 13 weeks old 38764 Test results of parrot on Freebsd 13 - 14 weeks old 14 - 15 weeks old 15 - 16 weeks old 38594 [BUG] source line numbers 16 - 17 weeks old 17 - 18 weeks old 38469 [BUG] -O1 branch optimization 18 - 19 weeks old 38432 Exception thrown from constructor leads to oddness 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues Platform Severity Tag Lang Win32 3abandoned 05005threads 0 BASIC0 sco 0fatal 0notok 0 scheme 0 riscos0High 0ok0 tcl 25 qnx 0low 1Patch10 urm 0 powerux 0medium0regex 0 bc 0 other 0none 0sendToCPAN0 punie1 os390 0Normal1Todo174 Amber0 os2 0unknown 0unknown 0 Zcode0 openbsd 1Wishlist 3utilities 0 Lisp 0 next 0 notabug 0 ruby 0 Solaris 0 library 0 python 0 sunos 0 install 1 befunge 0 svr4 0 bounce0 bf 0 VOS 0 Bug 17 cola 0 vms 0 compiler 0 forth0 uts 0 configure 0 jako 0 unknown 0 core 0 m4 0 unix 0 dailybuild0 ook 0 unicosmk 0 docs 0 plot 0 unicos0 duplicate 0 perl60 sysv 0 wontfix 0 svr5 0 netbsd0 mswin32 0 dynixptx 0 dos 0 dgux 0 dec_osf 0 darwin0 cygwin_nt 0 cygwin0 bsdos 0 All 2 freebsd 0 generic 0 gnu 0 MacOS X 0 macos 0 machten 0 mac 0 lynxos0 Linux 0 irix640 irix 0 HPUX 0 aix 0 --- Ticket Status By Version New or OpenResolved --- Requesto
Re: A question about .begin_eh
On Sun, Jun 11, 2006 at 11:52:14AM -0400, Bob Rogers wrote: >I notice the following paragraph, vintage late May, in > pdd23_exceptions.pod: > > A C<.begin_eh> directive marks the beginning of a span of > opcodes which the programmer expects to throw an exception. If > an exception occurs in the execution of the given opcode span, > Parrot will transfer control to I. > > I assume this means that you intend to replace the current methodology > of searching for an Exception_Handler object on the control stack when > an error is thrown with a search through sub metadata. That's the plan. The upside is that on the non-exceptional case, nothing at all needs to be done. I just couldn't see the value in making the VM allocate and free memory blocks on the control stack, over and over, when no exceptions are occurring. > How do you envision this interacting with C, e.g.? Currently, > it is straightforward for find_exception_handler to DTRT WRT other control > stack entries. Would the metadata also contain information about > C and such? I hadn't decided either way about C. Seems to me that either way will work though. Could you spell out a little more of what you see as being bad (or harder)? > P.S. FWIW, I am asking now because I have begun to work again on > dynamic binding -- which of course makes this problem worse. I can't see how. Dynamically bind all you want, but the code of each subroutine is fixed at compile time. Having static metadata is no sin as long as as the data that they're meta of are also static. -- Chip Salzenberg <[EMAIL PROTECTED]>
[perl #39425] [TODO] namespaces: store_global variant
# New Ticket Created by Will Coleda # Please include the string: [perl #39425] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39425 > Need a store_global opcode that takes a multi-element NS key. -- Will "Coke" Coleda [EMAIL PROTECTED]
[perl #39426] [BUG] Can't build with cygwin.
# New Ticket Created by Will Coleda # Please include the string: [perl #39426] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39426 > The cygwin build fails with the following error during make: Invoking Parrot to generate runtime/parrot/include/config.fpmc -- cross your fing ers ./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc /bin/sh: line 1: 3088 Segmentation fault (core dumped) ./ miniparrot.exe co nfig_lib.pasm >runtime/parrot/include/config.fpmc make: *** [runtime/parrot/include/config.fpmc] Error 139 This with r12926 $ gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose -- prefix=/usr -- exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/ usr/lib --man dir=/usr/share/man --infodir=/usr/share/info --enable- languages=c,ada,c++,d,f77, java,objc --enable-nls --without-included-gettext --enable-version- specific-runt ime-libs --without-x --enable-libgcj --disable-java-awt --with-system- zlib --ena ble-interpreter --disable-libgcj-debug --enable-threads=posix -- enable-java-gc=b oehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash- synchroniza tion --enable-libstdcxx-debug : (reconfigured) Thread model: posix gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) $ perl -v This is perl, v5.8.7 built for cygwin-thread-multi-64int (with 1 registered patch, see perl -V for more detail) Copyright 1987-2005, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. -- Will "Coke" Coleda [EMAIL PROTECTED]
[perl #39425] [TODO] namespaces: store_global variant
> [coke - Mon Jun 12 10:29:50 2006]: > > Need a store_global opcode that takes a multi-element NS key. > Implemented, plus test case. Jonathan
[perl #39430] Method cache not always invalidated
# New Ticket Created by Jonathan Worthington # Please include the string: [perl #39430] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39430 > 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.
Re: A question about .begin_eh
From: Chip Salzenberg <[EMAIL PROTECTED]> Date: Mon, 12 Jun 2006 06:54:24 -0700 On Sun, Jun 11, 2006 at 11:52:14AM -0400, Bob Rogers wrote: >I notice the following paragraph, vintage late May, in > pdd23_exceptions.pod: > >A C<.begin_eh> directive marks the beginning of a span of >opcodes which the programmer expects to throw an exception. If >an exception occurs in the execution of the given opcode span, >Parrot will transfer control to I. > > I assume this means that you intend to replace the current methodology > of searching for an Exception_Handler object on the control stack when > an error is thrown with a search through sub metadata. That's the plan. The upside is that on the non-exceptional case, nothing at all needs to be done. I just couldn't see the value in making the VM allocate and free memory blocks on the control stack, over and over, when no exceptions are occurring. Yes, that's nice. The downside, though, is that you have to do more work when it's time to throw, but I agree that this is likely to happen less often, at least for most error-handling situations. (There's also a load-time cost, I imagine, but it can't be very large.) Unfortunately, this is a step backwards from my perspective, as it is already problematic to use Parrot as it exists now to implement ANSI Common Lisp error signalling semantics, and any approach based on metadata (being static) will make it more so. However, I can still implement ANSI semantics using dynamic binding, C, and continuations that respect both (which they currently do not), though the result won't interoperate with error handling in the rest of Parrot. > How do you envision this interacting with C, e.g.? Currently, > it is straightforward for find_exception_handler to DTRT WRT other control > stack entries. Would the metadata also contain information about > C and such? I hadn't decided either way about C. Seems to me that either way will work though. Could you spell out a little more of what you see as being bad (or harder)? Actions are dynamic state that must nest properly with respect to error handlers. So you have to know how many actions to pop & invoke when unwinding the stack before invoking a given error handler. So it seems to me that you would also have to lexicalize actions in order to give find_exception_handler a clue. (Or, more accurately, not to take away the clue that it has.) But you can't lexicalize actions completely without removing the ability to invoke a closure as a cleanup action! > P.S. FWIW, I am asking now because I have begun to work again on > dynamic binding -- which of course makes this problem worse. I can't see how. Dynamically bind all you want, but the code of each subroutine is fixed at compile time. Having static metadata is no sin as long as as the data that they're meta of are also static. -- Chip Salzenberg <[EMAIL PROTECTED]> True, but not all items on the control stack are as static as error handlers, and they interact to a large degree. Dynamic bindings in particular require runtime dynamic state (namely, the saved values), so there still needs to be something on the control stack to capture it. Of course, one can store metadata that records how deep the binding stack should be at each handler (relative to the sub entrypoint), given the right lexical cues in the source. But since (I believe) we still need binding and unbinding opcodes that do something at runtime, and could therefore be conditionalized away, or might even throw an error, this has its pitfalls. -- Bob
